Council

Réunissez quatre conseillers pour les décisions ambiguës :

• la voix de Claude adaptée au contexte
• un sous-agent « Sceptique »
• un sous-agent « Pragmatique »
• un sous-agent « Critique »

Ceci concerne la prise de décision en situation d’ambiguïté, et non la révision de code, la planification de la mise en œuvre ou la conception de l’architecture.

Quand l'utiliser

Utilisez «council» lorsque :

• une décision présente plusieurs voies plausibles et qu’aucune ne se détache clairement
• vous avez besoin de mettre en évidence les compromis de manière explicite
• l’utilisateur sollicite des seconds avis, des opinions divergentes ou des points de vue multiples
• l’ancrage conversationnel représente un risque réel
• une décision « oui / non » gagnerait à être soumise à une remise en question contradictoire

Exemples :

• monorepo vs polyrepo
• « Lancer maintenant » vs « Attendre pour peaufiner »
• drapeau de fonctionnalité vs déploiement complet
• simplifier le périmètre vs conserver l’ampleur stratégique

Quand NE PAS l'utiliser

Rôles

Ces trois voix externes doivent être lancées sous forme de sous-agents distincts, ne disposant que de la question et du contexte pertinent, et non de l’intégralité de la conversation en cours. C’est ce qu’on appelle le mécanisme anti-ancrage.

Déroulement

1. Extraire la véritable question

Réduire la décision à une seule invite explicite :

• que décidons-nous ?
• Quelles sont les contraintes importantes ?
• Qu'est-ce qui constitue un succès ?

Si la question est vague, posez une question de clarification avant de convoquer l’council

2. Ne rassemblez que le contexte nécessaire

Si la décision concerne spécifiquement le code source :

• rassemblez les fichiers, extraits de code, descriptions de tickets ou métriques pertinents
• restez concis
• n'incluez que le contexte nécessaire à la prise de décision

Si la décision est stratégique ou d’ordre général :

• ignorez les extraits du dépôt, sauf s'ils modifient sensiblement la réponse

3. Définissez d’abord la position de l’architecte

Avant de lire les autres avis, notez :

• votre position initiale
• les trois arguments les plus convaincants qui la justifient
• le principal risque lié à la voie que vous privilégiez

Faites-le en premier lieu afin que la synthèse ne se contente pas de refléter les avis extérieurs.

4. Lancez trois points de vue indépendants en parallèle

Chaque sous-agent reçoit :

• la question de décision
• un contexte succinct si nécessaire
• un rôle strict
• aucun historique de conversation superflu

Format de la consigne :

You are the [ROLE] on a four-voice decision council.

Question:
[decision question]

Context:
[only the relevant snippets or constraints]

Respond with:
1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in your recommendation
4. Surprise — one thing the other voices may miss

Be direct. No hedging. Keep it under 300 words.

Accent mis sur le rôle :

• Sceptique : remettre en question le cadre, remettre en cause les hypothèses, proposer l’alternative crédible la plus simple
• Pragmatique : optimiser la rapidité, la simplicité et la mise en œuvre concrète
• Critique : mettre en évidence les risques de perte, les cas limites et les raisons pour lesquelles le plan pourrait échouer

5. Synthétisez en respectant les limites de partialité

Vous êtes à la fois participant et synthétiseur ; appliquez donc ces règles :

• ne rejetez pas un point de vue extérieur sans expliquer pourquoi
• si une opinion extérieure a modifié votre recommandation, indiquez-le explicitement
• incluez toujours l’opinion dissidente la plus forte, même si vous la rejetez
• si deux avis s’opposent à votre position initiale, considérez cela comme un signal réel
• gardez les positions brutes visibles avant le verdict

6. Présentez un verdict concis

Utilisez ce format de présentation :

## Council: [short decision title]

**Architect:** [1-2 sentence position]
[1 line on why]

**Skeptic:** [1-2 sentence position]
[1 line on why]

**Pragmatist:** [1-2 sentence position]
[1 line on why]

**Critic:** [1-2 sentence position]
[1 line on why]

### Verdict
- **Consensus:** [where they align]
- **Strongest dissent:** [most important disagreement]
- **Premise check:** [did the Skeptic challenge the question itself?]
- **Recommendation:** [the synthesized path]

Veillez à ce qu’il soit facilement consultable sur l’écran d’un téléphone.

Règle de persistance

N’écrivez pas de notes ad hoc dans ~/.claude/notes ou d’autres chemins secondaires de cette compétence.

Si l'councile modifie de manière significative la recommandation :

• utilisez knowledge-ops pour stocker la leçon à l'emplacement durable approprié
• ou utilisez /save-session si le résultat doit être conservé en mémoire de session
• ou mettez directement à jour le ticket GitHub / Linear concerné si la décision modifie l'état d'exécution actuel

Ne persistez une décision que lorsqu’elle modifie quelque chose de concret.

Suivi en plusieurs phases

Par défaut, un seul tour.

Si l’utilisateur souhaite un tour supplémentaire :

• veillez à ce que la nouvelle question reste ciblée
• n'incluez le verdict précédent que si cela est nécessaire
• veillez à ce que le Skeptic reste aussi simple que possible afin de préserver la valeur anti-ancrage

Anti-modèles

• utiliser « council » pour la révision de code
• Utiliser l’council lorsque la tâche se limite à un travail d’implémentation
• fournir aux sous-agents la transcription intégrale de la conversation
• Masquer les désaccords dans le verdict final
• Consigner chaque décision sous forme de note, quelle que soit son importance

Compétences associées

• santa-method — vérification contradictoire
• knowledge-ops — enregistrer correctement les différences de décision de manière durable
• search-first — rassembler des documents de référence externes avant l’council, si nécessaire
• architecture-decision-records — formaliser le résultat lorsque la décision devient une politique système à long terme

Exemple

Question :

Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?

Forme probable de l’council :

• L’architecte insiste sur l’intégrité structurelle et sur la nécessité d’éviter une interface confuse
• Le sceptique se demande si l’interface utilisateur est réellement le facteur limitant
• Le pragmatique demande ce qui peut être livré dès maintenant sans nuire à la confiance
• Le critique met l’accent sur la charge de support, la dette d’attentes et la confusion liée au déploiement

L’important n’est pas l’unanimité. L’important est de rendre les divergences d’opinion claires avant de faire un choix.