breakdown – décomposition convergente, orientée action
Le complément convergent de /fanout. /fanout ouvre un problème (multiples réponses valables) ; /breakdown en ferme un (une seule interrogation -> une seule prochaine étape). Un seul coup, sans sous-agents, coût ~1x. Basé sur l'exploration du transcript de session du mainteneur : le frottement le plus fort était « arrête d'expliquer, fais-le », donc cette compétence est ACTION-D'ABORD et minimaliste en prose par conception. Si votre résultat ressemble à une gentille promenade guidée, c'est faux – coupez.
Étape 1 – Récupérer l'interrogation
Acceptez le problème via une mention @, un chemin, ou du texte collé. S'il est vraiment vague,
demandez une ou deux phrases – une fois. Lisez tout fichier référencé jusqu'à son terme avant de décomposer.
Si l'interrogation est (ou nomme) un artefact de projet, lisez AUSSI le CHECKPOINT.md de ce projet
jusqu'à son terme (recevoir un aperçu ne compte pas comme une lecture) – le « vrai objectif » et la « décision bloquante »
dépendent de l'état vivant du projet (échéances, portes de séquencement, ce qui est déjà décidé), et une
décomposition qui l'ignore pointe vers la mauvaise action suivante. Passez uniquement si le problème est vraiment sans projet.
Étape 2 – Générer exactement ces cinq blocs, de manière concise, dans l'ordre
Pas de préambule. Pas de « J'ai accès à... ». Ne reformulez pas la question en long.
- Vrai objectif (une phrase). Ce que « fait » signifie réellement. Si l'objectif énoncé diffère du vrai, dites-le en une ligne.
- Plus petite action suivante (une étape concrète, physique, réalisable en une session – par ex. « ouvre X et écris les trois noms de champs », pas « conçois le schéma »). Puis PROPOSEZ de le faire maintenant. N'expliquez pas longuement avant.
- L'unique décision bloquante – la seule bifurcation qui débloque le plus, ou « aucune – commence juste. »
- Plan complet (réduit) – la liste de contrôle complète sous un résumé d'une ligne, explicitement dépriorisée : « ignorez jusqu'à ce que l'étape 2 soit faite. »
- Premier piège – le mode d'échec le plus probable et son signal le plus précoce.
Règles
- Un seul fil sur le chemin critique. Ne listez pas de flux de travail parallèles.
- Langage simple, pas de codes inventés (traduisez toute étiquette de classement en mots humains).
- Ne COMMENCEZ PAS le travail tant que l'utilisateur n'a pas choisi. /breakdown planifie ; il n'exécute pas.
- Ne persistez rien par défaut. Si cela vaut la peine d'être conservé, proposez de l'écrire dans la ligne « Prochaine étape » du CHECKPOINT du projet.