tderoussel/decision-council

Run a structured multi-perspective review of a decision instead of getting one agreeable answer. Use when the user says run a council, get me perspectives on this, should I do X, stress-test this decision, or is this a good idea.

Qu'est-ce que decision-council ?

decision-council is a Claude Code agent skill that run a structured multi-perspective review of a decision instead of getting one agreeable answer. Use when the user says run a council, get me perspectives on this, should I do X, stress-test this decision, or is this a good idea.

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

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Decision council

The problem this solves

Ask an agent "why is this a good idea?" and you get a well-argued case for yes. Ask "why is this a bad idea?" and you get an equally well-argued case for no. Both are fluent, neither is a judgment. A single agent is a bad advisor because it optimizes for a coherent answer rather than a correct one.

This runs several independent perspectives, has them reviewed by agents who don't know who wrote what, and produces one verdict.

When to run it

Real forks with real cost: build vs. buy, ship vs. hold, pricing changes, whether a feature is premature, what to work on next. Not for questions with a known answer.

Steps

1. State the decision precisely

Write it as one sentence with a real fork in it. If it can't be stated that way, the decision isn't clear enough to review yet — fix that first.

Gather what's actually known: constraints, what's already been tried, what's reversible and what isn't.

2. Spawn the council — in parallel, independent

Five agents, each with a genuinely different lens. They must not see each other's answers.

PersonaJob
The contrarianAssume this fails. What killed it?
The optimistAssume it works. What did it unlock that's being undervalued?
The operatorWho does the work, what breaks, what's the real cost in the user's time?
The customerDoes the person paying actually care? Would they notice?
The accountantWhat does this cost, what does it return, what's the opportunity cost?

Each returns: a recommendation, the reasoning, and the one fact that would change its mind.

Swap a persona when the decision calls for it — a regulatory lens for a compliance fork, a security lens for an architecture one. Keep the lenses genuinely distinct.

3. Peer review, blind

Strip attribution and shuffle. Hand the anonymized set to fresh reviewers. Ask each: which argument is strongest, which is weakest, and what did all of them miss?

Blinding matters — it stops the review from deferring to whichever persona sounds most authoritative.

4. The chairman

One final agent reads the perspectives and the reviews and returns:

## Decision: <the question>

**Verdict:** <the call, in one sentence>

**Confidence:** <high | medium | low><why>

**The reasoning that carried it:** <2-3 sentences>

**The strongest case against:** <state it fairlydo not strawman it>

**What would change this:** <the specific fact or event that flips the answer>

**If we proceed:** <first concrete step>

5. Report honestly

If the council split, say it split. A forced consensus is worse than a live disagreement — most people would rather see the real tension and make the call themselves.

Never manufacture agreement to look decisive.

Scaling it

Five personas is the default. Three for a smaller call, seven for something expensive or hard to reverse. More personas only helps if the lenses are genuinely different — five distinct angles beat nine overlapping ones.

Credit

The multi-persona-plus-blind-review-plus-chairman pattern comes from Ollie Leman, by way of Remy Gaskell's Open Residency episode on agent operating systems.

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.

Skills associés