Council

Was macht Council?

Berufe vier Berater für mehrdeutige Entscheidungen:

• die im Kontext befindliche Claude-Stimme
• einen Skeptiker-Subagenten
• einen Pragmatiker-Subagenten
• einen Kritiker-Subagenten

Dies ist für Entscheidungsfindung unter Ambiguität, nicht für Code-Review, Implementierungsplanung oder Architekturentwurf.

Wann verwenden

Verwende Council, wenn:

• eine Entscheidung mehrere glaubwürdige Pfade und keinen offensichtlichen Gewinner hat
• du explizite Abwägungsoberfläche benötigst
• der Benutzer nach Zweitmeinungen, Widerspruch oder mehreren Perspektiven fragt
• Konversations-Ankerung ein echtes Risiko darstellt
• eine Go/No-Go-Entscheidung von adversariellem Widerspruch profitieren würde

Beispiele:

• Monorepo vs. Polyrepo
• jetzt ausliefern vs. auf Politur warten
• Feature-Flag vs. vollständiger Rollout
• Umfang vereinfachen vs. strategische Breite behalten

Wann NICHT verwenden

Statt Council	Verwende
Überprüfen, ob die Ausgabe korrekt ist	santa-method
Aufteilen eines Features in Implementierungsschritte	planner
Entwerfen von Systemarchitektur	architect
Überprüfen von Code auf Fehler oder Sicherheit	code-reviewer oder santa-method
Direkte Sachfragen	einfach direkt antworten
Offensichtliche Ausführungsaufgaben	einfach die Aufgabe erledigen

Rollen

Stimme	Blickwinkel
Architekt	Korrektheit, Wartbarkeit, langfristige Auswirkungen
Skeptiker	Voraussetzungs-Herausforderung, Vereinfachung, Annahmen brechen
Pragmatiker	Auslieferungsgeschwindigkeit, Benutzerauswirkung, betriebliche Realität
Kritiker	Randfälle, Abwärtsrisiko, Fehlermodi

Die drei externen Stimmen sollten als frische Subagenten gestartet werden, die nur die Frage und den relevanten Kontext erhalten, nicht die gesamte laufende Unterhaltung. Das ist der Anti-Ankerungsmechanismus.

Arbeitsablauf

1. Die eigentliche Frage extrahieren

Reduziere die Entscheidung auf einen expliziten Prompt:

• worüber entscheiden wir?
• welche Einschränkungen sind wichtig?
• was zählt als Erfolg?

Wenn die Frage vage ist, stelle eine klärende Frage, bevor du den Rat einberufst.

2. Nur den notwendigen Kontext sammeln

Wenn die Entscheidung codebasis-spezifisch ist:

• sammle die relevanten Dateien, Ausschnitte, Issue-Texte oder Metriken
• halte es kompakt
• füge nur den Kontext ein, der für die Entscheidung benötigt wird

Wenn die Entscheidung strategisch/allgemein ist:

• überspringe Repo-Ausschnitte, es sei denn, sie ändern die Antwort materiell

3. Zuerst die Architektenposition formulieren

Bevor du die anderen Stimmen liest, schreibe auf:

• deine anfängliche Position
• die drei stärksten Gründe dafür
• das Hauptrisiko in deinem bevorzugten Pfad

Tue dies zuerst, damit die Synthese nicht einfach die externen Stimmen widerspiegelt.

4. Drei unabhängige Stimmen parallel starten

Jeder Subagent erhält:

• die Entscheidungsfrage
• kompakten Kontext, falls erforderlich
• eine strenge Rolle
• keine unnötige Gesprächshistorie

Prompt-Form:

Du bist der [ROLLE] in einem vierstimmigen Entscheidungsrat.

Frage:
[Entscheidungsfrage]

Kontext:
[nur die relevanten Ausschnitte oder Einschränkungen]

Antworte mit:
1. Position — 1-2 Sätze
2. Begründung — 3 prägnante Aufzählungspunkte
3. Risiko — größtes Risiko in deiner Empfehlung
4. Überraschung — eine Sache, die die anderen Stimmen übersehen könnten

Sei direkt. Kein Herumreden. Halte es unter 300 Wörtern.

Rollen-Schwerpunkte:

• Skeptiker: Rahmenstellung herausfordern, Annahmen hinterfragen, die einfachste glaubwürdige Alternative vorschlagen
• Pragmatiker: Optimieren für Geschwindigkeit, Einfachheit und reale Ausführung
• Kritiker: Abwärtsrisiko, Randfälle und Gründe, warum der Plan scheitern könnte, aufzeigen

5. Mit Voreingenommenheitsbarrieren synthetisieren

Du bist sowohl Teilnehmer als auch Synthesizer, also verwende diese Regeln:

• verwerfe keine externe Ansicht, ohne zu erklären, warum
• wenn eine externe Stimme deine Empfehlung geändert hat, sage dies explizit
• füge immer den stärksten Widerspruch ein, selbst wenn du ihn ablehnst
• wenn zwei Stimmen gegen deine anfängliche Position ausgerichtet sind, behandle dies als echtes Signal
• halte die rohen Positionen vor dem Urteil sichtbar

6. Ein kompaktes Urteil präsentieren

Verwende diese Ausgabeform:

## Rat: [kurzer Entscheidungstitel]

**Architekt:** [1-2 Satz Position]
[1 Zeile warum]

**Skeptiker:** [1-2 Satz Position]
[1 Zeile warum]

**Pragmatiker:** [1-2 Satz Position]
[1 Zeile warum]

**Kritiker:** [1-2 Satz Position]
[1 Zeile warum]

### Urteil
- **Konsens:** [wo sie übereinstimmen]
- **Stärkster Widerspruch:** [wichtigste Meinungsverschiedenheit]
- **Prämissenprüfung:** [hat der Skeptiker die Frage selbst herausgefordert?]
- **Empfehlung:** [der synthetisierte Pfad]

Halte es auf einem Telefonbildschirm lesbar.

Persistenzregel

Schreibe keine Ad-hoc-Notizen nach ~/.claude/notes oder andere Schattenpfade von diesem Skill aus.

Wenn der Rat die Empfehlung materiell ändert:

• verwende knowledge-ops, um die Lektion am richtigen dauerhaften Ort zu speichern
• oder verwende /save-session, wenn das Ergebnis zur Sitzungsspeicher gehört
• oder aktualisiere das entsprechende GitHub/Linear-Issue direkt, wenn die Entscheidung die aktive Ausführungswahrheit ändert

Persistiere eine Entscheidung nur, wenn sie etwas Wirkliches ändert.

Mehrrunden-Follow-up

Standard ist eine Runde.

Wenn der Benutzer eine weitere Runde wünscht:

• halte die neue Frage fokussiert
• füge das vorherige Urteil nur bei Bedarf ein
• halte den Skeptiker so sauber wie möglich, um den Anti-Ankerungswert zu bewahren

Anti-Muster

• Council für Code-Review verwenden
• Council verwenden, wenn die Aufgabe nur Implementierungsarbeit ist
• den Subagenten das gesamte Gesprächsprotokoll füttern
• Meinungsverschiedenheiten im endgültigen Urteil verstecken
• jede Entscheidung unabhängig von ihrer Wichtigkeit als Notiz persistieren

Verwandte Skills

• santa-method — adversarielle Verifikation
• knowledge-ops — dauerhafte Entscheidungsdeltas korrekt persistieren
• search-first — externes Referenzmaterial vor dem Rat sammeln, falls erforderlich
• architecture-decision-records — das Ergebnis formalisieren, wenn die Entscheidung zu einer langlebigen Systemrichtlinie wird

Beispiel

Frage:

Sollten wir ECC 2.0 jetzt als Alpha ausliefern oder warten, bis die Control-Plane-Benutzeroberfläche vollständiger ist?

Wahrscheinliche Rat-Form:

• Architekt drängt auf strukturelle Integrität und Vermeidung einer verwirrenden Oberfläche
• Skeptiker hinterfragt, ob die Benutzeroberfläche tatsächlich der Engpass ist
• Pragmatiker fragt, was jetzt ausgeliefert werden kann, ohne Vertrauen zu beschädigen
• Kritiker konzentriert sich auf Supportlast, Erwartungsschulden und Rollout-Verwirrung

Der Wert liegt nicht in Einstimmigkeit. Der Wert liegt darin, die Meinungsverschiedenheit lesbar zu machen, bevor man wählt.