Que fait Conseil ?
Convoquez quatre conseillers pour les décisions ambiguës :
- la voix Claude en contexte
- un sous-agent Skeptique
- un sous-agent Pragmatiste
- un sous-agent Critique
Ceci est pour la prise de décision sous ambiguïté, pas pour la revue de code, la planification d'implémentation ou la conception d'architecture.
Quand utiliser
Utilisez le conseil quand :
- une décision a plusieurs chemins crédibles et aucun gagnant évident
- vous avez besoin d'expliciter les compromis
- l'utilisateur demande un second avis, une dissidence ou plusieurs perspectives
- l'ancrage conversationnel est un risque réel
- un appel à faire ou ne pas faire bénéficierait d'un défi contradictoire
Exemples :
- monorepo vs polyrepo
- livrer maintenant vs attendre pour peaufiner
- feature flag vs déploiement complet
- simplifier le périmètre vs garder l'ampleur stratégique
Quand NE PAS utiliser
| Au lieu du conseil | Utilisez |
|---|---|
| Vérifier si la sortie est correcte | santa-method |
| Décomposer une fonctionnalité en étapes d'implémentation | planner |
| Concevoir l'architecture système | architect |
| Examiner le code pour des bogues ou la sécurité | code-reviewer ou santa-method |
| Questions factuelles directes | Répondez directement |
| Tâches d'exécution évidentes | Faites simplement la tâche |
Rôles
| Voix | Lentille |
|---|---|
| Architecte | exactitude, maintenabilité, implications à long terme |
| Skeptique | remise en cause des prémisses, simplification, bris d'hypothèses |
| Pragmatiste | vitesse de livraison, impact utilisateur, réalité opérationnelle |
| Critique | cas limites, risque de baisse, modes d'échec |
Les trois voix externes doivent être lancées comme des sous-agents vierges avec seulement la question et le contexte pertinent, pas l'intégralité de la conversation en cours. C'est le mécanisme anti-ancrage.
Flux de travail
1. Extraire la vraie question
Réduisez la décision à une invite explicite :
- que décidons-nous ?
- quelles contraintes importent ?
- qu'est-ce qui constitue un succès ?
Si la question est vague, posez une question de clarification avant de convoquer le conseil.
2. Rassembler uniquement le contexte nécessaire
Si la décision est spécifique au code :
- collectez les fichiers, extraits, texte de l'issue ou métriques pertinents
- gardez cela compact
- incluez uniquement le contexte nécessaire à la décision
Si la décision est stratégique/générale :
- sautez les extraits de dépôt sauf s'ils changent matériellement la réponse
3. Former d'abord la position de l'Architecte
Avant de lire les autres voix, écrivez :
- votre position initiale
- les trois raisons les plus fortes en sa faveur
- le principal risque dans votre chemin préféré
Faites cela en premier pour que la synthèse ne reflète pas simplement les voix externes.
4. Lancer trois voix indépendantes en parallèle
Chaque sous-agent reçoit :
- la question de décision
- un contexte compact si nécessaire
- un rôle strict
- aucun historique de conversation inutile
Forme de l'invite :
Vous êtes le/la [RÔLE] dans un conseil de décision à quatre voix.
Question :
[question de décision]
Contexte :
[uniquement les extraits ou contraintes pertinents]
Répondez avec :
1. Position — 1-2 phrases
2. Raisonnement — 3 points concis
3. Risque — le plus grand risque dans votre recommandation
4. Surprise — une chose que les autres voix pourraient manquer
Soyez direct. Pas de réserve. Restez sous 300 mots.
Emphase des rôles :
- Skeptique : remettre en cause le cadrage, questionner les hypothèses, proposer l'alternative crédible la plus simple
- Pragmatiste : optimiser pour la vitesse, la simplicité et l'exécution dans le monde réel
- Critique : exposer les risques de baisse, les cas limites et les raisons pour lesquelles le plan pourrait échouer
5. Synthétiser avec des garde-fous contre les biais
Vous êtes à la fois participant et synthétiseur, donc utilisez ces règles :
- ne rejetez pas un avis externe sans expliquer pourquoi
- si une voix externe a changé votre recommandation, dites-le explicitement
- incluez toujours la dissidence la plus forte, même si vous la rejetez
- si deux voix s'alignent contre votre position initiale, traitez cela comme un signal réel
- gardez les positions brutes visibles avant le verdict
6. Présenter un verdict compact
Utilisez cette forme de sortie :
## Conseil : [titre court de la décision]
**Architecte :** [position en 1-2 phrases]
[1 ligne sur pourquoi]
**Skeptique :** [position en 1-2 phrases]
[1 ligne sur pourquoi]
**Pragmatiste :** [position en 1-2 phrases]
[1 ligne sur pourquoi]
**Critique :** [position en 1-2 phrases]
[1 ligne sur pourquoi]
### Verdict
- **Consensus :** [là où ils s'accordent]
- **Dissidence la plus forte :** [désaccord le plus important]
- **Vérification des prémisses :** [le Skeptique a-t-il remis en cause la question elle-même ?]
- **Recommandation :** [le chemin synthétisé]
Gardez-le lisible sur un écran de téléphone.
Règle de persistance
N'écrivez pas de notes ad-hoc dans ~/.claude/notes ou d'autres chemins cachés via cette compétence.
Si le conseil change matériellement la recommandation :
- utilisez
knowledge-opspour stocker la leçon au bon endroit durable - ou utilisez
/save-sessionsi le résultat appartient à la mémoire de session - ou mettez à jour directement l'issue GitHub / Linear concernée si la décision change la vérité d'exécution active
Ne persistez une décision que lorsqu'elle change quelque chose de réel.
Suivi multi-tours
Par défaut, un seul tour.
Si l'utilisateur veut un autre tour :
- gardez la nouvelle question ciblée
- incluez le verdict précédent seulement si nécessaire
- gardez le Skeptique aussi vierge que possible pour préserver la valeur anti-ancrage
Anti-patrons
- utiliser le conseil pour la revue de code
- utiliser le conseil quand la tâche est simplement du travail d'implémentation
- fournir aux sous-agents la transcription entière de la conversation
- cacher le désaccord dans le verdict final
- persister chaque décision comme une note quelle que soit son importance
Compétences connexes
santa-method— vérification contradictoireknowledge-ops— persister correctement les deltas de décision durablessearch-first— rassembler le matériel de référence externe avant le conseil si nécessairearchitecture-decision-records— formaliser le résultat lorsque la décision devient une politique système durable
Exemple
Question :
Devrions-nous livrer ECC 2.0 en alpha maintenant, ou attendre que l'interface utilisateur du plan de contrôle soit plus complète ?
Forme probable du conseil :
- L'Architecte pousse pour l'intégrité structurelle et éviter une surface confuse
- Le Skeptique remet en question si l'interface est réellement le facteur limitant
- Le Pragmatiste demande ce qui peut être livré maintenant sans nuire à la confiance
- Le Critique se concentre sur la charge de support, la dette d'attentes et la confusion de déploiement
La valeur n'est pas l'unanimité. La valeur est de rendre le désaccord lisible avant de choisir.