council

name	council
description	Convenes multi-agent council deliberations for decisions requiring diverse perspectives. Use when the user asks "call a council", "gather specialists", "get a council opinion", or "what do the experts think". Also activate when the user wants a structured debate between domain-specific viewpoints. Not for single-perspective research (use research) or architectural decisions that don't need multi-agent deliberation (use architecture).
version	2.0.0-alpha.5

Council

Convene multi-agent councils for complex decisions requiring diverse expert perspectives.

Critical Rules

Always

• Select odd number of agents (5 or 7) — never even
• Spawn ALL agents in parallel in a single response
• Select and state the council composition, then proceed directly to spawning
• Document each perspective and create synthesis with consensus/disagreements
• Wait for explicit user decision — council advises, user decides
• Archive council after decision recorded in the journal
• Log decision to the project journal: loaf journal log "decision(scope): council outcome and user's choice"

Never

• Use even number of agents (risks ties)
• Spawn agents sequentially — parallel only
• Pause for composition approval before spawning unless the user explicitly asks for it
• Make the decision yourself — present synthesis, let user choose
• Skip documenting minority perspectives

Verification

After work completes, verify:

• Council file created at .agents/councils/{YYYYMMDD}-{HHMMSS}-{topic}.md
• All 5-7 agents spawned and perspectives collected
• Synthesis includes consensus points, disagreements, trade-offs
• User decision recorded in council file
• Decision logged to the project journal
• Council archived after the decision is recorded in the journal

Quick Reference

Council Composition

Select 5-7 agents covering relevant domains:

• Technical domains (backend, frontend, infrastructure)
• Quality domains (security, performance, UX)
• Process domains (testing, DevOps, documentation)

Spawn Pattern

All agents in ONE response:

Spawn agent 1 (domain X) + agent 2 (domain Y) + agent 3 (domain Z) + ...

Each agent receives:

• Decision question and options
• Domain-specific analysis factors
• Instruction to focus on THEIR expertise only

Synthesis Structure

1. Consensus points (all agents agree)
2. Key disagreements (different perspectives)
3. Trade-off analysis per option
4. Overall recommendation with confidence level
5. Explicit deferral if genuinely ambiguous

Spec and Linear Parent Linkage

Councils stay local. Even when the workspace uses Linear-native mode, council files live in .agents/councils/ — they are deliberation artifacts, not executable work, and belong with specs in git.

When a council resolves a spec's open questions:

• Include the spec ID in council frontmatter (e.g., spec: SPEC-024). This is already the common pattern.
• If the spec's linear_parent has been populated by /breakdown, also include linear_parent: ENG-198 in council frontmatter so a reader on Linear can trace back to the deliberation.
• Do not post council content to the Linear parent issue. A brief one-line reference ("Resolved via council 2026-04-21 — see .agents/councils/…") in a sub-issue comment is sufficient if the council drove a specific task decision.

Topics

Topic	Reference	Use When
Council Template	templates/council.md	Creating council files
Composition	council/SKILL.md	Selecting council agents
Delegation	orchestration/references/delegation.md	Spawning Amp check/agent mode or new thread