council
Skill1 starsChanged 5 months agoMITView on GitHub
A decision chamber for high-stakes, ambiguous calls. Five specialist advisors (contrarian, first-principles, expansionist, outsider, executor) attack the question independently; a blind second round tears every proposal apart without knowing who wrote it; a fresh chairman delivers a verdict — a decision, not a menu. Use for hard go/no-go and tradeoff calls. Heavy (~11 subagents) — reserve for decisions that earn it.
143 other projects use a version of this.
Adopted by
Most recently taken up by
- Beskars-Code/Skillstheir own version, first seen Nov 8, 2026
- Gabriel-Lafrance/Skillstheir own version, first seen Nov 8, 2026
- ong6/skillstheir own version, first seen Nov 8, 2026
- lbussell/agent-skillstheir own version, first seen Nov 8, 2026
- scottwater/skillstheir own version, first seen Nov 8, 2026
- T0mSIlver/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use agent-payment-x402, motion-advanced and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
TironFoxSkillagent-payment-x402
Add x402 payment execution to AI agents — per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents need to pay for APIs, services, or other agents.
Also in 5 projects that use this
renepfSkillmotion-advanced
Advanced motion patterns for React / Next.js — drag & drop, gestures, text animations, SVG path drawing, custom hooks, imperative sequences (useAnimate), loaders, and the full API decision tree. Requires motion-foundations.
Also in 4 projects that use this
RojiosSkilldefi-amm-security
Security checklist for Solidity AMM contracts, liquidity pools, and swap flows. Covers reentrancy, CEI ordering, donation or inflation attacks, oracle manipulation, slippage, admin controls, and integer math.
Also in 6 projects that use this
scottwaterSkillmodernize
Rebase an aging PR onto its current base and decide whether it should be modernized, reworked, or closed. Use when asked to rebase, update, or modernize an old PR.
Also in 7 projects that use this
RojiosSkilldart-flutter-patterns
Production-ready Dart and Flutter patterns covering null safety, immutable state, async composition, widget architecture, popular state management frameworks (BLoC, Riverpod, Provider), GoRouter navigation, Dio networking, Freezed code generation, and clean architecture.
Also in 5 projects that use this
scottwaterSkillleaving-pr-comments
Format comments an agent posts on GitHub on the user's behalf. Use whenever leaving a PR comment, review comment, or reply.
Also in 6 projects that use this
- +1 more from scottwater
- +1 more from Rojios
Other versions143 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 143
- simstudioai/sim★ 30ksame name
- 0xNyk/council-of-high-intelligence★ 4.8ksame name
- t3dotgg/tstack★ 2.5ksame name
- danieleteti/delphimvcframework★ 1.4ksame name
- warpdotdev/common-skills★ 630same name
- QuixiAI/agi-memory★ 623same name
- QuixiAI/Hexis★ 623same name
- zaxbysauce/opencode-swarm★ 519same name
- ZaxbyHub/opencode-swarm★ 518same name
- boshu2/agentops★ 453same name
133 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- api-designSkill
- brainstormingSkill
- dispatching-parallel-agentsSkill
- document-toolkitSkill
- executing-plansSkill
- gui-input-automationSkill
- humanizeSkill
- hyprland-controlSkill
- incremental-implementationSkill
- issue-to-prSkill
- litreviewSkill
- mcp-builderSkill
- rust-reviewSkill
- screen-captureSkill
- session-handoffSkill
- shadcn-auditSkill
- spec-to-issuesSkill
- subagent-driven-developmentSkill
- teachSkill
- unslopSkill
- using-git-worktreesSkill
- visual-computer-use-loopSkill
- writing-flowSkill
- writing-plansSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 128 edited versions we read keep these.
8
Distinctive
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
- Distinctive: line 38
If the decision doesn't justify ten agents, run a reduced chamber (see Scaling the chamber) or skip the skill.
- Distinctive: line 45
No jargon, buzzwords, or hedging.
- Distinctive: line 59
If it's vague, ask one clarifying question (AskUserQuestion) before convening.
- Distinctive: line 178
Strip self-identifying language: before Stage 2 — a proposal that announces its lens isn't blind.
- Distinctive: line 189
If the user has opted into the Workflow tool, this pipeline maps cleanly onto it (Stage 1 parallel → anonymize → Stage 2 parallel → …
- Distinctive: line 193
Only when it changes something real:
- Distinctive: line 199
Don't paper-trail every council.
- Distinctive: line 203
Default to one pass. If the user wants another, keep the new question focused, include the prior verdict only if necessary, and re-run …
“Common” is measured: kept by at least 6 in 10 of the 128 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Council — a decision chamber that returns a verdict
For a decision that is genuinely ambiguous and high-stakes, one opinion — yours or the chat's — isn't enough. Council runs the decision through three stages:
- Five advisors each attack the question from a different lens, independently and blind to the conversation.
- A blind teardown — every proposal is anonymized, shuffled, and handed to a fresh reviewer who tries to destroy it without knowing who wrote it.
- A chairman — a fresh agent, also blind to the chat — reads all of it and delivers a verdict.
This is eleven subagents in total. It is the wrong tool for most decisions. Use it when the call is hard to reverse, the paths are credible and conflicting, and being wrong is expensive. Otherwise answer directly or use a lighter skill.
The output is a verdict, not an answer — one decision, the reasoning that survived attack, and what would reverse it.
When to use
- A hard go / no-go or strategic tradeoff with no obvious winner.
- The decision is expensive to reverse (architecture, hiring, a public commitment, a rewrite).
- The conversation has been circling one answer and you suspect premature consensus.
- The user explicitly wants to be challenged, or asks for "the council."
When NOT to use
| If you're really trying to… | Use instead |
| Break a feature into implementation steps | writing-plans |
| Turn a fuzzy idea into an approved spec | brainstorming |
| Stress-test one plan you already favor | grill-me |
| Design an interface or module contract | api-design |
| Review code for bugs, safety, or quality | /code-review, rust-review |
| Make a low-stakes or easily-reversible call | just decide |
| Answer a straight factual question | just answer |
If the decision doesn't justify ten agents, run a reduced chamber (see Scaling the chamber) or skip the skill.
Voice — keep it plain
The whole point of the chamber is that you can follow the reasoning and judge it yourself. So every agent writes in plain, spoken English — the way you'd explain a decision to a smart friend over coffee, not the way a consultant writes a memo. The rule, applied to advisors, reviewers, and the chairman alike:
- Short sentences. Everyday words.
- No jargon, buzzwords, or hedging. If a technical term is unavoidable, define it in a few words.
- Say the thing directly — no throat-clearing, no "it's important to note," no inflated claims.
- Make the reasoning traceable: plain cause-and-effect, so you can see why, not just what.
This instruction is baked into each prompt below, because the subagents don't share your plain-voice skill — the rule has to travel with the prompt. The verdict especially must read clean on the first pass.
Stage 0 — Frame the question
Reduce the decision to one explicit prompt the advisors will all answer:
- What are we actually deciding?
- What constraints are fixed?
- What counts as success?
If it's vague, ask one clarifying question (AskUserQuestion) before convening. Then gather the minimal context the advisors need — relevant files, metrics, constraints. Keep it compact; this exact packet (question + context) is what every Stage 1 advisor receives, and nothing more.
Stage 1 — The five advisors
Launch all five as fresh parallel subagents (Agent/Task; see dispatching-parallel-agents). Each gets the framed question and the compact context packet — never the conversation transcript. That blindness is the anti-anchoring mechanism: feed them the chat and you get five rewordings of the answer you already had.
| Advisor | Mandate |
| Contrarian | The devil's advocate. Assume the decision was made and it failed — explain how. Find the landmines and failure modes, argue against the idea even if privately persuaded. |
| First-Principles Thinker | Ignore the framing and the options entirely. Decompose the problem to its fundamental truths, rebuild a recommendation from zero, and don't anchor on how the question was posed — you may land somewhere completely different. |
| Expansionist | Zoom out. The proposer is too close to see it. Surface second-order effects, opportunity cost, and the upside and downside that are invisible up close — at 10× scale and in three years. |
| Outsider | Strip away all industry context, jargon, and insider assumptions. Approach it as someone from a different field would, bring one cross-domain analogy, and name the insider assumption most worth dropping. |
| Executor | Skip the philosophy. Name the single most important actionable next step, startable today. Bias hard toward momentum and the smallest reversible move that's right regardless of the final call. |
Prompt shape for each:
You are the [ADVISOR] on a decision council. You are blind to any prior discussion.
Decision:
[framed question]
Context:
[the compact packet — nothing else]
Your mandate:
[the advisor's mandate from the table]
Respond with exactly:
1. Position — your recommendation in 1-2 sentences
2. Reasoning — 3 concise bullets
3. Sharpest point — the one thing your lens sees that the others will miss
4. Biggest risk in YOUR own recommendation
Be direct. No hedging. Do not reference your role by name in the body. Under 300 words.
Write in plain, spoken English: short sentences, everyday words, no jargon or buzzwords. Explain it like you would to a smart friend, not in a memo.Stage 2 — The blind teardown
Now turn the five proposals over to adversaries who don't know where they came from.
- Anonymize. Strip every proposal of role labels and self-identifying language (delete any "as the executor…", lens-naming, or tells). Relabel them Proposal A–E.
- Shuffle. Reorder so position carries no signal.
- Dispatch one fresh reviewer per proposal (parallel). Each reviewer sees only its assigned anonymized proposal — no authorship, no transcript, no sibling proposals.
Why blind: a reviewer who knows "this is the Executor" defers to action bias; one who knows "this is the Outsider" discounts it as naïve. Anonymity forces judging the argument, not its source.
Reviewer prompt shape:
You are a reviewer on a decision council. Below is one proposal. You do not know
who wrote it or what perspective produced it. Tear it apart on the merits.
Proposal [X]:
[anonymized proposal]
Respond with exactly:
1. Strongest flaw — where the reasoning is weakest
2. Hidden assumption — what it quietly takes for granted
3. Failure condition — what would have to be true for this to be wrong
4. Survival score — 1 (collapses) to 5 (holds up), one line of justification
Be ruthless and specific. Reward nothing for confidence.
Write in plain, spoken English: short sentences, everyday words, no jargon. State each flaw the way you'd point it out to a colleague, not in a review memo.Stage 3 — The chairman's verdict
The chairman is a fresh subagent too — blind to the conversation, so the verdict isn't colored by the chat's drift or the user's apparent leaning. You (the orchestrator) assemble the board and dispatch it; you do not write the verdict yourself.
Assemble the board: the framed question, the compact context, all five proposals with their lenses re-attached (you hold the mapping), and each proposal's teardown paired to it. Then dispatch one chairman:
You are the chairman of a decision council. You are blind to any prior discussion —
judge only the board below.
Decision:
[framed question]
Context:
[the compact packet]
The board — five proposals, each with the lens that produced it and the blind teardown it received:
[Proposal · Contrarian]: … [Teardown · survival score]: …
[Proposal · First-Principles]: … [Teardown · survival score]: …
[Proposal · Expansionist]: … [Teardown · survival score]: …
[Proposal · Outsider]: … [Teardown · survival score]: …
[Proposal · Executor]: … [Teardown · survival score]: …
Weigh what SURVIVED attack, not what sounded best. A proposal the teardown gutted
loses, however eloquent. A proposal with a low survival score but one irreplaceable
insight contributes that insight, not the whole. Issue a verdict, not a survey —
do not retreat to "it depends".
Write the whole verdict in plain, spoken English: short sentences, everyday words,
no jargon, buzzwords, or hedging. Someone outside the field should follow your
reasoning on the first read. Show the cause and effect — don't just assert the call,
let the reader see why it follows.
Respond in exactly this shape:
## Verdict: [decision title]
**The call:** [one decisive sentence, in plain words]
**Why:** [2-4 lines — the reasoning that held up, as plain cause-and-effect]
**What nearly killed it:** [the strongest surviving objection, in plain terms — and why it doesn't flip the call, or what guardrail it forces]
**First-principles check:** [did rebuilding from zero agree, or surface a better frame?]
**Do this now:** [the single next action, pressure-tested by the teardown]
**This reverses if:** [the specific new information that would change the verdict]Relay the chairman's verdict to the user verbatim. Optionally precede it with a compact Chamber notes block — each advisor's one-line position and survival score — so the disagreement stays legible. Add your own commentary only if the user asks; the verdict is the deliverable.
Independence rules
These are what make the chamber more than five echoes:
- Stage 1 advisors get only the framed question + compact context. Never the transcript.
- Stage 2 reviewers get a single anonymized, shuffled proposal. No authorship, no transcript, no siblings.
- Strip self-identifying language before Stage 2 — a proposal that announces its lens isn't blind.
- The chairman is itself a fresh subagent: it sees the whole board (proposals with lenses re-attached + paired teardowns) but never the conversation, so the verdict isn't colored by the chat or the user's apparent preference. The orchestrator assembles the board, dispatches the chairman, and relays the verdict verbatim.
Scaling the chamber
The full chamber is expensive. Match the ceremony to the stakes:
- Full (11 subagents) — irreversible, expensive-to-be-wrong calls.
- Reduced (3 advisors — Contrarian, First-Principles, Executor — single teardown pass) — meaningful but recoverable decisions.
- None — low stakes or an obvious answer. Just decide.
If the user has opted into the Workflow tool, this pipeline maps cleanly onto it (Stage 1 parallel → anonymize → Stage 2 parallel → chairman). You cannot launch a workflow without that opt-in — default to dispatching agents directly.
Persisting the verdict
Only when it changes something real:
- Changes active work → update the relevant
docs/spec or the GitHub/Linear issue. - Durable architectural choice → record it as an ADR in
docs/adr/. - Worth carrying forward → capture via
session-handoff.
Don't paper-trail every council.
Multi-round
Default to one pass. If the user wants another, keep the new question focused, include the prior verdict only if necessary, and re-run Stages 1–3 fresh — the value is in repeating the independence, not in accumulating context.
Anti-patterns
- Running the full chamber on a decision that doesn't earn ten agents.
- Feeding advisors or reviewers the conversation transcript.
- Letting proposals reach Stage 2 with their lens still attached (breaks the blind review).
- A chairman who hedges into "it depends" instead of issuing a verdict.
- A verdict or proposal written in jargon and memo-speak the reader has to decode.
- Weighing proposals by eloquence instead of what survived the teardown.
- Convening around a vague question instead of framing it first.
- Persisting every verdict regardless of whether it changed anything.
Related skills
grill-me— relentlessly interrogate one plan you already favor (single-track, vs. the chamber's many lenses)brainstorming— when you need to generate options, not adjudicate between themdispatching-parallel-agents— the underlying mechanism for launching each stage concurrentlyteach(FIRST-PRINCIPLES.md) — the decomposition method the First-Principles advisor uses
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
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.

