agentleFS
manastalukdarmanastalukdar/ai-devstudio/skills/council/SKILL.md

council

Skill1 starsChanged 7 months agoMITView on GitHub

Convene four voices (Architect, Skeptic, Pragmatist, Critic) to surface structured disagreement on an ambiguous decision or go/no-go call. Use when multiple credible paths exist and no single review agent should have the final word.

143 other projects use a version of this, 13 of them edited.

Adopted by

Most recently taken up by

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.
  • TironFoxSkill

    agent-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

  • renepfSkill

    motion-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

  • RojiosSkill

    defi-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

  • scottwaterSkill

    modernize

    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

  • RojiosSkill

    dart-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

  • scottwaterSkill

    leaving-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

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 128 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before consulting other voices, write down a starting position, its three strongest reasons, and its main risk.

    line 33
  2. Distinctive:

    Never dismiss an external view without saying why.

    line 75
  3. Distinctive:

    If a voice changed the recommendation, say so explicitly.

    line 76
  4. Distinctive:

    Always surface the strongest dissent, even when rejecting it.

    line 77
  5. Very specific:

    If the verdict is worth keeping, offer /decision-log to capture it as an ADR.

    line 99
  6. Distinctive:

    Do not write ad-hoc notes elsewhere.

    line 100
  7. Distinctive:

    Early exit: if the question has one obvious answer (no real tradeoff), say so in one line and skip convening the council.

    line 123
  8. Distinctive:

    Follow-up round requested: keep the new question narrow and pass only the prior verdict, not the full transcript, to preserve Skeptic value.

    line 136
  9. Very specific:

    Read-only advisory output.

    line 141

“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.

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

Council

Four-voice structured disagreement for ambiguous decisions and go/no-go calls.

Usage

/council <decision question>
/council <decision question> --round2   # follow-up round, prior verdict optional context

Behavior

1. Extract the real question

State explicitly: what is being decided, what constraints matter, what counts as success. If the question is vague, ask one clarifying question before proceeding.

2. Gather minimal context

Collect only the snippets, metrics, or constraints needed to judge the decision. Skip repo detail for strategic/general questions unless it changes the answer.

3. Form an initial position

Before consulting other voices, write down a starting position, its three strongest reasons, and its main risk. This prevents the synthesis from simply mirroring whichever voice speaks last.

4. Launch three independent voices

Spawn each as a fresh subagent with only the question and the compact context from step 2 — never the full conversation history. This is the anti-anchoring mechanism: a voice that inherits the discussion tends to agree with it.

Apply tiered model delegation: Skeptic and Pragmatist can run on a cheaper model (Haiku-class); reserve the stronger model for Critic or for synthesis if the decision is high-stakes.

Prompt shape per voice:

You are the [ROLE] on a four-voice decision council.

Question: [decision question]
Context: [only the relevant snippets or constraints]

Respond with:
1. Position - 1-2 sentences
2. Reasoning - 3 concise bullets
3. Risk - biggest risk in your recommendation
4. Surprise - one thing the other voices may miss

Be direct, no hedging, under 300 words.

Role emphasis:

VoiceLens
Architect (in-context)correctness, maintainability, long-term implications
Skepticpremise challenge, simplest credible alternative
Pragmatistshipping speed, operational reality
Criticedge cases, downside risk, failure modes

5. Synthesize with bias guardrails

  • Never dismiss an external view without saying why.
  • If a voice changed the recommendation, say so explicitly.
  • Always surface the strongest dissent, even when rejecting it.
  • Two voices aligning against the initial position is a real signal, not noise.

6. Present the verdict

## Council: [decision title]

**Architect:** [position] - [why]
**Skeptic:** [position] - [why]
**Pragmatist:** [position] - [why]
**Critic:** [position] - [why]

### Verdict
- Consensus: [where they align]
- Strongest dissent: [most important disagreement]
- Premise check: [did the Skeptic challenge the question itself?]
- Recommendation: [synthesized path]

7. Record the outcome

If the verdict is worth keeping, offer /decision-log to capture it as an ADR. Do not write ad-hoc notes elsewhere.

Examples

Input: /council monorepo vs polyrepo for the new services Output: four short positions plus a verdict block recommending monorepo with a named dissent from Critic on CI blast-radius, and an offer to log the decision.

Input: /council ship now or hold for polish Output: Pragmatist and Skeptic align on shipping a scoped subset; verdict flags this as the deciding signal over the initial hold-for-polish position.

Token Optimization

Expected range: 800-2,500 tokens initial (three subagent calls plus synthesis); 150-350 tokens on a --round2 follow-up that reuses the prior verdict instead of re-gathering context.

Caching: none — each council convenes fresh subagents by design, so caching a prior verdict would undermine anti-anchoring. .claude/cache/council/ is not used.

Early exit: if the question has one obvious answer (no real tradeoff), say so in one line and skip convening the council.

Patterns used: tiered model delegation (cheaper model for Skeptic and Pragmatist), progressive disclosure (verdict first, full transcripts only if asked), early exit on non-ambiguous questions.

Edge Cases

  • Question is really a code review or implementation task: redirect to /review or standard implementation instead of convening the council.
  • User wants unanimous agreement: explain that legible disagreement, not consensus, is the point; report dissent even if all four converge.
  • Follow-up round requested: keep the new question narrow and pass only the prior verdict, not the full transcript, to preserve Skeptic value.

Safety

Read-only advisory output. No file writes beyond an explicit, user-approved /decision-log entry. Never feeds subagents the full conversation history.

Related

/brainstorm for open-ended exploration before a decision exists, /first-principles to strip assumptions before framing the question, /decision-log to record the verdict as a durable ADR.

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.