Tu agente de código escribe bien y admite mal lo que dio por hecho. Elige una forma para el estado, una convención de errores, un límite entre módulos, en silencio, y tú descubres la decisión tres archivos después, cuando algo la contradice.
El método BMAD ataca eso poniendo las decisiones en disco antes de que exista el código. Se instala como un conjunto de skills de agente, te da personas con nombre con las que hablar y escribe briefs y documentos de arquitectura que tu siguiente sesión puede leer en lugar de volver a deducir.
Esta guía lo instala desde cero, ejecuta dos workflows de planificación de principio a fin y después hace lo que la mayoría de los artículos se salta: comprueba el resultado con el linter que BMAD incluye exactamente para eso. Medido el 23 de septiembre de 2026 con la versión 6.13.0-next.
Míralo en video
La misma idea en video: qué es el método, por qué varias personas especializadas superan a un único asistente generalista y qué se siente al trabajar con ellas.
¿Qué problema resuelve BMAD en realidad?
Conserva el razonamiento que produjo tu código, en lugar de tirarlo al terminar el chat. Un agente de código es eficaz implementando e indiferente a la procedencia: pídele una funcionalidad y obtienes una funcionalidad, más una docena de decisiones que nadie registró.
La respuesta de BMAD es un conjunto de skills, cada una un workflow especializado, que escriben su resultado en archivos dentro de tu repositorio. Un brief de producto es un archivo. Un documento de arquitectura es un archivo. El razonamiento detrás de cada uno se añade a un registro de memoria que vive al lado.
Esa forma es todo el argumento. La siguiente sesión, el siguiente agente o el compañero que hereda el proyecto lee la decisión en lugar de adivinarla; y como los artefactos son Markdown plano, nada queda encerrado en el historial de chat de un proveedor.
¿Qué necesitas antes de instalar?
Tres cosas, y una de ellas es nueva desde el video: Node.js con npm, Git y uv. Los workflows de BMAD se apoyan en scripts de Python, y uv es la forma de ejecutarlos: sin él, las skills se detienen y te piden instalarlo.
node --version # v22.21.1
git --version # 2.54.0
uv --version # 0.11.6Tu editor también tiene que admitir skills de agente. La skills CLI detecta qué estás usando e instala en consecuencia; en esta máquina encontró Claude Code e instaló sin hacer una sola pregunta.
¿Cómo se instala?
Un comando en tu proyecto, y la skills CLI hace el resto. Puedes ver primero qué hay disponible: el repositorio publica 32 skills, y la idea no es que las tomes todas.
npx skills add bmad-code-org/BMAD-METHOD --listPara instalar, nombra las skills que quieres. La base que propone el README es el hub más los dos registros de módulo; añade las personas y los workflows que esperas usar.
npx skills add bmad-code-org/BMAD-METHOD \
--skill bmad --skill bmod-core-tools --skill bmod-method \
--skill bmad-build --skill bmad-agent-analyst \
--skill bmad-agent-architect --skill bmad-brainstormingSiete skills aterrizaron en 3,7 segundos. Viven en .agents/skills/, en la raíz del proyecto, enlazadas simbólicamente a .claude/skills/ para Claude Code y copiadas a una estructura universal que leen otras 20 herramientas (Codex, Cursor, Copilot y el resto), así que la misma instalación sirve para el editor que abras después.
¿Cómo sabes qué falta?
Pide el estado antes de hacer nada más. La skill bmad es un hub: lee la instalación, informa en qué estado está y nombra el único comando que toca ejecutar a continuación.
El primer status en una instalación recién hecha devolvió current: false con next: "bmad setup" y, más útil aún, seis recomendaciones. Cada persona declara las skills de workflow en las que se apoya, y las que omitiste aparecen listadas con el comando exacto para añadirlas.
{
"skill": "bmad-agent-architect",
"requires": "bmad-architecture",
"state": "missing",
"install": "npx skills add bmad-code-org/BMAD-METHOD --skill bmad-architecture"
}Son recomendaciones, no fallos: una analista sin la skill de reconocimiento profundo sigue funcionando, solo tiene menos recursos a mano. Instalar las seis llevó otros 3,3 segundos y dejó el proyecto en 13 skills.
¿Qué crea el setup?
Ejecuta setup y BMAD escribe una carpeta _bmad/: 19 archivos, 288 KB y nada que tengas que rellenar a mano. Es un upsert, así que también es lo que ejecutas después de cada actualización.
_bmad/
config.toml # project name and where artifacts go
scripts/ # shared Python the skills call
core-tools/scripts/ # per-module copies
method/scripts/
custom/.gitignore # keeps personal answers out of commitsLa configuración es corta y merece leerse, porque decide dónde aterrizará todo lo que produzcas: _bmad-output/planning-artifacts para la planificación, _bmad-output/implementation-artifacts para el trabajo de código y docs para el conocimiento del proyecto.
El setup solo hace las preguntas que declaran los módulos instalados. En esta ejecución no hubo ninguna, y el segundo status devolvió current: true, next: null, con cero problemas y cero requisitos sin cumplir.
¿Qué producen en realidad los workflows de planificación?
Archivos, en una carpeta de ejecución, con un registro de memoria al lado. Apuntado a un producto pequeño (un registro de préstamos para una biblioteca comunitaria gestionada por voluntarios), el workflow de brief produjo brief.md bajo una carpeta con fecha.
Su estructura: resumen ejecutivo, problema, solución, a quién sirve, criterios de éxito, alcance y preguntas abiertas.
Lo interesante es el acompañante. Cada workflow escribe sus decisiones a través de un script compartido, así que la carpeta acumula un registro del porqué separado del qué:
uv run _bmad/scripts/memlog.py append --workspace "$W" \
--type decision \
--text "Scope fixed to loans and returns only; borrower accounts, reservations and fines explicitly out of v1."Esa línea es la promesa del contexto duradero hecha concreta. El brief dice qué es el producto; el memlog dice qué alternativas se cerraron y cuándo, que es justo la parte que normalmente se evapora cuando se cierra una ventana de chat.
¿En qué se diferencia la skill de arquitectura de pedir un diseño?
Se niega a escribir la mayor parte de lo que esperarías. La skill de arquitectura de BMAD produce un spine (una columna vertebral): solo las invariantes que permitirían que dos partes construidas por separado diverjan. Todo lo demás se aplaza de forma explícita.
Cada decisión es un bloque pequeño con tres campos: a qué obliga, qué divergencia evita y la regla exigible. El formato es lo que la hace comprobable más adelante.
### AD-1 — A loan's returned state is a timestamp, never a boolean
- **Binds:** all
- **Prevents:** two builders modelling the same fact differently — one as
`isReturned: true`, one as `returnedAt` — making the overdue query and the
history view disagree.
- **Rule:** the `Loan` entity carries `returnedAt` as a nullable timestamp.
Open means `returnedAt == null`. No boolean mirror may be stored.La skill también insiste en que cualquier tecnología que nombre se verifique por versión en la web en lugar de recordarse, y por eso la tabla de stack del resultado lleva versiones fijadas y no nombres vagos. Para este spine, eso supuso confirmar React 19.3.0, Vite 8.3.0, TypeScript 7.0.2 y el Parse JS SDK 8.6.0 antes de fijarlos.
¿Puedes verificar el resultado o tienes que confiar?
Puedes verificar una parte real, algo poco habitual en esta categoría. La skill de arquitectura incluye scripts/lint_spine.py, y ejecutarlo sobre el spine producido es un solo comando.
uv run .agents/skills/bmad-architecture/scripts/lint_spine.py \
--workspace "_bmad-output/planning-artifacts/architecture/architecture-bmad-demo-2026-09-23"El spine volvió limpio: "ok": true, "total_findings": 0. Por sí solo eso demuestra poco (un linter que nunca salta no vale nada), así que corrompimos el mismo archivo a propósito y lo ejecutamos otra vez.
{"ok": false, "total_findings": 3, "findings": [
{"detail": "AD-2 missing required field(s): rule", "severity": "high"},
{"detail": "AD-1 id reused (also at line 32)", "severity": "high"},
{"detail": "AD-1 is non-monotonic (follows AD-4)", "severity": "high"}
]}Tres hallazgos de severidad alta, cada uno con su línea. Las comprobaciones son estructurales, no semánticas (ninguna herramienta te dirá que una decisión es incorrecta), pero “cada decisión lleva su regla y los ids nunca chocan” es exactamente el tipo de deriva que vuelve un documento poco fiable seis meses después.
¿Qué pasa cuando pasas al código?
La skill de build se compila a sí misma para cada ejecución en lugar de entregar al agente un único prompt estático. Invocarla renderiza un snapshot en _bmad/render/, y el snapshot solo contiene los pasos que necesita la ruta elegida.
Pedir la ruta oneshot con una revisión rápida produjo un snapshot de 92 KB y 12 archivos (los pasos de clarificación, plan y oneshot, los prompts de revisión y un manifest), mientras que los pasos de la ruta larga quedaron fuera.
El workflow que renderiza lleva estándares explícitos, incluido un listón de “Ready for Development” que exige que cada tarea nombre una ruta de archivo y que cada criterio de aceptación esté escrito como Given/When/Then.
¿Con qué debes tener cuidado?
Tres cosas, ninguna decisiva. La primera es la brecha de versiones: npx skills add tira de la rama main del repositorio, así que las skills informaron 6.13.0-next mientras bmad-method en npm está en 6.12.0. Si necesitas una versión fija, instala desde npm o desde un marketplace de plugins.
La segunda son los permisos. Las skills se ejecutan con todos los derechos de tu agente, y el instalador lo dice. El propio script de setup de BMAD es limpio (sin ejecución de shell, acceso a red limitado a descargar un manifest de versiones, escrituras confinadas a la carpeta que le pasas), pero eso es una propiedad de este proyecto, no de las skills en general.
La tercera es la tentación de instalar de más: con 32 skills disponibles, apetece llevárselas todas. El status te dirá qué quieren en realidad tus personas. Toma esas y deja el resto.
¿Dónde deja esto a tu backend?
Exactamente donde lo puso el spine, que es la idea. El documento de arquitectura que produjo esta ejecución fijó un backend gestionado detrás de una única capa de gateway: un solo módulo autorizado a importar el SDK, que devuelve objetos planos al dominio.
Es un límite que vale la pena dejar por escrito antes de que exista código, sea cual sea la plataforma que haya detrás. También es lo que hace reversible la decisión: la regla nombra la capa, no al proveedor, así que cambiar la fuente de datos más adelante toca un directorio en lugar de cada componente.
Las herramientas de planificación no construyen nada por sí solas. Lo que BMAD cambia es que las razones sobreviven a la sesión, y unas razones en disco son lo más barato que tendrás cuando el proyecto cumpla seis meses y la persona que tomó la decisión ya no esté.
