council

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:

1. Council Recommendation (the full Round 3 block, written FIRST, in 100 words or less — decision, rationale, confidence)
2. Round 1: Initial Perspectives (brief, 50 words max each)
3. 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

1. Provide clear context - Members need background to deliberate effectively
2. State constraints upfront - Time, budget, team skills, etc.
3. Define success criteria - What would a good decision look like?
4. Set urgency level - Affects depth of deliberation

During Deliberation

1. Let each member speak fully - Don't interrupt perspectives
2. Note tensions explicitly - Disagreements are valuable signal
3. Seek synthesis, not consensus - Perfect agreement is suspicious
4. Capture dissent - Minority views may prove prescient

After Decision

1. Document the outcome - What was actually decided
2. Revisit periodically - Was the decision correct?
3. 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.