tderoussel/decision-council

Führe eine strukturierte Überprüfung einer Entscheidung aus mehreren Perspektiven durch, anstatt nur eine zustimmende Antwort zu erhalten. Verwende dies, wenn der Benutzer „führe einen Rat durch“, „hol mir Perspektiven dazu ein“, „soll ich X tun“, „stress-test diese Entscheidung“ oder „ist das eine gute Idee“ sagt.

Was ist decision-council?

Dieses Skill ermöglicht es AI-Agenten, komplexe und folgenreiche Entscheidungen systematisch zu evaluieren, indem es mehrere unabhängige, rollenbasierte Perspektiven generiert, diese in einem blinden Peer-Review-Verfahren anonymisiert bewerten lässt und schließlich durch einen finalen „Vorsitzenden“-Agenten zu einem strukturierten Urteil zusammenzufassen. Es löst das grundlegende Problem, dass ein einzelner Agent dazu neigt, eine kohärente statt einer korrekten Antwort zu liefern, indem es Perspektiven wie die des Kontrahenten, des Optimisten, des Betreibers, des Kunden und des Buchhalters parallel nutzt. Das Skill ist besonders nützlich für reale Gabelungen mit hohem Einsatz – wie Build vs. Buy, Ausliefern vs. Zurückhalten, Preisänderungen oder Feature-Priorisierung – und nicht für Fragen mit bekannten Antworten. Es ist plattformunabhängig und folgt einem klaren, reproduzierbaren Fünf-Schritte-Prozess, der sicherstellt, dass sowohl die stärksten als auch die schwächsten Argumente fair gegenübergestellt werden und echte Spannungen nicht zugunsten einer erzwungenen Einigung unterdrückt werden.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/tderoussel/agent-skills/tree/main/skills/decision-council

Installed? Explore more Produktivität & Zusammenarbeit skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Entscheidungsrat

Das Problem, das dies löst

Würde man einen Agenten fragen: „Warum ist das eine gute Idee?“, erhält man eine gut argumentierte Zustimmung. Fragt man: „Warum ist das eine schlechte Idee?“, erhält man eine ebenso gut argumentierte Ablehnung. Beide sind eloquent, aber kein Urteil. Ein einzelner Agent ist ein schlechter Berater, weil er eher auf eine kohärente als auf eine korrekte Antwort optimiert.

Dieses Skill führt mehrere unabhängige Perspektiven aus, lässt sie von Agenten prüfen, die nicht wissen, wer was geschrieben hat, und liefert ein einziges Urteil.

Wann man es einsetzt

Echte Gabelungen mit echtem Einsatz: Bauen vs. Kaufen, Ausliefern vs. Zurückhalten, Preisänderungen, ob eine Funktion verfrüht ist, woran man als nächstes arbeiten soll. Nicht für Fragen mit bekannter Antwort.

Schritte

1. Formuliere die Entscheidung präzise

Schreibe sie als einen Satz mit einer echten Gabelung. Wenn sie nicht so formuliert werden kann, ist die Entscheidung noch nicht klar genug für eine Überprüfung – behebe das zuerst.

Erfasse, was tatsächlich bekannt ist: Einschränkungen, was bereits versucht wurde, was umkehrbar ist und was nicht.

2. Den Rat einberufen – parallel, unabhängig

Fünf Agenten, jeder mit einer wirklich anderen Perspektive. Sie dürfen die Antworten der anderen nicht sehen.

PersonaAufgabe
Der KontrahentNimm an, dies scheitert. Was hat es zerstört?
Der OptimistNimm an, es funktioniert. Was hat es freigesetzt, das unterschätzt wird?
Der BetreiberWer macht die Arbeit, was geht schief, was sind die wahren Kosten der Benutzerzeit?
Der KundeKümmert es die zahlende Person tatsächlich? Würde sie es bemerken?
Der BuchhalterWas kostet das, was bringt es, was sind die Opportunitätskosten?

Jeder liefert: eine Empfehlung, die Begründung und die eine Tatsache, die seine Meinung ändern würde.

Tausche eine Persona aus, wenn die Entscheidung es erfordert – eine regulatorische Perspektive für eine Compliance-Gabelung, eine Sicherheitsperspektive für eine Architekturentscheidung. Halte die Perspektiven wirklich verschieden.

3. Peer-Review, blind

Entferne die Zuordnung und mische. Gib die anonymisierte Sammlung an neue Prüfer. Frage jeden: Welches Argument ist das stärkste, welches das schwächste, und was haben alle übersehen?

Blindheit ist wichtig – sie verhindert, dass der Prüfer derjenigen Persona den Vorzug gibt, die am autoritärsten klingt.

4. Der Vorsitzende

Ein letzter Agent liest die Perspektiven und die Bewertungen und gibt Folgendes zurück:

## Entscheidung: <die Frage>

**Urteil:** <der Entscheid, in einem Satz>

**Sicherheit:** <hoch | mittel | niedrig> — <warum>

**Die ausschlaggebende Begründung:** <2–3 Sätze>

**Das stärkste Gegenargument:** <faires Formulieren – kein Strohmann>

**Was würde dies ändern:** <die spezifische Tatsache oder das Ereignis, das die Antwort umkehrt>

**Wenn wir weitermachen:** <erster konkreter Schritt>

5. Ehrlich berichten

Wenn der Rat gespalten ist, sage, dass er gespalten ist. Ein erzwungener Konsens ist schlimmer als eine lebendige Uneinigkeit – die meisten Menschen würden lieber die echte Spannung sehen und selbst entscheiden.

Erzeuge niemals Einigkeit, um entschlossen zu wirken.

Skalierung

Fünf Personas sind die Voreinstellung. Drei für eine kleinere Entscheidung, sieben für etwas Teures oder schwer Umkehrbares. Mehr Personas helfen nur, wenn die Perspektiven wirklich unterschiedlich sind – fünf verschiedene Blickwinkel schlagen neun überlappende.

Danksagung

Das Muster mit mehreren Personas plus Blindbewertung plus Vorsitzendem stammt von Ollie Leman, über Remy Gaskells Open-Residency-Episode über Agenten-Betriebssysteme.

Individual skills in this repo

This repo contains 8 individual skills — each has its own dedicated page.

tderoussel/codebase-audit

Runs a ranked, evidence-backed audit of a product, codebase, or subsystem, ending in a verify list that separates proven findings from inferred ones. Use when the user asks for an audit, a gap analysis, a deep read, a bug hunt, a readiness check, a re-audit, a state reconciliation, or asks what they are not seeing. Trigger phrases include "audit", "gap analysis", "what am I missing", "deep audit", "readiness", "bug hunt", "review the whole thing". Produces findings and a verify list; does not fix.

tderoussel/competitive-teardown

Researches a competing product against your own and produces a ranked build-or-ignore verdict, plus optional comparison-page copy. Use when the user names a competitor or asks how their product stacks up against one. Trigger phrases include "vs us", "competitor", "what does X have", "should we copy", "competitive gap", "teardown", "are we behind". Produces a ranked verdict with effort estimates and an explicit not-worth-copying list.

tderoussel/fleet-brief

Authors a workstream brief for dispatching multiple parallel build agents across one codebase, with per-lane file ownership, shared-ground warnings, and a derived DO-NOT list. Use whenever work is about to be split across concurrent agents, workers, lanes, or waves — even if the user does not say "write a brief". Trigger phrases include "fan out", "parallel agents", "orchestrate this", "split into lanes", "workstreams", "run these in parallel", "review-gated build". Produces the brief; does not dispatch.

tderoussel/inbox-triage

Triage an email inbox — sort what needs a reply, draft the replies, flag what needs a decision, and surface what can be ignored or unsubscribed. Use when the user says triage my inbox, do my email, what's in my inbox, or clean up my email.

tderoussel/overnight-build

Composes an autonomous unattended Claude Code build prompt that survives usage-limit resets via BUILD_LOG.md checkpointing, plus the launcher that restarts it. Use when the user asks for an overnight build, an autonomous build, a build to run while they sleep, an unattended or unsupervised session, or any long build they will not be monitoring. Trigger phrases include "overnight build", "run overnight", "build while I sleep", "autonomous build", "let it run", "unattended". Produces a single copyable prompt; does not run the build.

tderoussel/session-log

Write a durable record of a work session — what was built, root-caused, or shipped — into the project's notes. Use when the user says log this session, write a session log, record this, or when a substantial piece of work has just finished and needs to be handed off to a future session.

tderoussel/ship-gate

Verification gate for a Next.js-on-Vercel + Supabase + GitHub Actions stack, to run before claiming anything is shipped, deployed, live, merged, passing, or done. Use before saying a change is in production, before merging a PR, before reporting CI green, and before writing any status into a document — even if the user does not ask for verification. Trigger phrases include "is it live", "did it deploy", "ship it", "merge it", "is CI green", "confirm prod", "did that work". Encodes traps where the obvious check returns a false pass.

tderoussel/vault-doctor

Audits and repairs an Obsidian vault's structural health — broken [[wikilinks]], ambiguous duplicate filenames, missing or malformed frontmatter, stale status markers, and hub notes whose state sections have gone cold. Use when the user asks about vault health, broken links, vault cleanup, dead links, orphan notes, tag consistency, or says the vault feels messy or out of date. Trigger phrases include "vault health", "broken links", "clean up the vault", "audit the vault", "is the vault current". Read-only by default; every repair is proposed before it is made.

Verwandte Skills