Council

Rat

Rufe vier Berater für mehrdeutige Entscheidungen zusammen:

• die in-Kontext Claude-Stimme
• einen Skeptiker-Unteragenten
• einen Pragmatiker-Unteragenten
• einen Kritiker-Unteragenten

Dies ist für Entscheidungsfindung unter Mehrdeutigkeit, nicht für Code-Reviews, Implementierungsplanung oder Architekturentwurf.

Wann verwenden

Verwende den Rat, wenn:

• eine Entscheidung mehrere glaubwürdige Wege und keinen offensichtlichen Gewinner hat
• du explizite Abwägungen benötigst
• der Benutzer nach Zweitmeinungen, Widerspruch oder mehreren Perspektiven fragt
• Gesprächsverankerung ein echtes Risiko darstellt
• eine Go/No-Go-Entscheidung von gegnerischer Herausforderung profitieren würde

Beispiele:

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

Wann NICHT verwenden

Statt des Rates	Verwende
Überprüfen, ob die Ausgabe korrekt ist	santa-method
Ein Feature in Implementierungsschritte zerlegen	planner
Systemarchitektur entwerfen	architect
Code auf Fehler oder Sicherheitslücken prüfen	code-reviewer oder santa-method
Direkte sachliche Fragen	einfach direkt antworten
Offensichtliche Ausführungsaufgaben	einfach die Aufgabe erledigen

Rollen

Stimme	Linse
Architekt	Korrektheit, Wartbarkeit, langfristige Auswirkungen
Skeptiker	Prämisse hinterfragen, Vereinfachung, Annahmen brechen
Pragmatiker	Auslieferungsgeschwindigkeit, Benutzerauswirkungen, operative Realität
Kritiker	Randfälle, Abwärtsrisiken, Fehlermodi

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

Arbeitsablauf

1. Die eigentliche Frage extrahieren

Reduziere die Entscheidung auf eine explizite Aufforderung:

• Was 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 maßgeblich

3. Zuerst die Position des Architekten bilden

Bevor du andere Stimmen liest, notiere:

• deine anfängliche Position
• die drei stärksten Gründe dafür
• das Hauptrisiko deines bevorzugten Wegs

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

4. Drei unabhängige Stimmen parallel starten

Jeder Unteragent erhält:

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

Form der Aufforderung:

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 Abwiegeln. Bleibe unter 300 Wörtern.

Rollen-Schwerpunkte:

• Skeptiker: Rahmung hinterfragen, Annahmen prüfen, 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, daher verwende diese Regeln:

• verwerfe keine externe Sichtweise, 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 sich zwei Stimmen gegen deine anfängliche Position verbünden, behandle dies als echtes Signal
• halte die rohen Positionen vor dem Urteil sichtbar

6. Ein knappes 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 hinterfragt?]
- **Empfehlung:** [der synthetisierte Weg]

Halte es auf einem Telefonbildschirm lesbar.

Persistenzregel

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

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 Sitzungsspeicherung gehört
• oder aktualisiere direkt das relevante GitHub-/Linear-Issue, wenn die Entscheidung die aktuelle Ausführungswahrheit ändert

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

Mehrrunden-Folgefrage

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-Anker-Wert zu bewahren

Anti-Muster

• Den Rat für Code-Reviews verwenden
• Den Rat verwenden, wenn die Aufgabe nur Implementierungsarbeit ist
• Den Unteragenten das gesamte Gesprächsprotokoll füttern
• Meinungsverschiedenheiten im endgültigen Urteil verstecken
• Jede Entscheidung unabhängig von ihrer Bedeutung als Notiz persistieren

Verwandte Skills

• santa-method — gegnerische Verifikation
• knowledge-ops — dauerhafte Entscheidungsänderungen 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-Struktur:

• Architekt drängt auf strukturelle Integrität und Vermeidung einer verwirrenden Oberfläche
• Skeptiker hinterfragt, ob die Benutzeroberfläche wirklich der Engpass ist
• Pragmatiker fragt, was jetzt ausgeliefert werden kann, ohne Vertrauen zu schädigen
• Kritiker konzentriert sich auf Supportaufwand, Erwartungsschulden und Auslieferungsverwirrung

Der Wert liegt nicht in Einmütigkeit. Der Wert liegt darin, die Meinungsverschiedenheiten lesbar zu machen, bevor man wählt.