Glosario
Cada término de la documentación de BMAD+ en palabras sencillas, por tema: anfitrión, pack, habilidad, intake, enjambre, semilla, puerta, recibo, receta y estados.
En esta página
- Arquitectura
- Archivos y ciclo de vida
- Intake y enjambres
- Orquestación
- Revisión y aceptación
- Memoria y packs especializados
- Palabras de estado que imprimen las herramientas
Las tablas se agrupan por tema y no alfabéticamente, para que las palabras relacionadas queden juntas. Los nombres de agentes, comandos, opciones, archivos y las palabras de estado que imprimen las herramientas (como needs-approval) se quedan en inglés en todos los idiomas, porque es lo que verás en pantalla. La columna de la derecha remite a la página que explica el término en contexto.
Arquitectura#
Términos de arquitectura| Término | Significado | Más información |
|---|
| anfitrión (host) | La herramienta de programación con IA que lee las instrucciones y hace el trabajo con su propio modelo y permisos: Claude Code, Cursor, Codex CLI y otras. | Cómo funciona BMAD+ |
|---|
host-managed | El contrato de ejecución de BMAD+: el anfitrión aporta el modelo, los permisos y los posibles subagentes; BMAD+ no llama a ningún modelo ni ejecuta nada en segundo plano. | Cómo funciona BMAD+ |
|---|
| columna (spine) | AGENTS.md, el único archivo de instrucciones generado que leen todas las herramientas: lista de agentes, habilidades, reglas de memoria y datos del registro. | Cómo funciona BMAD+ |
|---|
| adaptador | Un archivo corto generado, en el formato que espera una herramienta (CLAUDE.md, GEMINI.md, una regla de Cursor, ...), que remite a la columna. | Adaptadores |
|---|
| pack | Un grupo de agentes, habilidades y workflows que se instalan juntos. Hay diez; Core es obligatorio. | Todos los paquetes |
|---|
| agente | Una persona con nombre a la que te diriges en el chat («Forge, ...»). 48 entre los packs, 15 de ellos puntos de entrada del instalador. | La lista de agentes |
|---|
| rol | Un modo dentro de un agente, como Analista o Product Manager para Atlas. El cambio se pide o es automático y siempre se anuncia. | Cómo se activan los roles |
|---|
| perfil (persona) | La identidad con nombre de un agente, con su nombre, rol y descripción, tal como se declara en el registro. | Registro y skills |
|---|
| habilidad (skill) | Una carpeta con un SKILL.md que el anfitrión carga cuando hace falta: un procedimiento como autopilot, intake o swarm. Cada agente es también una habilidad. | Registro y skills |
|---|
| workflow | Un procedimiento en Markdown, paso a paso, en un pack, ejecutado por tu asistente. Dev Studio tiene 38 y Shield 11. | Dev Studio |
|---|
| registro (registry) | registry.yaml, la fuente única de verdad del repositorio fuente de la que se generan packs, listas, cifras y adaptadores. | Registro y skills |
|---|
| CLI | La herramienta de línea de comandos bmad-plus: contabilidad determinista sobre archivos locales. No llama a ningún modelo y requiere Node.js 20 o superior. | Referencia de la línea de comandos |
|---|
| instrucción de chat | Una frase para tu asistente, como bmad-help, autopilot o parallel. No es un comando de terminal. | Cómo funciona BMAD+ |
|---|
Archivos y ciclo de vida#
Términos de archivos y ciclo de vida| Término | Significado | Más información |
|---|
| manifiesto | _bmad/.bmad-plus-install.json: versión, packs, herramientas y el SHA-256 de cada archivo instalado. | Confianza y propiedad |
|---|
| inventario de propiedad | El fileInventory del manifiesto. Un archivo es de BMAD+ mientras coincide con su hash; una vez editado, es tuyo. Su estado es complete, incomplete, legacy o invalid. | Confianza y propiedad |
|---|
| recibo (receipt) | El registro de una actualización aplicada en .bmad/updates/<id>/receipt.json, con copias de seguridad, que usa update --restore. | Instalar, actualizar, desinstalar |
|---|
| política de actualización | _bmad/update-policy.json: off, notify (por defecto) o auto con un rango de versiones explícito, más los ajustes de canal y preversiones. | Usar BMAD+ en equipo |
|---|
| punto de control (checkpoint) | Una parada en una ejecución de autopilot, fijada por etapa (discovery, architecture, story, delivery) en require_approval, notify_only o auto. | Nexus |
|---|
| modo de ejecución | manual (llamas a cada agente), autopilot (Nexus gestiona el pipeline) o hybrid (autopilot con puntos de control frecuentes). | Referencia: config.yaml |
|---|
| entregable | Un archivo que produce un agente, normalmente bajo _bmad-output/: un brief, un PRD, una arquitectura, historias, una revisión, un informe. | Tu primera hora |
|---|
| modo solo prompts | Cómo funciona el pack SEO sin un entorno de Python utilizable: el agente sigue sus prompts, marca las categorías no verificadas y no calcula ninguna puntuación global. | El paquete SEO |
|---|
Intake y enjambres#
Términos de intake y enjambre| Término | Significado | Más información |
|---|
| intake (cuestionario de entrada) | La lista de preguntas que un pack necesita ver respondidas antes de actuar, definida en un intake.yaml y dirigida por bmad-plus intake. | Intake |
|---|
| imprescindible (must-have) | Una pregunta sin la cual el pack no puede empezar: debe estar respondida o marcada como desconocida con su riesgo. No puede llevar valor por defecto. | Intake |
|---|
answered, defaulted, unknown | Los tres estados de una respuesta de intake: lo dijiste tú; mantuviste el valor por defecto propuesto; no lo sabes (se copia el riesgo). | Intake |
|---|
| brief | Dos sentidos. Un brief de intake es el Markdown que redacta la CLI a partir de las respuestas, el contrato de los siguientes pasos del pack. Un brief de enjambre es el archivo que un subagente lee como toda su instrucción. | Intake |
|---|
| enjambre (swarm) | Muchos subagentes que hacen cada uno una vez el mismo tipo de trabajo, dirigidos por bmad-plus swarm: un panel, un jurado o una dispersión. | Enjambres |
|---|
| subagente | Una sesión de trabajo lanzada por el anfitrión, una por brief. BMAD+ nunca la inicia; lo hace el moderador, a través del anfitrión. | Enjambres |
|---|
panel, jury, fanout | Los tres tipos de enjambre: unidades repartidas desde un perfil; unidades listadas con una lente cada una; unidades suministradas con ámbitos de escritura disjuntos. | Enjambres |
|---|
| unidad, ficha (card) | Una unidad es un miembro de un enjambre. Su ficha son sus datos (segmento, edad, objeción, lente, ámbito), repartidos o listados en el init y congelados para la ejecución. | Enjambres |
|---|
| perfil, definición, plantilla, contexto | Las cuatro entradas de un enjambre: la distribución del panel; el JSON que declara tipo, forma de respuesta y recuento; la plantilla de brief; y el texto que leen las unidades (un argumentario, por ejemplo), incluido literalmente. | Enjambres |
|---|
| semilla (seed) | Un número de 0 a 2147483647 que hace reproducible el reparto: mismo perfil, mismo --n, misma semilla, mismas fichas. | Enjambres |
|---|
| presupuesto, oleada | swarm.budget (26) es cuántos subagentes puede usar una ejecución antes de que una persona deba decir sí; swarm.wave (10) cuántos se lanzan juntos. | Enjambres |
|---|
| aprobación | El sí humano que permite una ejecución por encima del presupuesto. Se registra con --approved; el asistente no debe pasarlo por su cuenta. | Enjambres |
|---|
| aviso de transparencia (disclosure) | La frase que abre cada recuento, como «Simulated units are not people». Se informa una vez, antes de cualquier cifra. | Enjambres |
|---|
| recuento (tally) | tally.json y tally.md, calculados solo sobre respuestas válidas, con las unidades omitidas nombradas y el denominador visible. | Enjambres |
|---|
| respuesta válida | Un archivo de respuesta bien formado: id correcto, todos los campos obligatorios, ningún campo no declarado, tipos y límites respetados. Válida significa bien formada, no verdadera. | Enjambres |
|---|
Orquestación#
Términos de Nexus| Término | Significado | Más información |
|---|
| autopilot | El modo de Nexus que ejecuta Discovery, Build y Ship con puntos de control. Se inicia diciendo autopilot en el chat. | Nexus |
|---|
| ejecución de Nexus (run) | Un grafo de tareas duradero y sus intentos, guardado en .bmad-plus/nexus/runs/, creado a partir de un plan. | Nexus |
|---|
| plan | El archivo JSON que escribes para nexus create: tareas con objetivo, ámbito, artefactos, recursos, comprobaciones y límites. | Nexus |
|---|
| tarea, intento | Una tarea es un nodo del plan. Un intento es una prueba de esa tarea, ligada a una identidad (sesión del anfitrión o proceso supervisado). | Nexus |
|---|
| ámbito de escritura (scope) | Los archivos o carpetas que una tarea puede escribir. Los ámbitos son exclusivos y disjuntos entre tareas. | Nexus |
|---|
| recurso | Una entrada protegida de una tarea (instrucciones, un verificador) a la que Nexus aplica un hash y que debe quedar fuera de cualquier ámbito de escritura. | Nexus |
|---|
| ejecución, verificación, aceptación | Los tres resultados separados de una tarea: alguien hizo el trabajo; pasaron comprobaciones independientes; se aceptó el espacio de trabajo actual. Cada uno puede estar pendiente, superado, fallido o ambiguo sin implicar el siguiente. | Nexus |
|---|
| reconciliar (reconcile) | Cerrar un intento incierto con una observación de operador (propietario detenido, reintento seguro o no). Necesario antes de un reintento. | Nexus |
|---|
| backend de procesos, supervisor | La forma opcional de ejecutar una tarea como comando local o llamada a Codex CLI. El supervisor es el proceso en primer plano que la lanzó y el único que puede enviar señales a su proceso hijo. | Nexus |
|---|
Revisión y aceptación#
Términos de revisión y aceptación| Término | Significado | Más información |
|---|
| ámbito de revisión (scope) | La lista sellada y con hash de los archivos que una revisión debe cubrir, con un motivo nombrado para cada archivo excluido. La escribe review scope. | Revisión y aceptación |
|---|
| hallazgo (finding), anclaje (anchor) | Un hallazgo es un problema notificado con el código que cita. El anclaje localiza esa cita en el archivo (located, ambiguous o unlocated); nunca se confía en el número de línea de un modelo. | Revisión y aceptación |
|---|
| cobertura (coverage) | coverage.json: para cada archivo seleccionado, completed, failed o waived con un motivo. De ahí se deriva el veredicto. | Revisión y aceptación |
|---|
| puerta (gate) | Un comando cuyo código de salida es un veredicto: review gate (0 clean, 1 findings, 2 incomplete), uat gate (0 passed, 1 failed, 2 awaiting, 3 stale), assurance verify. | Revisión y aceptación |
|---|
| esfuerzo | --effort low|medium|high: el número de pasadas de revisión (1, 2 o 3) y si cada hallazgo se cuestiona con un paso de refutación (no en low). Que el revisor planifique antes la lectura depende del tamaño del cambio, no del esfuerzo. | Revisión y aceptación |
|---|
| regla de revisión | Una instrucción en Markdown ligada a patrones de ruta; ocho vienen con BMAD+, Shield añade seis de cumplimiento y un proyecto añade las suyas en _bmad/review-rules.yaml. | Revisión y aceptación |
|---|
| receta de aceptación (recette) | Una página autónoma que una persona recorre paso a paso para confirmar una entrega en pantalla. El comando es bmad-plus uat (alias recette). | Revisión y aceptación |
|---|
| testigo (witness) | Aquello en lo que se apoya una receta (un registro, un archivo, un estado), declarado con la consulta de solo lectura que demuestra su estado. | Revisión y aceptación |
|---|
| ejecución (run), clasificación (triage) | Una ejecución (run) son las respuestas de un probador en JSON. La clasificación asigna a cada fallo product, recipe, data o undecided, con una decisión. | Revisión y aceptación |
|---|
human-observed | La etiqueta de la evidencia de aceptación: una persona lo vio. La puerta establece que la ejecución está completa, vigente y clasificada, no que el probador mirara en el lugar correcto. | Revisión y aceptación |
|---|
Memoria y packs especializados#
Términos de memoria y packs| Término | Significado | Más información |
|---|
| cerebro (brain) | Una carpeta de memoria compartida fuera de un proyecto: el cerebro global ~/.bmad-plus/brain/, un _brain/ de cartera o la carpeta de memoria de Claude. Un proyecto se enlaza a ella; nunca se copia. | Memoria |
|---|
| traspaso (handoff) | Una nota fechada en .agents/memory/sessions/ que resume lo hecho, decidido y pendiente, para que una sesión en frío pueda retomar. | Memoria |
|---|
| reglas de conducta G1 a G4 | Cuatro reglas de conducta en las instrucciones de cada agente: pensar antes de programar, simplicidad primero, cambios quirúrgicos, ejecución guiada por el objetivo. | Memoria |
|---|
| Atelier, design read, ajustes (dials) | Atelier es el agente de diseño. El design read es su intake. Los ajustes (variance, motion, density, de 1 a 10) afinan el diseño; uno que se deja abierto se infiere de la superficie y se anota como inferido. | El paquete Design |
|---|
| puerta de base legal (fase menos 1) | La regla OSINT según la cual una operación sobre una persona con nombre exige antes un propósito, una base legal, una retención y una vía de supresión registrados. Sin ellos, el agente rechaza. | Confianza y propiedad |
|---|
| grado de confianza (A a D) | La calificación de Shadow para un hecho: A tres fuentes o más, B dos, C una, D sin verificar. | El paquete OSINT |
|---|
| caso de aseguramiento, registro (ledger) | Las herramientas de evidencia de Shield: afirmaciones, cada una respaldada por una comprobación ejecutada; un registro encadenado por hash runs.jsonl anota las ejecuciones. Una afirmación es supported o unsupported; passed, failed, stale y missing son los estados de una comprobación. | El paquete Shield |
|---|
| controles (controls) | Referencias de cumplimiento escritas FRAMEWORK:ID, como ISO27001:A.8.5 o GDPR:Art.32. Se rechaza un control desconocido o mal escrito. | El paquete Shield |
|---|
Palabras de estado que imprimen las herramientas#
Palabras de estado y su significado| Palabra | Impresa por | Significado |
|---|
ready / not ready | intake plan | Cada imprescindible está respondido o desconocido con su riesgo / sigue abierto un imprescindible (salida 2). |
|---|
needs-approval | swarm init | La ejecución supera el presupuesto y no se ha aprobado (salida 2); no se escribió ningún brief. |
|---|
missing / invalid | swarm check | Sin archivo de respuesta para una unidad / un archivo de respuesta que no pasa la validación, con los motivos. |
|---|
incomplete / findings / clean | review gate | Faltan evidencias o la revisión se detuvo (2) / hallazgos abiertos en un ámbito cubierto (1) / ninguno en un ámbito cubierto (0). |
|---|
passed / failed / awaiting / stale | uat gate | Ejecución terminada, vigente y clasificada (0) / fallida (1) / sin ejecución terminada (2) / la ejecución respondió a otra revisión (3). |
|---|
not started / running / completed | nexus summary | El estado de ejecución de una tarea; verification y acceptance se muestran por separado como pending, passed, failed o accepted. |
|---|
unknown / off / notify / auto | update-check, update-policy | Última versión no establecida (sin conexión, obsoleta) / consultas detenidas / solo informar / aplicar dentro de un rango explícito. |
|---|
ok / warning / error | doctor | Sano / un archivo modificado o sin propietario, notificado / un archivo requerido que falta o es ilegible (salida 1). |
|---|