/skill

Council

Use four voices to test a hard choice:

• Architect: long-term quality and upkeep
• Skeptic: weak claims and simpler paths
• Pragmatist: speed and real-world needs
• Critic: risks, edge cases, and failure

Use this skill to make a choice under doubt. Do not use it for code review, task plans, or system design.

When to Use It

Use the council when:

• Two or more sound choices exist.
• No choice is a clear winner.
• The user asks for several views or a dissenting view.
• A go or no-go call needs a hard test.
• The current chat may bias the answer.
• The costs, risks, or gains need to be made clear.

Common cases:

• Monorepo or many repos
• Ship now or wait
• Feature flag or full launch
• Cut scope or keep the wider plan

When Not to Use It

Do not use the council to delay a clear choice.

Rules

• Use one clear question.
• Give each voice the same facts.
• Give each outside voice only the facts it needs.
• Do not send the full chat unless a key fact cannot be split out.
• Keep each view short and firm.
• Show real dissent. Do not force a false deal.
• Do not let the loudest voice win by default.
• Do not let the council take an action. It only gives advice.
• Ask the user before any hard-to-undo act.
• If facts are missing, say what is missing. Do not make them up.

Steps

1. State the Choice

Turn the issue into one question.

Include:

• What must be chosen
• The real choices
• Key limits
• What success means
• When the choice must be made

If the answer would change based on one missing fact, ask one clear question first. If not, state a safe guess and continue.

2. Gather Only Key Facts

For a codebase choice, collect only the files, code, issue text, test results, or data needed for the call.

For a broad choice, skip repo details that will not change the answer.

Mark each claim as one of these:

• Fact
• Guess
• User goal
• Hard limit

If key facts clash, show the clash before calling the council.

3. Write the Architect View First

Before reading the other views, write:

• The first choice
• The three best reasons for it
• Its largest risk
• What fact would change the choice

This keeps the final answer from copying the last voice heard.

4. Start Three Fresh Voices

Run the Skeptic, Pragmatist, and Critic at the same time when tools allow it.

Each voice gets:

• The choice question
• The same key facts
• Its role
• No extra chat history

Use this prompt:

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

Question:
[one clear choice question]

Facts and limits:
[only the facts needed for this choice]

Reply with:
1. Choice: Pick one path in 1 or 2 sentences.
2. Reasons: Give 3 short bullets.
3. Main risk: Name the biggest risk in your path.
4. Missed point: Name one thing the other voices may miss.
5. Change trigger: Name one fact that would change your choice.

Be direct. Do not hide behind "it depends." If a fact is missing,
name it. Use fewer than 250 words.

Role notes:

• Skeptic: Test the way the question is framed. Break weak claims. Offer the simplest sound path.
• Pragmatist: Favor speed, low cost, clear use, and work that can ship.
• Critic: Find harm, edge cases, lock-in, rollback trouble, and ways the plan can fail.

If fresh voices cannot be started, write the three views one at a time. Keep each role separate. State that the views were not independent.

5. Compare the Views

Use these checks:

• Do not reject a view without a reason.
• Keep the strongest point against the final choice.
• If two outside voices reject the first choice, treat that as a strong sign.
• If a voice changes the first choice, say so.
• If all voices agree too fast, test the best other path once.
• If the vote is tied, use the user's goals and hard limits as the tie break.
• If risk is high and proof is weak, favor a small test or a path that can be undone.
• If no safe choice can be made, stop and name the missing fact or needed owner.

A vote is not the final answer. The reasons matter more than the count.

6. Give a Short Verdict

Use this form:

## Council: [short title]

**Architect:** [choice]
[main reason]

**Skeptic:** [choice]
[main reason]

**Pragmatist:** [choice]
[main reason]

**Critic:** [choice]
[main reason]

### Verdict

- **Shared view:** [where the voices agree]
- **Strongest dissent:** [best case against the choice]
- **Premise check:** [did the Skeptic reject the question or its claims?]
- **Recommendation:** [one clear path]
- **Next step:** [one small action]
- **Recheck if:** [fact or event that should reopen the choice]

Keep it easy to scan on a phone.

Edge Cases

• If the user names only one path, ask for the other path or test "do it" against "do not do it."
• If one choice breaks a hard limit, remove it before the council.
• If the choice affects safety, law, health, money, or private data, state that risk and use checked facts.
• If the choice is hard to undo, include a rollback plan or a small trial.
• If the user has already chosen, use the council to test that choice. Do not pretend the choice is still open.
• If new facts arrive after the verdict, run a new round only if they could change the call.
• If the voices agree but for different reasons, show those reasons.
• If there is no good path, choose the least harmful path and state the cost.

Saving the Result

Do not write quick notes to ~/.claude/notes or other hidden paths.

Save the result only when it changes real work:

• Use knowledge-ops for a lasting lesson.
• Use /save-session for a session note.
• Update the right GitHub or Linear issue when the choice changes active work.

Do not save small or short-lived choices.

More Rounds

Use one round by default.

Run another round only when the user asks, or when a new key fact could change the result.

For a new round:

• Ask a smaller question.
• Share the old verdict only when needed.
• Keep the Skeptic as fresh as possible.
• Do not repeat points that have already been settled.

Bad Patterns

Do not:

• Use the council for code review.
• Use it for plain build work.
• Send the full chat to each voice.
• Hide dissent in the verdict.
• Turn every choice into a saved note.
• Treat a vote as proof.
• Make up facts to break a tie.
• run more rounds with no new question or fact.

Related Skills

• santa-method: Test whether work is sound.
• knowledge-ops: Save a lasting change in what the team knows.
• search-first: Gather needed source facts before the council.
• architecture-decision-records: Record a long-term system choice.

Example

Question:

Should we ship ECC 2.0 as an alpha this week, or wait one month
for a better control panel?

Facts:
- The core work passes its tests.
- The control panel lacks clear error text.
- Ten skilled users asked for early access.
- Support can help five users per week.
- The alpha can be turned off in one hour.
- Success means learning from real use without hurting trust.

Possible council:

## Council: Ship ECC 2.0 Alpha

**Architect:** Ship a small alpha now.
The core is sound, and a limited group will show what the panel truly needs.

**Skeptic:** Ship now, but question whether the panel is the real gate.
The weak error text may be fixed faster than a one-month wait.

**Pragmatist:** Ship to five users this week.
This fits the support limit and gives useful feedback soon.

**Critic:** Do not open it to all ten users at once.
Poor error text may cause support load and loss of trust.

### Verdict

- **Shared view:** A small alpha is safer than a full launch or a long wait.
- **Strongest dissent:** Bad error text may confuse users and raise support work.
- **Premise check:** The panel may not need to be complete before a small alpha.
- **Recommendation:** Fix the worst error text, then invite five users.
- **Next step:** Pick five users and write a one-page rollback plan.
- **Recheck if:** Support takes more than one day per user.

The goal is not full agreement. The goal is clear disagreement before a choice.