| name | Council |
| description | Multi-perspective deliberation for complex decisions. Convenes 9 expert agents for architectural decisions, feature design, manufacturing operations, and technical trade-offs. USE WHEN user says 'council', 'convene council', 'deliberate', 'quick-council', 'multiple perspectives', 'architectural decision', 'design review', or 'trade-off analysis'. |
Council - Multi-Agent Deliberation System
The Council convenes multiple expert perspectives for complex decisions that benefit from diverse viewpoints.
When to Convene
Use the Council for:
- Architectural decisions - System design choices with long-term implications
- Feature design - User-facing functionality requiring UX + engineering balance
- Technical trade-offs - Performance vs maintainability, speed vs correctness
- Risk assessment - Evaluating potential failure modes from multiple angles
- Strategic direction - Major pivots or technology choices
Do NOT use for:
- Simple bug fixes
- Routine implementation tasks
- Well-defined requirements with clear solutions
- Time-critical decisions (Council adds deliberation overhead)
Workflow Routing
| Trigger | Workflow File | Use When |
|---|
/council "<question>", "convene council", "deliberate" | workflows/Convenecouncil.md | Full 9-member deliberation for architectural decisions, feature design, risk assessment, strategic direction |
/quick-council <pair> "<question>", "quick council" | workflows/Quickcouncil.md | Fast 2-member deliberation for time-sensitive or single-domain decisions (see Quick Council table below for pairs) |
Council Members
The Council consists of 9 permanent members, each bringing distinct expertise:
| Member | Name | Perspective | Key Questions |
|---|
| Architect | Serena | System design, scalability, patterns | "How does this fit the larger system?" |
| Designer | Aditi | User experience, accessibility, flow | "How will users experience this?" |
| Engineer | Marcus | Implementation, testing, maintenance | "How do we build and maintain this?" |
| Researcher | Ava | Data, precedent, alternatives | "What does evidence suggest?" |
| Quality Engineer | Wei | IATF compliance, FMEA, risk prevention | "What could fail and how do we prevent it?" |
| Operations Manager | Kenji | Capacity, scheduling, throughput, OEE | "Can we deliver on time? What's the bottleneck?" |
| Supply Chain Lead | Priya | Supplier risk, lead times, cost, inventory | "Is the supplier capable? What's the landed cost?" |
| Finance Controller | David | ROI, cash flow, margin, capex | "What's the payback? How does this affect margin?" |
| Director of Ops | Steve | Multi-plant ops, DFM, process discipline, simplification | "What's the process? Can we actually hold this?" |
Member Personas
Architect_Serena:
role: Systems Architect
focus: Big picture, patterns, scalability
style: Strategic, principled, forward-thinking
questions:
- "What are the system-wide implications?"
- "Does this align with our architectural principles?"
- "How will this scale?"
- "What patterns apply here?"
Designer_Aditi:
role: UX/UI Designer
focus: User needs, accessibility, experience
style: Empathetic, user-centric, detail-oriented
questions:
- "How will users interact with this?"
- "Is this accessible to all users?"
- "What's the cognitive load?"
- "Does this match user mental models?"
Engineer_Marcus:
role: Senior Engineer
focus: Implementation, testing, technical debt
Deliberation Process
Round 1: Initial Perspectives (Parallel)
Each member provides independent analysis without seeing others' input.
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Architect │ │ Designer │ │ Engineer │ │ Researcher │
│ Serena │ │ Aditi │ │ Marcus │ │ Ava │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
▼ ▼ ▼ ▼
[Analysis] [Analysis] [Analysis] [Analysis]
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Quality │ │ Operations │ │Supply Chain │ │ Finance │
│ Wei │ │ Kenji │ │ Priya │ │ David │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
▼ ▼ ▼ ▼
[Analysis] [Analysis] [Analysis] [Analysis]
Output format per member (keep concise — 50 words MAX per perspective). Brevity is required. If you find yourself writing more than 50 words for any member, stop and move on.
⚠️ MANDATORY OUTPUT ORDER: To guarantee the recommendation is never lost to truncation, output sections in this order:
- Council Recommendation (the full Round 3 block, written FIRST, in 100 words or less — decision, rationale, confidence)
- Round 1: Initial Perspectives (brief, 50 words max each)
- Round 2: Cross-Perspective Analysis (brief, only if space remains)
The Recommendation block must appear at the TOP of the response, immediately after acknowledging the topic. Do not write Round 1 or Round 2 before it. This is non-negotiable — a truncated response that still contains the Recommendation block is a success; a truncated response missing it is a failure.
Round 2: Direct Responses (Sequential)
Members respond to each other's points, identifying agreements and disagreements.
## Cross-Perspective Analysis
### Agreements
- [Point where multiple members align]
### Tensions
- [Architect vs Engineer]: [Description of tension]
- [Designer vs Researcher]: [Description of tension]
### Questions Raised
- [Question that emerged from discussion]
Round 3: Synthesis (MANDATORY — THIS IS THE MOST IMPORTANT SECTION)
CRITICAL RULE: The council MUST always complete Round 3 and deliver a concrete recommendation. Do NOT end mid-deliberation. Even under uncertainty, commit to a direction (e.g., "Outsource if lead time < 8 weeks, otherwise insource") rather than leaving the decision open. "It depends" without a concrete decision is a failure mode.
If you are running out of space: Skip or abbreviate Round 1 and Round 2 entirely — the Recommendation block (already written first, per the mandatory output order above) is non-negotiable and must appear in every council response. Keep the ENTIRE response, including all perspectives, under 600 words total.
Consolidate into unified recommendation with dissenting notes.
## Council Recommendation
**Decision:** [Clear recommendation]
**Rationale:** [Why this recommendation]
**Implementation Notes:**
- [From Engineer perspective]
- [From Architect perspective]
**User Impact:**
- [From Designer perspective]
**Evidence Base:**
- [From Researcher perspective]
**Risk & Compliance:**
- [From Quality Engineer perspective]
**Operations Impact:**
- [From Operations Manager perspective]
**Supply Chain & Cost:**
- [From Supply Chain Lead perspective]
**Financial Analysis:**
- [From Finance Controller perspective]
**Dissenting Views:**
- [Any unresolved disagreements]
**Confidence Level:** [High/Medium/Low]
> ⚠️ **Completion Check:** If you have not written the above recommendation block, you are not done. Complete the deliberation before responding.
Invocation Methods
Via Workflow
/council "Should we use GraphQL or REST for the new API?"
Via Skill Trigger
When encountering a complex decision, invoke:
I'm facing an architectural decision that would benefit from multiple perspectives.
Let me convene the Council to deliberate on: [decision description]
Quick Council (2-Member Variant)
For faster deliberation, use a 2-member council with the most relevant perspectives:
| Decision Type | Members | Rationale |
|---|
| API design | Architect + Engineer | System + implementation |
| UI feature | Designer + Engineer | UX + buildability |
| Performance | Engineer + Researcher | Implementation + data |
| Security | Architect + Researcher | System + precedent |
| Manufacturing process | Quality + Engineer | Risk prevention + implementation |
| Compliance/audit | Quality + Researcher | IATF requirements + evidence |
| Product design | Quality + Architect | Failure modes + system design |
| New program launch | Operations + Quality | Capacity + risk |
| Make/buy decision | Supply Chain + Finance | Cost + capability |
| Capex investment | Finance + Operations | ROI + capacity need |
| Supplier issue | Supply Chain + Quality | Capability + compliance |
| Capacity planning | Operations + Finance | Throughput + investment |
| Design tolerance review | Director of Ops + Quality | DFM + risk prevention |
| Process simplification | Director of Ops + Operations | SDSS + capacity |
| Engineering change review | Director of Ops + Engineer | Manufacturability + implementation |
| Multi-plant issue | Director of Ops + Quality | Standardization + containment |
/quick-council architect+engineer "Should we cache at the API or database layer?"
Council Output Storage
Council deliberations are stored for future reference:
~/.claude/MEMORY/Decisions/
├── 2026-01-17_graphql-vs-rest.md
├── 2026-01-15_auth-architecture.md
└── ...
Format:
# Council Decision: [Topic]
**Date:** [timestamp]
**Convened by:** [user/auto]
**Urgency:** [high/medium/low]
## Context
[Background and constraints]
## Round 1: Initial Perspectives
[Member analyses]
## Round 2: Cross-Analysis
[Agreements, tensions, questions]
## Round 3: Recommendation
[Final recommendation with confidence]
## Outcome
[What was actually decided/implemented - filled in later]
Best Practices
When Convening
- Provide clear context - Members need background to deliberate effectively
- State constraints upfront - Time, budget, team skills, etc.
- Define success criteria - What would a good decision look like?
- Set urgency level - Affects depth of deliberation
During Deliberation
- Let each member speak fully - Don't interrupt perspectives
- Note tensions explicitly - Disagreements are valuable signal
- Seek synthesis, not consensus - Perfect agreement is suspicious
- Capture dissent - Minority views may prove prescient
After Decision
- Document the outcome - What was actually decided
- Revisit periodically - Was the decision correct?
- Learn from mistakes - Update member heuristics
Integration with Algorithm
The Council integrates with the 7-phase Algorithm:
| Phase | Council Role |
|---|
| OBSERVE | Gather context for Council |
| THINK | Council deliberation happens here |
| PLAN | Implement Council recommendation |
| BUILD | Define ISC based on recommendation |
| EXECUTE | Build according to plan |
| VERIFY | Test against Council criteria |
| LEARN | Evaluate decision quality |
Related Skills
- Algorithm - Council fits in THINK phase
- A3CriticalThinking - Structured problem-solving
- Agent Personas - Individual member definitions
Examples
Example 1: Database Choice
Topic: "Should we use PostgreSQL or MongoDB for the new service?"
Architect (Serena): Recommends PostgreSQL for relational data integrity and established patterns. Concerns about eventual consistency with MongoDB.
Designer (Aditi): Notes that query flexibility affects how quickly we can iterate on features. Prefers whatever enables faster UX iteration.
Engineer (Marcus): PostgreSQL has better tooling and team experience. MongoDB would require training. Testing is more straightforward with SQL.
Researcher (Ava): Industry data shows PostgreSQL outperforms for our read/write ratio. MongoDB better for document-heavy workloads we don't have.
Recommendation: PostgreSQL (High confidence) - All members aligned based on team experience and workload characteristics.
Example 2: Feature Scope
Topic: "Should we ship MVP without offline support?"
Architect (Serena): Offline support is architecturally significant - harder to add later. But MVP needs to ship.
Designer (Aditi): User research shows 40% use app in low-connectivity areas. Offline is critical for them, but we can ship to others first.
Engineer (Marcus): Offline adds 3 weeks. Suggests shipping online-only with offline-ready architecture.
Researcher (Ava): Competitors without offline have 2-star reviews. But first-mover advantage matters more in our segment.
Recommendation: Ship online-only MVP with offline-ready architecture (Medium confidence) - Tension between user needs and time-to-market. Revisit after launch data.
