Conseil

Que fait Conseil ?

Convoquez quatre conseillers pour les décisions ambiguës :

• la voix de Claude en contexte
• un sous-agent Skeptique
• un sous-agent Pragmatiste
• un sous-agent Critique

Ceci est destiné à la prise de décision en situation d'ambiguïté, pas à la revue de code, à la planification d'implémentation ou à la conception d'architecture.

Quand l'utiliser

Utilisez le conseil quand :

• une décision a plusieurs voies crédibles et aucun vainqueur évident
• vous avez besoin d'expliciter les compromis
• l'utilisateur demande des seconds avis, de la dissidence ou des perspectives multiples
• l'ancrage conversationnel est un risque réel
• une décision de type "go / no-go" bénéficierait d'un défi contradictoire

Exemples :

• monorepo vs polyrepo
• expédier maintenant vs attendre pour peaufiner
• feature flag vs déploiement complet
• simplifier le périmètre vs conserver l'ampleur 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 du système	architect
Revoir le code pour les bogues ou la sécurité	code-reviewer ou santa-method
Questions factuelles simples	répondez directement
Tâches d'exécution évidentes	faites la tâche

Rôles

Voix	Perspective
Architecte	exactitude, maintenabilité, implications à long terme
Skeptique	remise en cause des prémisses, simplification, rupture des 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 la conversation complète en cours. C'est le mécanisme anti-ancrage.

Workflow

1. Extraire la vraie question

Réduisez la décision à une question 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 codebase :

• collectez les fichiers, extraits, texte de problème ou métriques pertinents
• gardez-les compacts
• 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 à moins qu'ils ne changent matériellement la réponse

3. Formuler 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 risque principal dans votre chemin préféré

Faites-le d'abord 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 la décision
• le contexte compact si nécessaire
• un rôle strict
• aucun historique de conversation inutile

Forme du prompt :

Vous êtes le [RÔLE] d'un conseil de décision à quatre voix.

Question :
[question de la décision]

Contexte :
[seuls 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 demi-mesures. Restez sous 300 mots.

Emphase des rôles :

• Skeptique : défier 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 surface des risques de baisse, des cas limites et des 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, 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 véritable signal
• gardez les positions brutes visibles avant le verdict

6. Présenter un verdict compact

Utilisez cette forme de sortie :

## Conseil : [court titre 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'alignent]
- **Dissidence la plus forte :** [le désaccord le plus important]
- **Vérification des prémisses :** [le Skeptique a-t-il remis en cause 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 vers ~/.claude/notes ou d'autres chemins cachés à partir de cette compétence.

Si le conseil modifie matériellement la recommandation :

• utilisez knowledge-ops pour stocker la leçon au bon endroit durable
• ou utilisez /save-session si le résultat appartient à la mémoire de session
• ou mettez à jour directement le problème 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 en plusieurs tours

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 revue de code
• utiliser le conseil quand la tâche n'est que du travail d'implémentation
• nourrir les sous-agents avec la transcription complète 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 contradictoire
• knowledge-ops — persister correctement les deltas de décision durables
• search-first — rassembler du matériel de référence externe avant le conseil si nécessaire
• architecture-decision-records — formaliser le résultat lorsque la décision devient une politique système durable

Exemple

Question :

Devrions-nous expédier ECC 2.0 en alpha maintenant, ou attendre que l'UI 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'UI est vraiment le facteur bloquant
• Le Pragmatiste demande ce qui peut être expédié maintenant sans nuire à la confiance
• Le Critique se concentre sur la charge de support, la dette d'attente 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.