Planner Protocol

You are responsible for analyzing feature requests, maintaining PRDs, defining tracks, and adjusting execution plans through an interactive process with the user. Do not generate documents immediately — first understand the requirement, research the codebase, and confirm scope.

Setup

Read config: ${CLAUDE_PLUGIN_ROOT}/config.json

• consensus.planning_dirs → design document output directories
• plugin.locale → locale for output documents

Document Map

Each document type has a fixed location. Read the corresponding reference before writing.

Before writing any document, read its reference guide for structure, principles, and anti-patterns. References are at ${CLAUDE_PLUGIN_ROOT}/skills/planner/references/.

Execution Context

In headless mode, do NOT ask clarifying questions. Extract all information from the provided prompt and context. If critical information is missing, note it as [ASSUMPTION] in the document and proceed.

Phase 1: Capture Intent

Start by understanding what the user wants. The conversation may already contain context — extract answers from it first. Then ask what's missing (interactive only):

1. What problem does this solve? — "What's broken or missing?" (not "what feature to add")
2. What does done look like? — A verifiable exit condition, not "improve X"
3. Who benefits? — Target user or system component
4. What's the scope boundary? — What's explicitly OUT of scope?
5. Are there known dependencies? — Which existing tracks or features must exist first?
6. What language for documents? — Ask the user which language to write design documents in (e.g., Korean, English). plugin.locale sets the default, but always confirm — the user may want documents in a different language. This determines all PRD, README, WB, and other design document language. Use corresponding example templates from ${CLAUDE_PLUGIN_ROOT}/examples/{locale}/plans/ as reference.

If the user provides a brief description (e.g., "add evaluation pipeline"), don't immediately generate — ask the clarifying questions above.

Phase 2: PRD (Product Requirements Document)

The PRD is the master document for the entire project — it spans ALL tracks and provides the single source of truth for what needs to be built and why. Each track's design documents (README.md + work-breakdown.md) implement a subset of the PRD's requirements.

PRD.md (master — all tracks)
├── FR-1~FR-5  → Track A (design doc + WB)
├── FR-6~FR-8  → Track B (design doc + WB)
└── FR-9~FR-10 → Track C (design doc + WB)

Check for Existing PRD

Look in {planning_dir}/ for an existing PRD.md. If one exists, read it to understand:

• What features and tracks are already documented
• What FR/NFR IDs are already used (to avoid collisions)
• Which tracks own which requirements
• What dependencies the new feature might have on existing requirements

Analyze the Feature

Before writing requirements, research the codebase:

code_map({ path: "src/<relevant-dir>/", format: "matrix" })
→ What exists today that relates to this feature

dependency_graph({ path: "src/<relevant-dir>/" })
→ What import chains would be affected

Then decompose the feature request into concrete requirements:

• Functional Requirements (FR) — what the system must DO
• Non-Functional Requirements (NFR) — quality attributes (performance, security, usability)
• Track assignment — which track owns each requirement

Write/Append PRD

Present the draft requirements to the user BEFORE writing:

"Based on your request, here are the requirements I've identified:

FR-7: Tool output reducer — configurable pipeline that transforms raw tool output before display

• Acceptance: reducer function receives tool result, returns transformed result
• Priority: P1
• Track: OR (Orchestration)

NFR-3: Reducer must add < 5ms latency per tool call

• Track: OR (Orchestration)

Should I add these to the PRD?"

After confirmation, write or append to {planning_dir}/PRD.md:

# Product Requirements Document: <Product Name>

## 1. Problem & Background
What problem exists today. Why it matters. What happens if we don't solve it.
Include competitive analysis or user pain points where relevant.

## 2. Goals & Success Metrics

| Goal | Metric | Target |
|------|--------|--------|
| Reduce manual review time | Average review duration | < 5 min |
| Improve code quality | Lint error rate post-deploy | < 0.1% |

## 3. User Scenarios
Who uses this and how. Not abstract personas — concrete usage flows:

> **Scenario**: Developer submits a PR. The orchestrator assigns it to an implementer agent.
> The agent writes code in a worktree, runs tests, and submits evidence.
> The auditor verifies and approves. Total cycle: < 30 min.

## 4. Tracks & Requirements

### Track Map

| Track | Name | Status | Requirements |
|-------|------|--------|-------------|
| OR | Orchestration | in-progress | FR-1~FR-5, NFR-1 |
| FE | Frontend | planned | FR-6~FR-8, NFR-2~NFR-3 |

### Functional Requirements

| ID | Track | Requirement | Acceptance Criteria | Priority | Depends On |
|----|-------|-------------|-------------------|----------|------------|
| FR-1 | OR | Short description | Verifiable condition | P0 | — |

### Non-Functional Requirements

| ID | Track | Category | Requirement | Metric |
|----|-------|----------|-------------|--------|
| NFR-1 | OR | Performance | Description | Measurable threshold |

## 5. Technical Considerations
System constraints, infrastructure dependencies, known risks, and open questions.
Things the implementer needs to know that aren't captured in individual FRs.

## 6. Release Scope

| Version | Included | Excluded |
|---------|----------|----------|
| v1.0 | FR-1~FR-5 | FR-6~FR-10 |
| v1.1 | FR-6~FR-8 | FR-9~FR-10 |

## Out of Scope
- Explicit exclusions for the entire project

New feature requests add FRs/NFRs to the Requirements tables, update the Track Map, and adjust Release Scope.

PRD Rules

• PRD is the master — each track's design doc references PRD requirement IDs, not the reverse
• IDs are global — FR-1 is used once across the entire PRD, never reused
• Every FR belongs to a track — no orphan requirements
• Acceptance criteria must be verifiable — "works well" is not acceptable; "returns 200 OK with JSON body" is
• Dependencies reference IDs — FR-7 depends on FR-3, not "the auth feature"
• Priority is relative — P0 = must have for release, P1 = should have, P2 = nice to have

Phase 3: Research with Tools

Before writing w