magnus919/agent-skills

BMad: Protocolo de Plano de Control de Intención a Entrega

BMad es un método de entrega de software construido sobre una idea: la intención humana debe ser progresivamente clarificada, registrada, revisada y entregada a los agentes como contexto duradero en lugar de improvisada en el chat. Esta habilidad convierte ese método en un protocolo que cualquier arnés de agente puede seguir, sin necesidad de instalador oficial de BMad.

El ciclo: clasificar la solicitud → comprimir la intención en un contrato → enrutar a la ruta segura más pequeña → implementar una unidad acotada → revisar como triaje → enrutar el fracaso a la capa donde entró la ambigüedad → controlar la autonomía mediante la aceptación observable → aprender del trabajo completado.

Cuándo usar esta habilidad

Cargar cuando una solicitud de cambio, funcionalidad, informe de error, construcción delegada o épica multiagente necesite:

• captura de intención antes de la implementación: un contrato, no una vibración;
• una decisión sobre cuánta ceremonia merece el trabajo;
• artefactos duraderos para que el trabajo sea reanudable entre sesiones o agentes;
• revisión que tria los hallazgos en lugar de enumerar ruido;
• autonomía que se detiene de forma segura cuando el límite es inseguro.

Clasificación del trabajo (ruta segura más pequeña)

Clase	Forma	Proceso
Directo	objetivo claro, cambio local, patrones establecidos, radio de explosión pequeño	implementar inmediatamente después de una aclaración mínima
Acotado	cambio coherente que necesita un contrato corto y un plan	contrato de intención → plan → implementar → revisar
Iniciativa	entre componentes, multi-historia, alto riesgo o estratégicamente incierto	análisis → planificación → solución → implementación → aprendizaje

Cargar references/classification.md para la tabla de decisiones, la regla de una pregunta y las condiciones de parada.

El contrato de intención (cinco campos)

Para trabajo acotado o de iniciativa, establecer un contrato antes de la implementación:

1. Por qué — el resultado y por qué es importante.
2. Capacidades — lo que el sistema debe poder hacer.
3. Restricciones — límites técnicos, operativos, legales, de seguridad, privacidad, tiempo, costo, organizativos.
4. No-objetivos — lo que está explícitamente fuera del alcance.
5. Señal de éxito — cómo sabremos que el resultado funciona y es aceptable.

Si un campo es materialmente ambiguo, hacer una pregunta de alto apalancamiento, proponer una respuesta recomendada y esperar la decisión. Para cambios triviales, el contrato puede ser cinco viñetas en la conversación; para trabajos más grandes, se convierte en un archivo de especificación versionado.

Cargar references/spec.md para la redacción de SPEC y el vocabulario de estados. Plantillas: templates/SPEC.md y templates/INTENT.md.

El ciclo canónico

1. Inspeccionar el repositorio y el contexto disponible antes de preguntar nada.
2. Clasificar el trabajo; indicar la ruta propuesta.
3. Establecer o reanudar el contrato de intención; hacer como máximo una pregunta material.
4. Presentar un plan para trabajo no trivial; esperar en el punto de control de aprobación.
5. Implementar el cambio coherente más pequeño; ejecutar primero pruebas enfocadas, luego comprobaciones más amplias.
6. Revisar corrección, alcance, seguridad, regresiones, mantenibilidad.
7. Reparar los hallazgos que pertenecen a este cambio; diferir explícitamente los hallazgos no relacionados.
8. Informar intención, comportamiento, archivos, riesgo, verificación, disposición de hallazgos y una opción de aceptar / reelaborar / investigar.

Vocabulario de estados de SPEC

Estado legible por máquina para trabajo reanudable:

Estado	Significado
borrador	La especificación existe pero no está lista
listo-para-desarrollo	Pasó la preparación; listo para implementar
en-progreso	Implementación en curso
en-revisión	Revisión o triaje en curso
hecho	Flujo de trabajo completado con éxito
bloqueado	No se puede continuar de forma segura sin supervisión

bloqueado es una señal de enrutamiento, no un fracaso: un orquestador de nivel superior, otro flujo de trabajo o un humano toman el control. Validar una especificación de forma determinista con scripts/check-spec.py.

Enrutamiento de fallos

Cuando algo está mal, diagnosticar la capa donde entró el fallo:

Fallo	Ruta
Resultado incorrecto o problema incorrecto	intención / análisis
Requisito faltante o contradictorio	contrato / planificación
Enfoque técnico conflictivo	arquitectura
Código local incorrecto	implementación
Prueba o evaluación insuficiente	verificación
Problema preexistente no relacionado	diferir explícitamente
Ambigüedad insegura	bloquear y preguntar

No seguir parcheando código cuando la especificación es el problema real.

Puerta de autonomía

La ejecución autónoma solo está permitida cuando se cumplen todas estas condiciones: contrato de intención coherente, aceptación observable, límite explícito, repositorio seguro de modificar, pruebas o evaluaciones ejecutables, estado duradero escribible, escalamiento definido. Durante el trabajo autónomo: un cambio coherente a la vez; nunca expandir el alcance con mejoras no relacionadas; nunca fusionar, desplegar o cambiar sistemas externos sin autorización; detenerse en vacíos de intención, capacidad faltante, ambigüedad destructiva, verificación fallida o reparación no convergente.

Archivos de referencia

Referencia	Cargar cuando
references/protocol.md	Necesitas el protocolo operativo completo listo para pegar para un agente
references/classification.md	Clasificar una solicitud o elegir la profundidad de ceremonia
references/spec.md	Escribir o reanudar un SPEC / contrato de intención
references/lifecycle.md	Ejecutar una iniciativa a través de las cuatro fases
references/project-context.md	Configurar o auditar reglas del repositorio (AGENTS.md)
references/review-and-failure-routing.md	Ejecutar una revisión o diagnosticar un fallo
references/autonomy.md	Configurar o ejecutar trabajo autónomo (Build Auto)
references/party-mode.md	Deliberación, compensaciones, debates de diseño, autopsias
references/adoption.md	Adoptar el protocolo incrementalmente o mapear a una fábrica oscura

Plantillas

Plantilla	Propósito
templates/SPEC.md	Contrato de máquina versionado para trabajo acotado/de iniciativa
templates/INTENT.md	Contrato ligero de cinco campos para trabajo acotado
templates/STORY.md	Una unidad de trabajo acotada y despachable
templates/REVIEW.md	Punto de control humano final: intención → comportamiento → riesgo → verificación

Scripts

Script	Cuándo ejecutar
scripts/check-spec.py	Después de escribir o editar una especificación: validar cinco campos + vocabulario de estados (solo stdlib, salida --json)

Enrutamiento a habilidades adyacentes

• Río arriba (antes de BMad): product-discovery valida si un problema es real; product-shaping establece un apetito y produce un pitch; product-strategy y product-roadmapping-and-portfolio enmarcan el contexto estratégico.
• Río abajo (durante BMad): spec-driven-development para tuberías formales de especificaciones/puertas; implementation-planning para un plan de entrega consciente de dependencias; adr-authoring para decisiones de arquitectura; software-architecture-analysis para ingeniería inversa de un código base existente.
• Ejecución y puertas: neckbeard para el flujo de entrega de incidencia a PR; verification-methodology para evidencia de aceptación; qa-methodology para estrategia de prueba; agent-evals-and-observability para evaluadores independientes; agent-council para deliberación multiagente estilo Party Mode; release-engineering para puertas de despliegue; kanban-guru para políticas de backlog y despacho.

Cuándo no usar

• El problema en sí no está validado → product-discovery. BMad comprime la intención; no establece si el problema es real.
• Aún no se ha decidido cuánto vale el trabajo → primero product-shaping (apetito, pitch, apuesta). BMad parte de una intención colocada.
• Necesitas un formato de especificación formal más puertas de fase como tubería de fábrica → spec-driven-development posee el formato SPEC y la mecánica de puertas; BMad proporciona el protocolo de plano de control a su alrededor.
• Estás ejecutando un flujo de entrega de incidencia a PR con sus propias puertas → neckbeard. BMad lo complementa; no ejecutes dos ciclos de vida de entrega en competencia.
• Necesitas revisión independiente → el juego de roles no es independencia. Usa agent-council, evaluadores separados o agent-evals-and-observability; nunca afirmes que la separación de personas es revisión independiente.
• Operar el instalador/herramientas oficiales de BMad → esta habilidad emula el método; no instala ni opera paquetes npm de bmad-method.

Deriva de versión y atribución

BMad está en evolución activa (repositorio oficial: bmadcode/bmad-method; BMAD™ y BMAD-METHOD™ son marcas comerciales de BMad Code, LLC). Los artículos más antiguos difieren en la expansión del nombre, agentes, nombres de archivos y comandos. Al instalar las herramientas oficiales, tratar la documentación oficial y la fuente instalada como autoritativas. Esta habilidad es una destilación original del método como un protocolo independiente del arnés; no reproduce contenido oficial del instalador.