magnus919/agent-skills

BMad : Protocole de plan de contrôle de l'intention à la livraison

BMad est une méthode de livraison logicielle construite sur une idée : l'intention humaine doit être progressivement clarifiée, enregistrée, revue et transmise aux agents sous forme de contexte durable plutôt qu'improvisée dans un chat. Cette compétence transforme cette méthode en un protocole que tout environnement d'agents peut suivre — sans nécessiter d'installateur officiel BMad.

La boucle : classifier la demande → compresser l'intention en un contrat → router vers le chemin le plus petit et le plus sûr → implémenter une unité bornée → réviser comme un triage → router l'échec vers la couche où l'ambiguïté est entrée → conditionner l'autonomie à une acceptation observable → apprendre du travail terminé.

Quand utiliser cette compétence

Charger lorsqu'une demande de changement, une fonctionnalité, un rapport de bug, une construction déléguée ou un epic multi-agents nécessite :

• une capture d'intention avant l'implémentation — un contrat, pas une ambiance ;
• une décision sur le niveau de cérémonie que le travail mérite ;
• des artefacts durables pour que le travail soit reprenable entre sessions ou agents ;
• une revue qui trie les constats au lieu d'énumérer du bruit ;
• une autonomie qui s'arrête en toute sécurité lorsque la frontière n'est pas sûre.

Classification du travail (chemin le plus petit et le plus sûr)

Classe	Forme	Processus
Direct	objectif clair, changement local, schémas établis, petit rayon d'impact	implémenter immédiatement après clarification minimale
Borné	changement cohérent nécessitant un court contrat et un plan	contrat d'intention → plan → implémenter → réviser
Initiative	inter-composant, multi-story, haut risque ou stratégiquement incertain	analyse → planification → solution → implémentation → apprentissage

Charger references/classification.md pour la table de décision, la règle de la question unique et les conditions d'arrêt.

Le contrat d'intention (cinq champs)

Pour un travail borné ou une initiative, établir un contrat avant l'implémentation :

1. Pourquoi — le résultat et pourquoi il est important.
2. Capacités — ce que le système doit être capable de faire.
3. Contraintes — techniques, opérationnelles, légales, sécurité, confidentialité, temps, coût, limites organisationnelles.
4. Non-objectifs — ce qui est explicitement hors scope.
5. Signal de succès — comment nous saurons que le résultat fonctionne et est acceptable.

Si un champ est matériellement ambigu, poser une question à fort impact, proposer une réponse recommandée et attendre la décision. Pour les changements triviaux, le contrat peut être cinq points dans la conversation ; pour un travail plus conséquent, il devient un fichier de spécification versionné.

Charger references/spec.md pour la rédaction de SPEC et le vocabulaire des statuts. Modèles : templates/SPEC.md et templates/INTENT.md.

La boucle canonique

1. Inspecter le dépôt et le contexte disponible avant de demander quoi que ce soit.
2. Classifier le travail ; indiquer la voie proposée.
3. Établir ou reprendre le contrat d'intention ; poser au plus une question matérielle.
4. Présenter un plan pour un travail non trivial ; attendre au point de contrôle d'approbation.
5. Implémenter le plus petit changement cohérent ; exécuter d'abord les tests ciblés, puis les vérifications plus larges.
6. Réviser pour la correction, la portée, la sécurité, les régressions, la maintenabilité.
7. Corriger les constats qui appartiennent à ce changement ; reporter explicitement les constats non liés.
8. Rapporter l'intention, le comportement, les fichiers, les risques, la vérification, le traitement des constats, et un choix accepter / retravailler / investiguer.

Vocabulaire des statuts de SPEC

Statut lisible par machine pour un travail reprenable :

Statut	Signification
draft	La SPEC existe mais n'est pas prête
ready-for-dev	A passé la validation de préparation ; prête à implémenter
in-progress	Implémentation en cours
in-review	Revue ou triage en cours
done	Workflow terminé avec succès
blocked	Impossible de continuer en toute sécurité sans aide

blocked est un signal de routage, pas un échec : un orchestrateur de plus haut niveau, un autre workflow ou un humain prend le relais. Valider une SPEC de manière déterministe avec scripts/check-spec.py.

Routage des échecs

Quand quelque chose ne va pas, diagnostiquer la couche où l'échec est entré :

Échec	Route
Mauvais résultat ou mauvais problème	intention / analyse
Exigence manquante ou contradictoire	contrat / planification
Approche technique conflictuelle	architecture
Code local incorrect	implémentation
Test ou évaluation insuffisant(e)	vérification
Problème préexistant non lié	reporter explicitement
Ambiguïté dangereuse	bloquer et demander

Ne pas continuer à corriger le code quand la spécification est le vrai problème.

Porte d'autonomie

L'exécution autonome n'est autorisée que lorsque toutes ces conditions sont remplies : contrat d'intention cohérent, acceptation observable, frontière explicite, dépôt sûr à modifier, tests ou évaluations exécutables, statut durable inscriptible, escalade définie. Pendant le travail autonome : un changement cohérent à la fois ; ne jamais étendre la portée sur des améliorations non liées ; ne jamais fusionner, déployer ou modifier des systèmes externes sans autorisation ; s'arrêter en cas de lacune d'intention, de capacité manquante, d'ambiguïté destructrice, d'échec de vérification ou de réparation non convergente.

Fichiers de référence

Référence	Charger quand
references/protocol.md	Vous avez besoin du protocole opérationnel complet prêt à coller pour un agent
references/classification.md	Classifier une demande ou choisir la profondeur de cérémonie
references/spec.md	Rédiger ou reprendre une SPEC / un contrat d'intention
references/lifecycle.md	Exécuter une initiative à travers les quatre phases
references/project-context.md	Configurer ou auditer les règles du dépôt (AGENTS.md)
references/review-and-failure-routing.md	Effectuer une revue ou diagnostiquer un échec
references/autonomy.md	Configurer ou exécuter un travail autonome (Build Auto)
references/party-mode.md	Délibération, compromis, débats de conception, post-mortems
references/adoption.md	Adopter le protocole de manière incrémentale ou le mapper à une dark factory

Modèles

Modèle	Objectif
templates/SPEC.md	Contrat machine versionné pour un travail borné / initiative
templates/INTENT.md	Contrat léger à cinq champs pour un travail borné
templates/STORY.md	Une unité de travail bornée et expédiable
templates/REVIEW.md	Point de contrôle humain final : intention → comportement → risque → vérification

Scripts

Script	Quand l'exécuter
scripts/check-spec.py	Après avoir écrit ou modifié une spec : valider cinq champs + vocabulaire des statuts (stdlib uniquement, sortie --json)

Routage vers les compétences adjacentes

• En amont (avant BMad) : product-discovery valide si un problème est réel ; product-shaping définit un appétit et produit un pitch ; product-strategy et product-roadmapping-and-portfolio cadrent le contexte stratégique.
• En aval (pendant BMad) : spec-driven-development pour les pipelines formels de spec/gate ; implementation-planning pour un plan de livraison avec dépendances ; adr-authoring pour les décisions d'architecture ; software-architecture-analysis pour le reverse engineering d'une base de code existante.
• Exécution et portes : neckbeard pour le flux de livraison issue-to-PR ; verification-methodology pour les preuves d'acceptation ; qa-methodology pour la stratégie de test ; agent-evals-and-observability pour les évaluateurs indépendants ; agent-council pour la délibération multi-agents en mode Party Mode ; release-engineering pour les portes de déploiement ; kanban-guru pour la politique de backlog et de dispatch.

Quand ne pas utiliser

• Le problème lui-même n'est pas validé → product-discovery. BMad compresse l'intention ; il n'établit pas si le problème est réel.
• Aucune décision encore sur la valeur du travail → product-shaping d'abord (appétit, pitch, pari). BMad part d'une intention placée.
• Vous avez besoin d'un format de spécification formel avec des portes de phase comme pipeline d'usine → spec-driven-development possède le format SPEC et les mécanismes de porte ; BMad fournit le protocole de plan de contrôle autour d'eux.
• Vous exécutez un flux de livraison issue-to-PR avec ses propres portes → neckbeard. BMad le complète ; n'exécutez pas deux cycles de vie de livraison concurrents.
• Vous avez besoin d'une revue indépendante → le jeu de rôle n'est pas de l'indépendance. Utilisez agent-council, des évaluateurs séparés ou agent-evals-and-observability ; ne prétendez jamais qu'une séparation de persona constitue une revue indépendante.
• Vous utilisez l'installateur/outillage officiel BMad → cette compétence émule la méthode ; elle n'installe ni n'exploite les packages npm bmad-method.

Dérive de version et attribution

BMad évolue activement (dépôt officiel : bmadcode/bmad-method ; BMAD™ et BMAD-METHOD™ sont des marques commerciales de BMad Code, LLC). Des articles plus anciens diffèrent sur le développement du nom, les agents, les noms de fichiers et les commandes. Lors de l'installation de l'outillage officiel, traiter la documentation officielle et la source installée comme faisant autorité. Cette compétence est une distillation originale de la méthode en tant que protocole agnostique ; elle ne reproduit pas le contenu de l'installateur officiel.