# El registro y las habilidades

> 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.

Canonical: https://bmad-plus.rochetta.fr/es/docs/concepts/registry-and-skills/
Language: es
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentación de BMAD+ › [Conceptos](https://bmad-plus.rochetta.fr/es/docs/concepts/) › El registro y las habilidades

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+.

<a id="what-it-declares"></a>
## Qué declara el registro

**Secciones de primer nivel de registry.yaml**

| Sección | Contenido |
| --- | --- |
| `product` | 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). |

<a id="uses-skills"></a>
## uses_skills: lo que dirige un agente

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.

**registry.yaml, pack design (extracto)**

```yaml
  design:
    order: 9
    display_name: "Design"
    required: false
    runtime: [node]
    agents: [design-engine]
    personas:
      - { id: design-engine, name: Atelier, role: Design Engine, description: "Senior product designer and design engineer: surfaces, tokens, accessibility, audits, redesigns", uses_skills: [design, design-review, redesign] }
    skills: []
    external_module: { package: design-skill, version: "0.2.1", skills: [design, design-review, redesign] }
    pack_dir: pack-design
    install_layout: packaged
    doctor:
      pack_agents: [design-engine.md]
      required_resources: [SKILL.md]
    intake: intake.yaml
    cohabitation_warning: "Overlaps Sentinel's UX-review role and Dev Studio's Rachel (UX Designer); ..."
```

<a id="external-module"></a>
## external_module: habilidades de un paquete npm

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.

<a id="pipelines"></a>
## pipelines: pasos ordenados con una puerta

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)**

```yaml
pipelines:
  - id: full-build
    title: From interview to private preview
    steps:
      - { workflow: discovery, gate: require_approval }
      - { workflow: positioning, gate: require_approval }
      - { agent: brandsite-art, gate: notify_only }
      - { workflow: preview, gate: require_approval }
```

<a id="triggers"></a>
## Disparadores que deben apuntar a cosas reales

`.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).

<a id="generated"></a>
## 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. |

<a id="skills-anatomy"></a>
## Qué es una habilidad

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.

<a id="extend-with-maker"></a>
## Añadir un agente o un pack con Maker

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.

1. **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.
2. **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»).
3. **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.
4. **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.
5. **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.

<a id="example-registry-ask-maker-agent"></a>
### Diseñar un agente de equipo con Maker

Ú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**

```text
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.

**Véase también**

- [Cómo funciona BMAD+](https://bmad-plus.rochetta.fr/es/docs/concepts/how-bmad-plus-works/)
- [Intake: preguntar primero](https://bmad-plus.rochetta.fr/es/docs/concepts/intake/)
- [El pack Maker](https://bmad-plus.rochetta.fr/es/docs/packs/maker/)
- [El pack Design](https://bmad-plus.rochetta.fr/es/docs/packs/design/)
- [Referencia: adaptadores](https://bmad-plus.rochetta.fr/es/docs/reference/adapters/)
- [Tratamiento de datos](https://bmad-plus.rochetta.fr/es/docs/security/data-handling/)

[Documentación de BMAD+](https://bmad-plus.rochetta.fr/es/docs/) · [Conceptos](https://bmad-plus.rochetta.fr/es/docs/concepts/)

[Código en GitHub](https://github.com/lrochetta/BMAD-PLUS)