Conseil
Convoquez quatre conseillers pour les décisions ambiguës :
- la voix Claude dans le contexte
- un sous-agent Skeptique
- un sous-agent Pragmatiste
- un sous-agent Critique
Ceci est pour la prise de décision en situation d'ambiguïté, pas pour la révision de code, la planification de l'implémentation ou la conception d'architecture.
Quand l'utiliser
Utilisez le conseil quand :
- une décision a plusieurs voies crédibles et aucun gagnant évident
- vous avez besoin de faire émerger explicitement des compromis
- l'utilisateur demande un second avis, une dissidence ou des perspectives multiples
- l'ancrage conversationnel est un risque réel
- une décision go / no-go 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 une largeur stratégique
Quand NE PAS l'utiliser
| Au lieu du conseil | Utilisez |
|---|---|
| Vérifier si le résultat est correct | santa-method |
| Décomposer une fonctionnalité en étapes d'implémentation | planner |
| Concevoir l'architecture système | architect |
| Réviser le code pour les bugs ou la sécurité | code-reviewer ou santa-method |
| Questions factuelles simples | répondez directement |
| Tâches d'exécution évidentes | effectuez la tâche |
Rôles
| Voix | Perspective |
|---|---|
| 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 de défaillance |
Les trois voix externes doivent être lancées comme des sous-agents vierges avec seulement la question et le contexte pertinent, pas toute 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 question explicite :
- que décidons-nous ?
- quelles contraintes importent ?
- qu'est-ce qui compte comme 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 :
- rassemblez les fichiers, extraits, texte du ticket ou métriques pertinents
- gardez-le concis
- 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 modifient 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 solides pour celle-ci
- le principal risque de votre voie préférée
Faites-le d'abord pour que la synthèse ne se contente pas de refléter les voix externes.
4. Lancer trois voix indépendantes en parallèle
Chaque sous-agent reçoit :
- la question de décision
- un contexte concis si nécessaire
- un rôle strict
- aucun historique de conversation inutile
Format de l'invite :
Vous êtes le [RÔLE] dans un conseil de décision à quatre voix.
Question :
[question de décision]
Contexte :
[seulement les extraits ou contraintes pertinents]
Répondez avec :
1. Position — 1-2 phrases
2. Raisonnement — 3 puces concises
3. Risque — le plus grand risque de votre recommandation
4. Surprise — une chose que les autres voix pourraient manquer
Soyez direct. Pas de circonlocutions. Restez sous 300 mots.
Accent sur le rôle :
- Skeptique : contester le cadrage, remettre en question 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 : faire remonter 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 un participant et le synthétiseur, alors utilisez ces règles :
- ne rejetez pas un point de vue 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 vrai signal
- gardez les positions brutes visibles avant le verdict
6. Présenter un verdict compact
Utilisez ce format de sortie :
## Conseil : [titre court de la décision]
**Architecte :** [position en 1-2 phrases]
[1 ligne sur le pourquoi]
**Skeptique :** [position en 1-2 phrases]
[1 ligne sur le pourquoi]
**Pragmatiste :** [position en 1-2 phrases]
[1 ligne sur le pourquoi]
**Critique :** [position en 1-2 phrases]
[1 ligne sur le 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 question la question elle-même ?]
- **Recommandation :** [la voie synthétisée]
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 depuis cette compétence.
Si le conseil modifie 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 le ticket GitHub / Linear concerné si la décision modifie la vérité d'exécution active
Ne persistez une décision que lorsqu'elle change quelque chose de réel.
Suivi multi-tour
Par défaut, un seul tour.
Si l'utilisateur souhaite 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 révision de code
- utiliser le conseil alors que la tâche n'est qu'un travail d'implémentation
- alimenter les sous-agents avec la transcription complète de la conversation
- cacher le désaccord dans le verdict final
- persister chaque décision sous forme de note quel qu'en soit l'importance
Compétences liées
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 plaide pour l'intégrité structurelle et éviter une surface confuse
- Le Skeptique se demande si l'interface utilisateur est vraiment le facteur bloquant
- 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 du déploiement
La valeur n'est pas l'unanimité. La valeur est de rendre le désaccord lisible avant de choisir.