Council

Was macht Council?

Berufe vier Berater für mehrdeutige Entscheidungen:

• die In-Kontext-Stimme von Claude
• einen Skeptiker-Subagent
• einen Pragmatiker-Subagent
• einen Kritiker-Subagent

Dies dient der Entscheidungsfindung unter Mehrdeutigkeit, nicht der Code-Überprüfung, Implementierungsplanung oder Architekturentwicklung.

Wann anwenden

Nutze Council, wenn:

• eine Entscheidung mehrere glaubwürdige Pfade und keinen offensichtlichen Gewinner hat
• du explizite Abwägungen sichtbar machen musst
• der Benutzer nach Zweitmeinungen, Widerspruch oder mehreren Perspektiven fragt
• Gesprächsankereffekte ein echtes Risiko darstellen
• eine Go/No-Go-Entscheidung von einer antagonistischen Herausforderung profitieren würde

Beispiele:

• Monorepo vs. Polyrepo
• Jetzt ausliefern vs. auf Feinschliff warten
• Feature-Flag vs. vollständige Einführung
• Umfang vereinfachen vs. strategische Breite beibehalten

Wann NICHT anwenden

Statt Council	Verwende
Überprüfen, ob die Ausgabe korrekt ist	santa-method
Aufteilen einer Funktion in Implementierungsschritte	planner
Entwerfen der Systemarchitektur	architect
Code auf Fehler oder Sicherheitslücken prüfen	code-reviewer oder santa-method
Einfache sachliche Fragen	einfach direkt beantworten
Offensichtliche Ausführungsaufgaben	einfach die Aufgabe erledigen

Rollen

Stimme	Perspektive
Architekt	Korrektheit, Wartbarkeit, langfristige Auswirkungen
Skeptiker	Prämissen-Herausforderung, Vereinfachung, Annahmen brechen
Pragmatiker	Auslieferungsgeschwindigkeit, Benutzerauswirkung, betriebliche Realität
Kritiker	Randfälle, Abwärtsrisiken, Fehlermodi

Die drei externen Stimmen sollten als frische Subagenten mit nur der Frage und dem relevanten Kontext gestartet werden, nicht mit dem gesamten laufenden Gespräch. Das ist der Anti-Ankermechanismus.

Arbeitsablauf

1. Die eigentliche Frage extrahieren

Reduziere die Entscheidung auf eine explizite Aufforderung:

• Was entscheiden wir?
• Welche Einschränkungen sind wichtig?
• Was gilt als Erfolg?

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

2. Nur den notwendigen Kontext sammeln

Wenn die Entscheidung codebasisspezifisch ist:

• sammle die relevanten Dateien, Ausschnitte, Auszugstexte oder Metriken
• halte es kompakt
• nimm nur den Kontext auf, der für die Entscheidung erforderlich ist

Wenn die Entscheidung strategisch/allgemein ist:

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

3. Zuerst die Architekten-Position bilden

Bevor du die anderen Stimmen liest, notiere:

• deine Ausgangsposition
• 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

Aufforderungsform:

Du bist der [ROLLE] in einem Entscheidungsrat aus vier Stimmen.

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 möglicherweise übersehen

Sei direkt. Keine Absicherung. Halte es unter 300 Wörtern.

Rollen-Schwerpunkte:

• Skeptiker: Rahmung herausfordern, Annahmen hinterfragen, die einfachste glaubwürdige Alternative vorschlagen
• Pragmatiker: Für Geschwindigkeit, Einfachheit und reale Umsetzung optimieren
• Kritiker: Abwärtsrisiken, Randfälle und Gründe, warum der Plan scheitern könnte, aufzeigen

5. Mit Voreingenommenheits-Schutzmechanismen synthetisieren

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

• lehne eine externe Sichtweise nicht ab, ohne zu erklären, warum
• wenn eine externe Stimme deine Empfehlung geändert hat, sage dies explizit
• beziehe stets den stärksten Widerspruch ein, selbst wenn du ihn ablehnst
• wenn zwei Stimmen gegen deine Ausgangsposition ausgerichtet sind, behandle dies als echtes Signal
• halte die rohen Positionen vor dem Urteil sichtbar

6. Ein kompaktes Urteil präsentieren

Verwende diese Ausgabeform:

## Council: [kurzer Entscheidungstitel]

**Architekt:** [1-2 Satz Position]
[1 Zeile zur Begründung]

**Skeptiker:** [1-2 Satz Position]
[1 Zeile zur Begründung]

**Pragmatiker:** [1-2 Satz Position]
[1 Zeile zur Begründung]

**Kritiker:** [1-2 Satz Position]
[1 Zeile zur Begründung]

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

Halte es auf dem Bildschirm eines Smartphones lesbar.

Persistenzregel

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

Wenn der Council die Empfehlung wesentlich ändert:

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

Persistiere eine Entscheidung nur dann, wenn sie etwas Reales ändert.

Mehrstufige Nachverfolgung

Standard ist eine Runde.

Wenn der Benutzer eine weitere Runde wünscht:

• halte die neue Frage fokussiert
• nimm das vorherige Urteil nur bei Bedarf auf
• halte den Skeptiker so sauber wie möglich, um den Anti-Ankerwert zu erhalten

Anti-Patterns

• 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 der Wichtigkeit als Notiz persistieren

Verwandte Fähigkeiten

• santa-method — antagonistische Verifikation
• knowledge-ops — dauerhafte Entscheidungsänderungen korrekt persistieren
• search-first — externes Referenzmaterial vor dem Council 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-UI vollständiger ist?

Wahrscheinliche Council-Form:

• Architekt drängt auf strukturelle Integrität und die Vermeidung einer verwirrten Oberfläche
• Skeptiker hinterfragt, ob die UI tatsächlich der limitierende Faktor ist
• Pragmatiker fragt, was jetzt ausgeliefert werden kann, ohne das Vertrauen zu beschädigen
• Kritiker konzentriert sich auf Support-Last, Erwartungsschulden und Einführungsverwirrung

Der Wert liegt nicht in der Einstimmigkeit. Der Wert liegt darin, die Meinungsverschiedenheit sichtbar zu machen, bevor man sich entscheidet.