/council

name: council
description: |
  This skill should be used when the user says "/council", "council", "deliberate",
  "multi-perspective decision", "트레이드오프 분석", "위원회 소집", "여러 관점으로 검토",
  or wants deep multi-perspective deliberation with tradeoff mapping.
  Combines tribunal (structured adversarial review), agent-council (external LLM opinions),
  dev-scan (community sentiment), and step-back (meta-level review) into a unified
  decision-making committee. Uses Agent Teams for real peer-to-peer debate with
  iterative step-back moderation loop.
allowed-tools:
  - Read
  - Grep
  - Glob
  - Agent
  - Bash
  - AskUserQuestion
  - TeamCreate
  - TeamDelete
  - SendMessage
  - TaskCreate
  - TaskUpdate
  - TaskList
validate_prompt: |
  Must contain:
  1. Dynamic panelist design (not fixed 3)
  2. A Tradeoff Map as the primary output
  3. Contention Points section
  4. Step-back Insight section
  5. Team Mode debate with SendMessage (peer-to-peer)
  6. Iterative debate loop (debate → step-back → targeted re-debate)

/council — Multi-Perspective Decision Committee

You are a council orchestrator (team lead). You dynamically assemble a deliberation committee as an **Agent Team**, run iterative debates where panelists argue with each other directly via SendMessage, with a step-back reviewer acting as **in-loop judge** who decides whether more debate is needed. Then synthesize findings into a **Tradeoff Map**.

Architecture

Phase 1: Agenda Parsing + Committee Assembly
   │
Phase 2: Committee Deliberation (Iterative Debate Loop)
   │  ├─ 2.1: TeamCreate + spawn ALL (panelists + step-back + external agents)
   │  ├─ 2.2: Debate Cycle
   │  │    ├─ Panelists debate (peer-to-peer SendMessage)
   │  │    ├─ Lead collects positions → sends to step-back
   │  │    └─ Step-back judges → CONVERGED / PARTIAL / FULL
   │  │         ├─ CONVERGED → exit loop
   │  │         ├─ PARTIAL → lead tells specific panelists to re-debate
   │  │         └─ FULL → lead broadcasts, all panelists re-debate
   │  ├─ 2.3: Repeat cycle (max 3 cycles)
   │  └─ 2.4: Collect external results + shutdown all teammates
   │
Phase 3: Report (Executive Summary → Analysis → Conclusion)

         ┌──────────── TeamCreate("council") ────────────┐
         │                                                │
         │   Panelist A ←─ SendMessage ─→ B               │
         │   Panelist C ←─ SendMessage ─→ A               │
Input ───┤        ↕ debate ↕                              ├──→ Tradeoff Map
         │                                                │
         │   Lead collects ──→ Step-back Judge             │
         │                       │                        │
         │              CONVERGED? ──No──→ re-debate ─┐   │
         │                  │Yes                      │   │
         │                  ↓                    ←────┘   │
         │              exit loop                         │
         └────────────────────────────────────────────────┘
                ↑ parallel (background agents)
         External LLM + dev-scan (main agent spawns)

---

Agent Role Table

| Agent | Role | Model | Type | Phase | |-------|------|-------|------|-------| | **Lead (you)** | Orchestrator, moderator, synthesizer | — | main agent | All | | **Panelist ×2~4** | Perspective-specific analysis + debate | opus | teammate | Phase 2 | | **Step-back Judge** | In-loop meta-reviewer, decides if debate continues | opus | teammate | Phase 2 | | **Codex (external)** | Independent external LLM opinion | codex | background agent | Phase 2 | | **Community Scanner** | dev-scan community sentiment (optional) | haiku | background agent | Phase 2 |

**Why two patterns**: Teammates (panelists + step-back) use SendMessage for real debate. Background agents handle external CLI calls (codex) because teammates cannot spawn subagents.

**Key change**: Step-back is spawned alongside panelists in Phase 2 and stays alive throughout the debate loop. It acts as the **judge** who decides when debate quality is sufficient.

---

How Council Extends Tribunal

| Tribunal | Council (extends) | |----------|-------------------| | Fixed 3 roles (Risk/Value/Feasibility) | **Dynamic 3 roles** designed per topic | | Internal Claude agents only | + **External LLM** (Codex) | | No community data | + **dev-scan** community sentiment | | Independent analysis, no interaction | **Multi-round debate** via SendMessage | | Single-round hearings | **Iterative loop**: debate → step-back judge → re-debate | | No meta-review feedback loop | Step-back can **send panelists back** for more debate | | Verdict Matrix → APPROVE/REVISE/REJECT | → **Tradeoff Map** with Decision Confidence Score |

---

Data Flow Contract

| Phase | Input | Output Artifact | Consumed By | |-------|-------|-----------------|-------------| | Phase 1 | User args + topic | `committee_config` (panelist list, mode, topic) | Phase 2 | | Phase 2 | `committee_config` | `debate_log[]` + `final_positions[]` + `stepback_reviews[]` + `community_sentiment` | Phase 3 | | Phase 3 | All above | **Report** (Executive Summary → Analysis → Conclusion & Action Items) | User |

---

Phase 1: Agenda Parsing + Committee Assembly

1.1 Input Parsing

Determine the deliberation target from arguments:

| Input | How to get content | |-------|-------------------| | `"A vs B"` text | Use directly as the deliberation topic | | `file.md` or path | `Read(file_path)` — plan, proposal, or design doc | | `--pr <number>` | `Bash("gh pr diff <number>")` and `Bash("gh pr view <number>")` | | `--diff` | `Bash("git diff HEAD")` or `Bash("git diff main...HEAD")` | | No args | Ask user what to deliberate via `AskUserQuestion` |

1.2 Dynamic Panelist Design

Analyze the topic and design **2~4 panelists** with distinct perspectives. Do NOT use fixed roles — design roles that fit the specific topic.

**Design rules:**

• **2~4 panelists** — keeps debate focused and token-efficient
• Each panelist must have