mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-10 11:23:32 +08:00
feat: add council decision workflow
This commit is contained in:
Affaan Mustafa
203
skills/council/SKILL.md
Normal file
203
skills/council/SKILL.md
Normal file
@@ -0,0 +1,203 @@
|
||||
---
|
||||
name: council
|
||||
description: Convene a four-voice council for ambiguous decisions, tradeoffs, and go/no-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Council
|
||||
|
||||
Convene four advisors for ambiguous decisions:
|
||||
- the in-context Claude voice
|
||||
- a Skeptic subagent
|
||||
- a Pragmatist subagent
|
||||
- a Critic subagent
|
||||
|
||||
This is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use council when:
|
||||
- a decision has multiple credible paths and no obvious winner
|
||||
- you need explicit tradeoff surfacing
|
||||
- the user asks for second opinions, dissent, or multiple perspectives
|
||||
- conversational anchoring is a real risk
|
||||
- a go / no-go call would benefit from adversarial challenge
|
||||
|
||||
Examples:
|
||||
- monorepo vs polyrepo
|
||||
- ship now vs hold for polish
|
||||
- feature flag vs full rollout
|
||||
- simplify scope vs keep strategic breadth
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
| Instead of council | Use |
|
||||
| --- | --- |
|
||||
| Verifying whether output is correct | `santa-method` |
|
||||
| Breaking a feature into implementation steps | `planner` |
|
||||
| Designing system architecture | `architect` |
|
||||
| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |
|
||||
| Straight factual questions | just answer directly |
|
||||
| Obvious execution tasks | just do the task |
|
||||
|
||||
## Roles
|
||||
|
||||
| Voice | Lens |
|
||||
| --- | --- |
|
||||
| Architect | correctness, maintainability, long-term implications |
|
||||
| Skeptic | premise challenge, simplification, assumption breaking |
|
||||
| Pragmatist | shipping speed, user impact, operational reality |
|
||||
| Critic | edge cases, downside risk, failure modes |
|
||||
|
||||
The three external voices should be launched as fresh subagents with **only the question and relevant context**, not the full ongoing conversation. That is the anti-anchoring mechanism.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Extract the real question
|
||||
|
||||
Reduce the decision to one explicit prompt:
|
||||
- what are we deciding?
|
||||
- what constraints matter?
|
||||
- what counts as success?
|
||||
|
||||
If the question is vague, ask one clarifying question before convening the council.
|
||||
|
||||
### 2. Gather only the necessary context
|
||||
|
||||
If the decision is codebase-specific:
|
||||
- collect the relevant files, snippets, issue text, or metrics
|
||||
- keep it compact
|
||||
- include only the context needed to make the decision
|
||||
|
||||
If the decision is strategic/general:
|
||||
- skip repo snippets unless they materially change the answer
|
||||
|
||||
### 3. Form the Architect position first
|
||||
|
||||
Before reading other voices, write down:
|
||||
- your initial position
|
||||
- the three strongest reasons for it
|
||||
- the main risk in your preferred path
|
||||
|
||||
Do this first so the synthesis does not simply mirror the external voices.
|
||||
|
||||
### 4. Launch three independent voices in parallel
|
||||
|
||||
Each subagent gets:
|
||||
- the decision question
|
||||
- compact context if needed
|
||||
- a strict role
|
||||
- no unnecessary conversation history
|
||||
|
||||
Prompt shape:
|
||||
|
||||
```text
|
||||
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. Keep it under 300 words.
|
||||
```
|
||||
|
||||
Role emphasis:
|
||||
- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative
|
||||
- Pragmatist: optimize for speed, simplicity, and real-world execution
|
||||
- Critic: surface downside risk, edge cases, and reasons the plan could fail
|
||||
|
||||
### 5. Synthesize with bias guardrails
|
||||
|
||||
You are both a participant and the synthesizer, so use these rules:
|
||||
- do not dismiss an external view without explaining why
|
||||
- if an external voice changed your recommendation, say so explicitly
|
||||
- always include the strongest dissent, even if you reject it
|
||||
- if two voices align against your initial position, treat that as a real signal
|
||||
- keep the raw positions visible before the verdict
|
||||
|
||||
### 6. Present a compact verdict
|
||||
|
||||
Use this output shape:
|
||||
|
||||
```markdown
|
||||
## Council: [short decision title]
|
||||
|
||||
**Architect:** [1-2 sentence position]
|
||||
[1 line on why]
|
||||
|
||||
**Skeptic:** [1-2 sentence position]
|
||||
[1 line on why]
|
||||
|
||||
**Pragmatist:** [1-2 sentence position]
|
||||
[1 line on why]
|
||||
|
||||
**Critic:** [1-2 sentence position]
|
||||
[1 line on why]
|
||||
|
||||
### Verdict
|
||||
- **Consensus:** [where they align]
|
||||
- **Strongest dissent:** [most important disagreement]
|
||||
- **Premise check:** [did the Skeptic challenge the question itself?]
|
||||
- **Recommendation:** [the synthesized path]
|
||||
```
|
||||
|
||||
Keep it scannable on a phone screen.
|
||||
|
||||
## Persistence Rule
|
||||
|
||||
Do **not** write ad-hoc notes to `~/.claude/notes` or other shadow paths from this skill.
|
||||
|
||||
If the council materially changes the recommendation:
|
||||
- use `knowledge-ops` to store the lesson in the right durable location
|
||||
- or use `/save-session` if the outcome belongs in session memory
|
||||
- or update the relevant GitHub / Linear issue directly if the decision changes active execution truth
|
||||
|
||||
Only persist a decision when it changes something real.
|
||||
|
||||
## Multi-Round Follow-up
|
||||
|
||||
Default is one round.
|
||||
|
||||
If the user wants another round:
|
||||
- keep the new question focused
|
||||
- include the previous verdict only if it is necessary
|
||||
- keep the Skeptic as clean as possible to preserve anti-anchoring value
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- using council for code review
|
||||
- using council when the task is just implementation work
|
||||
- feeding the subagents the entire conversation transcript
|
||||
- hiding disagreement in the final verdict
|
||||
- persisting every decision as a note regardless of importance
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `santa-method` — adversarial verification
|
||||
- `knowledge-ops` — persist durable decision deltas correctly
|
||||
- `search-first` — gather external reference material before the council if needed
|
||||
- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy
|
||||
|
||||
## Example
|
||||
|
||||
Question:
|
||||
|
||||
```text
|
||||
Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
|
||||
```
|
||||
|
||||
Likely council shape:
|
||||
- Architect pushes for structural integrity and avoiding a confused surface
|
||||
- Skeptic questions whether the UI is actually the gating factor
|
||||
- Pragmatist asks what can be shipped now without harming trust
|
||||
- Critic focuses on support burden, expectation debt, and rollout confusion
|
||||
|
||||
The value is not unanimity. The value is making the disagreement legible before choosing.
|
||||
Reference in New Issue
Block a user