Method packs are PaellaDoc plugin model for vocabulary: PRDs, epics, user stories, acceptance criteria, decision records.
🇬🇧 English
PaellaDoc separates what an artifact is (canonical) from what we call it (method-specific). This is the single design decision that lets PaellaDoc serve devs, PMs, and no-coders with the same engine.
The closed core
There is a fixed list of canonical artifact types. Every method pack must map its concepts to one of these. The list is short on purpose:
prd— Problem statement (role: PROBLEM)epic— Scope (role: SCOPE)user_story— Work item (role: WORK_ITEM)acceptance_criteria— Validation in Gherkin (role: VALIDATION)e2e_test— Release gate (role: RELEASE_GATE)decision_record— Trackable decision (role: DECISION)technical_spec,engineering_task,design_task,risk,improvement,maintenance_task,technical_debt,product_debt
Each artifact has a declared evidence intent: what kind of proof from the repo satisfies it (workflow, capability, behavior, user surface, tests, terminal runs, verification, metric, decision context).
Method packs
A method pack is a plugin that decides what vocabulary you see in your UI. The default classic pack maps:
prd→ “Product Requirements Document”epic→ “Epic”user_story→ “User Story”
A different pack could call them “Brief”, “Initiative”, “Job to be done”. The orchestrator doesn’t care. The canonical type and the role are what flows through the engine.
Why this matters
Three benefits:
- No vocabulary lock-in. You don’t like “user story”? Use a pack that calls it something else. The data underneath is identical.
- No fragmentation. A team using one pack can hand off to a team using another. The canonical types are the lingua franca.
- Extensibility without core changes. New pack ships as a plugin, registers its mappings, and the engine works the same.
For PMs and no-coders
You probably won’t think about method packs day to day. The pack you start with is classic and it just works. This post is for the moment you ask “wait, can I rename this thing?” — yes, but it’s a pack change, not a one-off rename. That decision is intentional.
Extending packs
Documentation on writing your own pack is in the main repo. Short version: you implement a small interface that declares MethodArtifactType instances and their mapping to canonical types and roles. Everything else (UI labels, ordering, defaults) is config.
🇪🇸 Español
PaellaDoc separa qué es un artefacto (canónico) de cómo lo llamamos (específico del método). Es la única decisión de diseño que permite a PaellaDoc servir a devs, PMs y no-coders con el mismo motor.
El closed core
Hay una lista fija de tipos canónicos de artefacto. Cada method pack tiene que mapear sus conceptos a uno de estos. La lista es corta a propósito:
prd— Statement del problema (rol: PROBLEM)epic— Scope (rol: SCOPE)user_story— Work item (rol: WORK_ITEM)acceptance_criteria— Validación en Gherkin (rol: VALIDATION)e2e_test— Release gate (rol: RELEASE_GATE)decision_record— Decisión trazable (rol: DECISION)technical_spec,engineering_task,design_task,risk,improvement,maintenance_task,technical_debt,product_debt
Cada artefacto tiene una intención de evidencia declarada: qué tipo de prueba desde el repo lo satisface (workflow, capability, behavior, user surface, tests, terminal runs, verification, metric, decision context).
Method packs
Un method pack es un plugin que decide qué vocabulario ves en tu UI. El pack classic por defecto mapea:
prd→ “Product Requirements Document”epic→ “Epic”user_story→ “User Story”
Un pack distinto podría llamarlos “Brief”, “Initiative”, “Job to be done”. El orquestador no se entera. El tipo canónico y el rol son lo que fluye por el motor.
Por qué esto importa
Tres beneficios:
- Sin lock-in de vocabulario. ¿No te gusta “user story”? Usa un pack que lo llame de otra forma. Los datos por debajo son idénticos.
- Sin fragmentación. Un equipo usando un pack puede pasarle trabajo a otro equipo con otro pack. Los tipos canónicos son la lingua franca.
- Extensibilidad sin tocar core. Un pack nuevo se entrega como plugin, registra sus mappings, y el motor funciona igual.
Para PMs y no-coders
Probablemente no pienses en method packs día a día. El pack con el que empiezas es classic y simplemente funciona. Este post es para el momento en que preguntes “espera, ¿puedo renombrar esto?” — sí, pero es un cambio de pack, no un rename puntual. Esa decisión es intencional.
Extender packs
La documentación para escribir tu propio pack está en el repo principal. Versión corta: implementas una interfaz pequeña que declara instancias de MethodArtifactType y su mapping a tipos canónicos y roles. Todo lo demás (labels de UI, orden, defaults) es config.