registry.yaml como fuente única de verdad: campos de un pack, uses_skills, external_module, pipelines, intake, las comprobaciones, lo generado y cómo un equipo añade un agente o pack con Maker.
Detrás de cada lista, cifra y archivo de instrucciones generado de BMAD+ hay un solo archivo: registry.yaml, en la raíz del repositorio fuente de BMAD+. Declara los packs, sus agentes, habilidades, archivos de datos, disposición de instalación, runtimes y etiquetas de cumplimiento, los adaptadores, la doctrina de tratamiento de datos y más. Cuanto está aguas abajo se genera a partir de él, de modo que una lista, una cifra o un adaptador no pueden desviarse de las declaraciones. Esta página es para quien quiera entender ese contrato, leer con confianza los archivos generados o extender BMAD+ en un fork o una distribución de equipo.
Nota· Un archivo del repositorio fuente
El paquete npm incluye los resultados generados (las definiciones de packs en la CLI, module.yaml, los adaptadores) y los scripts generadores tools/build/generate.js, generate-adapters.js e intake-contract.js, pero no el propio registry.yaml. Un proyecto instalado nunca contiene, pues, el registro; contiene AGENTS.md, _bmad/module.yaml y las habilidades. Para cambiar el registro se trabaja en un clon del repositorio de BMAD+.
Nombre en clave, nombre visible, versión (comprobada contra package.json), versión de BMAD-METHOD de la que deriva, si debe conservarse el aviso original.
targets
El archivo columna, el contrato de integración (execution: host-managed, lifecycle_events: not-integrated), el backend de procesos opcional (command, codex-exec, supervisor en primer plano, sin planificación), los siete adaptadores y las familias de modelos admitidas (claude, gpt, gemini, local).
runtimes
Node.js 20 o superior; Python 3.11 o superior con uv y un respaldo pipx para el aprovisionamiento opcional.
memory
Los ámbitos de memoria (archivos de proyecto, cartera) y las cuatro reglas de conducta.
eval
Las puertas de evaluación (repetición en pull requests; ejecuciones con el anfitrión nativo para cambios de modelo).
data_handling
La doctrina detrás de la página de tratamiento de datos: cada flujo que puede salir de la máquina, con su base de consentimiento.
packs
Los diez packs y cuanto figura en la tabla siguiente.
Campos de un pack
Campo
Qué declara
order, display_name, cli, summary
Orden de instalación y de visualización, nombres, las cadenas exactas que muestra el instalador. Las cifras de un resumen se derivan con marcadores: el generador rechaza un número de agentes, habilidades, workflows o packs escrito a mano en esos campos.
required, runtime
Core es required: true. Los runtimes que necesita un pack (node, y python para SEO).
agents, personas
Los ids de agentes que registra el instalador y el perfil (persona) visible de cada uno (nombre, rol, descripción).
skills, data
Los directorios de habilidades y archivos de datos que instala el pack.
install_layout, pack_dir, doctor
loose copia directorios de agentes en .agents/skills/; packaged copia un directorio de pack (pack-<name>) que contiene sus agentes. doctor lista los archivos de agentes y recursos requeridos que comprueba bmad-plus doctor.
uses_skills
Los ids de habilidades que dirige un pack o un perfil (ver abajo).
external_module
Habilidades tomadas de un paquete npm fijado (ver abajo).
pipelines
Pasos ordenados con una puerta cada uno (ver abajo).
intake
El archivo de cuestionario del pack (ver la página de intake).
governance, required_keys, optional_keys
Para OSINT: la puerta de base legal y sus plantillas, y las claves de API.
cohabitation_warning
Una frase sobre cómo se solapa el pack con otro. La muestra el instalador y se escribe como - Cohabitation (<pack>): ... bajo los datos del registro de la columna y de los adaptadores.
compliance_tags
Marcos normativos con los que se relaciona un pack (por ejemplo GDPR y EU-AI-Act para OSINT).
Un pack o un perfil lista los ids de habilidades que dirige. El generador resuelve cada id: debe ser una habilidad de cualquier pack, de un external_module o de Core, y un id que nadie incluye hace fallar el build. La lista de la columna muestra entonces - drives: design, design-review, redesign tras el perfil, y las instrucciones generadas dicen al agente que lea el SKILL.md de cada habilidad listada antes de actuar. Esta es la declaración real del perfil del pack Design.
Un pack puede tomar sus habilidades de un paquete publicado en vez del árbol de BMAD+. El pack Design es el primero: sus tres habilidades vienen de design-skill, fijado en la versión exacta 0.2.1. El paquete es una dependencia exacta de BMAD+ y figura en la doctrina de tratamiento de datos. En la construcción, el generador resuelve el paquete, comprueba que su versión coincide con la declarada y que existe skills/<id>/SKILL.md para cada habilidad listada. En la instalación, BMAD+ resuelve el paquete desde su propia instalación, rechaza una versión distinta y copia solo el directorio skills/ del paquete en .agents/skills/<id>/ mediante la misma copia gestionada e inventariada por hash que cualquier otro archivo (no se sigue ningún enlace simbólico). El tarball incluye además una herramienta de línea de comandos de enlace que BMAD+ nunca ejecuta. bmad-plus doctor exige los tres SKILL.md; la desinstalación quita las habilidades copiadas con el resto de archivos gestionados.
Un pack puede declarar pipelines: una cadena ordenada de sus propios workflows o agentes, cada paso con una puerta (require_approval, notify_only o auto). Nexus ejecuta un pipeline declarado paso a paso con el comportamiento de punto de control configurado, tras el intake del pack. Los ids de pipeline deben ser únicos en el pack y cada paso nombra exactamente un workflow o un agent que exista en el pack. Ningún pack declara un pipeline en 0.23.0: el campo existe, se valida y lo entiende autopilot, y está para los packs que lo necesiten. El ejemplo es el formato de la especificación, no contenido entregado.
Formato de un pipeline, según la especificación docs/specs/core-orchestration.md (un archivo del repositorio fuente, no incluido en el paquete npm)
.agents/data/role-triggers.yaml gobierna el cambio de rol. La comprobación npm run check:triggers (en el repositorio fuente) lo valida contra el registro: una clave de primer nivel debe ser un nombre corto de agente de Core (strategist, architect-dev, quality, orchestrator) o un id de pack; default_role debe ser uno de los auto_triggers de la clave; cada rol tiene una lista no vacía de patterns; contexts y reasoning, cuando existen, son listas de identificadores en snake_case; bajo una clave de pack, cada id de rol es un id de perfil (persona) o de pipeline de ese pack; y un patrón exacto repetido en dos roles de la misma clave es un error. Tres contextos de Core apuntan a las funciones de esta página: swarm_declared y panel_requested (Parallel Supervisor), y pack_pipeline_declared (autopilot).
Qué se genera y las comprobaciones que lo mantienen honesto#
Comandos en una copia de trabajo fuente de BMAD+
Comando
Qué hace
npm run build
Ejecuta tools/build/generate.js y escribe las definiciones de packs en tools/cli/lib/packs.js y src/bmad-plus/module.yaml a partir del registro.
npm run build:check
Falla cuando el registro ya no reproduce esos dos archivos, cuando product.version difiere de package.json, o cuando una ruta, habilidad, módulo externo o intake declarado es incorrecto.
node tools/build/generate-adapters.js --adopt
Regenera AGENTS.md y los archivos de adaptadores (CLAUDE.md, GEMINI.md, reglas .cursor, archivos .codex y .opencode, CONVENTIONS.md). --check los verifica sin escribir.
npm run check:counts
Recorre las superficies entregadas buscando cifras escritas a mano («N agents», «N workflows», «N packs») y falla ante cualquiera que contradiga lo que derivan el registro y los archivos. Una cifra se comprueba contra su sujeto: 38 es correcto para los workflows de Dev Studio e incorrecto para agentes.
npm run check:triggers
Valida los disparadores de rol como se describió arriba.
Una habilidad es una carpeta con un SKILL.md: una cabecera con un name y una description (que dice cuándo usarla, con palabras que tu asistente pueda reconocer) y luego el procedimiento. El material más largo está en una carpeta ref/ al lado, las plantillas en templates/. Cada agente es también una habilidad: agent-strategist/SKILL.md es Atlas. El anfitrión carga el SKILL.md que necesita, por eso importa la descripción: es lo que hace que un asistente elija la habilidad. Las seis habilidades de Core siguientes se incluyen con cada instalación.
Las habilidades de Core
Habilidad
Qué hace
Dirigida por
bmad-plus-autopilot
Nexus ejecuta Discovery, Build y Ship con puntos de control; primero el intake de cada pack implicado.
Nexus (AP)
bmad-plus-parallel
Detecta tareas independientes y las supervisa (lanzar, seguir, pausar, reiniciar, reasignar, escalar); contiene la sección de enjambres.
Nexus (PL)
bmad-plus-swarm
Protocolo de moderador para enjambres panel, jury y fanout bajo presupuesto.
Nexus Parallel Supervisor
bmad-plus-intake
Protocolo de bmad-plus intake: planificar, hacer unas preguntas, registrar, redactar.
Cualquier pack con intake; autopilot
bmad-plus-uat
Receta de aceptación humana: escribir la especificación, construir la página, leer, clasificar, pasar la puerta.
Sentinel (RB, RR, RG); autopilot
bmad-plus-sync
Protocolo para comprobar el framework instalado una vez por sesión; para mantenedores, lotes para revisar los cambios de origen (sin fusión automática desde el origen).
Cualquiera; mantenedores
Otras habilidades vienen con sus packs: dev-studio (el despachador del pack), las habilidades design, design-review y redesign copiadas de design-skill, las habilidades bmad-osint-investigate y bmad-osint-investigator del pack OSINT. Los packs SEO y Design llevan además un SKILL.md enrutador que reacciona cuando escribes /seo o /design en un mensaje; son palabras clave de petición, no comandos slash registrados por tu cliente.
Maker es el Agent Creator del pack Maker. Diseña un agente contigo en cuatro fases (descubrimiento, diseño con tu validación, generación, validación) y escribe una carpeta lista para integrar en _bmad-output/ready-to-integrate/. Sus capacidades: CA crear un agente, QA agente rápido con menos preguntas, EA editar en el sitio el SKILL.md de un agente existente (sin pasar por esa carpeta), VA validar una carpeta de agente (formato, manifiesto, códigos de capacidad únicos, calidad de los disparadores), PA empaquetar para la integración, TP mostrar la plantilla.
Lo que escribe Maker
Archivo
Contenido
agents/agent-<name>/SKILL.md
El agente: visión general, identidad, estilo de comunicación, principios, tabla de capacidades con códigos de dos letras, pasos de activación.
agents/agent-<name>/bmad-skill-manifest.yaml
Nombre, nombre visible, título, icono, capacidades, rol, identidad, pack, id canónico.
pack-definition.yaml
Un fragmento listo para fusionar con la tabla packs: de registry.yaml (orden, nombre visible, icono, entrada de la CLI, runtime, resumen, agentes, perfiles (personas), habilidades, disposición de instalación, etiquetas de cumplimiento, claves requeridas).
INTEGRATION.md
Instrucciones de integración: archivos por copiar, entrada del registro por añadir, línea del índice de ayuda, secuencia de regeneración y comprobación, una instalación de prueba.
Nota· La nota de integración de Maker sigue el registro
El INTEGRATION.md que escribe Maker empieza por el registro: indica añadir la entrada de pack-definition.yaml bajo packs: en registry.yaml, no editar nunca los archivos que se generan a partir de él (tools/cli/lib/packs.js, los metadatos de pack de src/bmad-plus/module.yaml, AGENTS.md y los demás adaptadores), añadir a mano una línea a src/bmad-plus/module-help.csv, regenerar y ejecutar las comprobaciones de deriva. Los pasos siguientes siguen la misma secuencia.
01
Crear y validar el agente
Pide CA a Maker, responde a sus preguntas de descubrimiento, valida la tabla de diseño y ejecuta VA sobre el resultado.
02
Copiarlo en un clon del repositorio
Coloca la carpeta del agente en src/bmad-plus/agents/ (agente «loose») o en un directorio de pack (pack «packaged»).
03
Declararlo en registry.yaml
Añade o amplía un pack: agents, personas (con uses_skills si dirige habilidades), skills, install_layout, doctor y, si hace falta, intake, pipelines, cohabitation_warning. Añade disparadores de rol en role-triggers.yaml bajo el id del pack si quieres activación automática.
04
Regenerar y comprobar
Ejecuta npm run build, node tools/build/generate-adapters.js --adopt, luego npm run build:check, npm run check:counts y npm run check:triggers. Cada fallo nombra el campo que corregir.
05
Instalarlo en un proyecto desechable
Ejecuta el instalador desde tu clon con --packs core,<your-pack> y luego doctor: no debe informar de ningún error. El contrato de instalación del repositorio (npm run test:install-contract) comprueba lo mismo para cada pack.
En un proyecto instalado, sin clon, puedes igualmente poner tus propias carpetas de habilidades en .agents/skills/. BMAD+ trata los archivos que no instaló como tuyos: bmad-plus doctor los señala como sin propietario (una advertencia, no un error), y la actualización y la desinstalación los dejan en su sitio. No están inscritos en la lista de agentes, así que la columna no los menciona; añade una línea a tu propio archivo de instrucciones o al adaptador si quieres que el asistente los encuentre.
Úsalo con el pack Maker instalado. La carpeta se escribe en _bmad-output/ready-to-integrate/; no se cambia nada más.
En tu asistente de IA
Maker, crea un agente de soporte al cliente para nuestro equipo: clasifica los tickets entrantes, redacta respuestas con nuestro tono y escala a una persona lo relativo a facturación. Hazme tus preguntas de descubrimiento en un solo lote, enséñame la tabla de diseño (nombre, roles, capacidades con códigos de dos letras, disparadores, dependencias) y espera mi validación antes de generar. Luego valida la carpeta y dime qué queda por declarar en el registro.
Lo que deberías obtener Un lote de preguntas, una vista previa del diseño que apruebas y luego _bmad-output/ready-to-integrate/ con el SKILL.md del agente, su manifiesto, un fragmento de pack y una nota de integración, seguidos de la lista de validación (formato, campos del manifiesto, códigos de capacidad únicos, calidad de los disparadores). No se instala ni se registra nada hasta que tú lo hagas.