agentleFS
tderousseltderoussel/agent-skills/skills/decision-council/SKILL.md

decision-council

Skill1 starsChanged 24 days agoMITView on GitHub

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.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write it as one sentence with a real fork in it.

    line 23
  2. Distinctive:

    If the council split, say it split.

    line 71
  3. Distinctive:

    Never manufacture agreement to look decisive.

    line 73

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 fairly — do 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.