council
Use when a decision has multiple credible paths and no obvious winner — convene a four-voice council (Architect, Skeptic, Pragmatist, Critic) for structured adversarial deliberation before choosing
Best use case
council is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when a decision has multiple credible paths and no obvious winner — convene a four-voice council (Architect, Skeptic, Pragmatist, Critic) for structured adversarial deliberation before choosing
Teams using council should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/council/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How council Compares
| Feature / Agent | council | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when a decision has multiple credible paths and no obvious winner — convene a four-voice council (Architect, Skeptic, Pragmatist, Critic) for structured adversarial deliberation before choosing
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Council
Convene four advisors for decisions under ambiguity:
- **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
This is for **decision-making under ambiguity**, not code review, architecture design, or implementation planning.
## When to Use
- A decision has multiple credible paths and no obvious winner
- You need explicit tradeoff surfacing before committing
- Conversational anchoring is a risk (you've been going in one direction too long)
- 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 | `evaluate-repository` or direct review |
| Breaking a feature into implementation steps | planner / Plan Mode |
| Reviewing code for bugs | `code-review` skill |
| Straight factual questions | answer directly |
| Obvious execution tasks | do the task |
## Workflow
### 1. Extract the real question
Reduce to one explicit prompt:
- What exactly are we deciding?
- What constraints matter?
- What counts as success?
If the question is vague, ask one clarifying question before convening.
### 2. 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
This anchors the synthesis so it doesn't simply mirror external voices.
### 3. Launch three subagents in parallel
Each subagent gets: the decision question + compact context + strict role. No full conversation history.
```text
# Copilot CLI tool call — launch 3 background task agents
task:
agent_type: "general-purpose"
name: "skeptic"
mode: "background"
prompt: |
You are the Skeptic on a four-voice decision council.
Question: [DECISION QUESTION]
Context: [COMPACT CONTEXT]
Challenge the framing. Question assumptions. Propose the simplest credible alternative.
Respond with:
1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in the status quo
4. Surprise — one thing the other voices may miss
Under 300 words. No hedging.
task:
agent_type: "general-purpose"
name: "pragmatist"
mode: "background"
prompt: |
You are the Pragmatist on a four-voice decision council.
[same structure — optimize for speed, simplicity, real-world execution]
task:
agent_type: "general-purpose"
name: "critic"
mode: "background"
prompt: |
You are the Critic on a four-voice decision council.
[same structure — surface downside risk, edge cases, failure modes]
```
**Copilot CLI tip — diversify the council:** When practical, assign different model
families or providers to different voices via per-agent `model` overrides. The goal is
not novelty for its own sake, but reducing the chance that all four voices inherit the
same model bias. See [`multi-model-strategy`](../../copilot-exclusive/multi-model-strategy/SKILL.md)
for concrete pairing guidance.
Then `read_agent` each result.
### 4. Synthesize with bias guardrails
- 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
### 5. Output format
```markdown
## Council Verdict: [Decision Question]
### Positions
| Voice | Recommendation | Core Reasoning |
|-------|---------------|----------------|
| Architect | [position] | [1-line summary] |
| Skeptic | [position] | [1-line summary] |
| Pragmatist | [position] | [1-line summary] |
| Critic | [position] | [1-line summary] |
### Strongest Dissent
[The best argument against the recommended path]
### Verdict
**[Chosen path]**
Rationale: [2-3 sentences explaining the choice and why dissent was acknowledged but not followed]
Next action: [Concrete first step]
```
## See Also
- [multi-model-strategy](../../copilot-exclusive/multi-model-strategy/SKILL.md) — choosing which model to use
- [plan-mode-mastery](../../copilot-exclusive/plan-mode-mastery/SKILL.md) — structured planning before execution
- [team-planner](../../copilot-exclusive/team-planner/SKILL.md) — multi-agent coordination for large tasksRelated Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.