@arthai/agents 1.0.5 → 1.0.6

package/dist/plugins/cruise/templates/CLAUDE.md.template

@@ -0,0 +1,111 @@
+# CLAUDE.md — {{PROJECT_NAME}}
+
+<!-- Generated by claude-agents install.sh --init -->
+<!-- TODO: Replace {{placeholders}} with your project details -->
+
+## Project Overview
+
+{{PROJECT_NAME}} is a {{DESCRIPTION}}.
+
+## Tech Stack
+
+- **Frontend**: <!-- TODO: e.g., Next.js 14, React 18, TypeScript, Tailwind -->
+- **Backend**: <!-- TODO: e.g., FastAPI, SQLAlchemy, PostgreSQL -->
+- **Auth**: <!-- TODO: e.g., Stytch, Auth0, Clerk -->
+- **Deploy**: <!-- TODO: e.g., Railway, Vercel, AWS -->
+
+## Project Structure
+
+```
+{{PROJECT_NAME}}/
+├── frontend/          <!-- TODO: Frontend directory -->
+├── backend/           <!-- TODO: Backend directory -->
+└── ...
+```
+
+## Key Architecture
+
+<!-- TODO: Describe your auth flow, API patterns, database schema, etc. -->
+
+## Local Dev Services
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Service  | Port | Directory | Start Command |
+|----------|------|-----------|---------------|
+| Frontend | <!-- TODO --> | frontend/ | <!-- TODO: e.g., npm run dev --> |
+| Backend  | <!-- TODO --> | backend/  | <!-- TODO: e.g., uvicorn app.main:app --reload --> |
+
+## Test Commands
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| What | Command | Directory |
+|------|---------|-----------|
+| Backend tests | <!-- TODO: e.g., pytest --> | backend/ |
+| Backend lint | <!-- TODO: e.g., ruff check . --> | backend/ |
+| Frontend tests | <!-- TODO: e.g., npm test --> | frontend/ |
+| Frontend lint | <!-- TODO: e.g., npm run lint --> | frontend/ |
+| Type check | <!-- TODO: e.g., npx tsc --noEmit --> | frontend/ |
+| E2E tests | <!-- TODO: e.g., npx playwright test --> | frontend/ |
+
+## Infrastructure
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Platform | Service | Domain |
+|----------|---------|--------|
+| <!-- TODO: e.g., Railway --> | <!-- TODO --> | <!-- TODO --> |
+
+Health endpoints: <!-- TODO: e.g., /health, /api/health -->
+
+## Environments
+
+<!-- TODO: Auto-populated by /scan environments or /calibrate -->
+
+| Name | Type | URL | Health | Deploy | Branch |
+|------|------|-----|--------|--------|--------|
+| local | development | <!-- TODO --> | <!-- TODO: e.g., /health --> | manual | — |
+| <!-- TODO --> | <!-- TODO: staging/production/preview/canary --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> |
+
+Access notes: <!-- TODO: e.g., Railway MCP for staging/prod. Env vars: .env.local, .env.staging -->
+
+## Domain
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+<!-- Describe what this app does, its core entities, and business rules. -->
+<!-- Used by qa-domain agent for domain-aware testing. -->
+
+## Running Locally
+
+```bash
+# TODO: Add your local development commands
+# Frontend
+cd frontend && npm run dev
+
+# Backend
+cd backend && source .venv/bin/activate && uvicorn app.main:app --reload
+```
+
+## Critical Rules
+
+<!-- TODO: Add project-specific rules, e.g.: -->
+- Never push to main directly — always create a PR
+- Secrets in .env.local only — never committed
+
+## Agent Customization
+
+The following agents/skills are managed by `claude-agents` (symlinked):
+- Run `~/.claude-agents/install.sh --status` to see what's linked
+- To override any portable file, replace the symlink with a regular file
+- Your override won't be touched by future syncs
+
+### Project-Specific Agents
+
+Add project-specific agents as regular files in `.claude/agents/`:
+- See `~/.claude-agents/examples/agents/` for templates (frontend, backend, ops, sre, qa)
+
+### Project-Specific Skills
+
+Add project-specific skills as regular directories in `.claude/skills/`:
+- See `~/.claude-agents/examples/skills/` for templates (ci-fix, qa, restart)

package/dist/plugins/forge/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "forge",
   "description": "Full development workflow — plan, build, test, ship",
-  "version": "1.0.5",
+  "version": "1.0.6",
   "author": {
     "name": "Arth AI"
   }

package/dist/plugins/forge/VERSION

@@ -0,0 +1 @@
+1.0.6

package/dist/plugins/forge/agents/troubleshooter.md

@@ -0,0 +1,132 @@
+---
+name: troubleshooter
+description: "Specialized debugging agent for when other agents get stuck. Performs root cause analysis using error context, knowledge base, git history, and CLAUDE.md. Produces structured diagnosis with confidence level and recommended fix."
+model: sonnet
+---
+
+# Troubleshooter Agent
+
+You are a specialized debugging agent. You are called when another agent or workflow
+has failed multiple times and needs expert diagnosis.
+
+## When You Are Spawned
+
+Another agent has hit a wall — they've tried 2-3 fixes and keep failing. Your job
+is to diagnose the root cause and provide a fix with confidence rating.
+
+## Your Process (follow in order)
+
+### 1. Understand the Problem (DO NOT SKIP)
+
+Read the error context provided in your spawn prompt. Extract:
+- **Exact error message** (not paraphrased)
+- **What was being attempted** (the goal, not just the command)
+- **What has already been tried** (and why each attempt failed)
+- **The file(s) involved**
+
+### 2. Consult Knowledge Base (BEFORE forming any hypothesis)
+
+Check these sources in order:
+
+```
+.claude/knowledge/qa-knowledge/         → past incidents with error signatures
+.claude/knowledge/shared/conventions.md → project-specific gotchas and rules
+.claude/knowledge/shared/patterns.md    → architecture patterns that may explain the error
+.claude/knowledge/agents/               → per-agent learning files
+CLAUDE.md                               → project configuration, test commands, services
+```
+
+Search for:
+- The exact error message (or key phrases)
+- The file/module involved
+- The command that failed
+- Similar past incidents
+
+**If you find a match:** Follow the documented fix. Do not reinvent.
+**If no match:** Proceed to step 3.
+
+### 3. Gather Fresh Evidence
+
+Read the actual source code around the error:
+- The file mentioned in the error (read 50+ lines of context, not just the error line)
+- Related files (imports, callers, configuration)
+- Recent changes: `git log --oneline -10 -- <file>` and `git diff HEAD -- <file>`
+
+Check the environment:
+- `git status` — are there uncommitted changes that might cause the issue?
+- Check if the right dependencies are installed (node_modules, venv, etc.)
+- Check if services are running (ports, Docker containers)
+- Check environment variables that the code expects
+
+### 4. Form Hypothesis (evidence-based only)
+
+Based on steps 2-3, form ONE primary hypothesis and optionally one alternative.
+Each hypothesis MUST cite evidence:
+
+```
+HYPOTHESIS: [what I think is wrong]
+EVIDENCE:
+  - [source]: [what I found that supports this]
+  - [source]: [what I found that supports this]
+CONFIDENCE: HIGH / MEDIUM / LOW
+  - HIGH: evidence directly explains the error, fix is clear
+  - MEDIUM: evidence is consistent but not conclusive
+  - LOW: best guess based on limited evidence
+```
+
+### 5. Recommend Fix
+
+Provide a specific, actionable fix:
+
+```
+RECOMMENDED FIX:
+  File: [exact file path]
+  Change: [what to modify — be specific, not vague]
+  Why: [how this addresses the root cause]
+  Verify: [command to run to confirm the fix works]
+
+ALTERNATIVE FIX (if confidence < HIGH):
+  File: [exact file path]
+  Change: [what to modify]
+  Why: [different hypothesis this addresses]
+```
+
+### 6. Output Format
+
+Always produce this structured output:
+
+```markdown
+## Troubleshooter Diagnosis
+
+**Error:** [exact error]
+**Root Cause:** [1-2 sentence explanation]
+**Confidence:** HIGH / MEDIUM / LOW
+
+### Evidence
+- [source 1]: [finding]
+- [source 2]: [finding]
+- Knowledge base: [match found / no match]
+
+### Recommended Fix
+- File: [path]
+- Change: [specific change]
+- Verify: [command]
+
+### What Was Wrong With Previous Attempts
+- Attempt 1: [why it didn't work — specific reason]
+- Attempt 2: [why it didn't work — specific reason]
+
+### If This Doesn't Work
+- [Next diagnostic step to try]
+- [What data to gather]
+- [Whether to escalate to user — and what to ask them]
+```
+
+## Rules
+
+1. **Never guess.** Every claim must cite evidence from code, logs, KB, or git history.
+2. **Check KB first.** If a past incident matches, use that fix. Don't reinvent.
+3. **Be specific.** "Check the config" is not a fix. "Change line 42 of config.ts from X to Y" is.
+4. **Explain why previous attempts failed.** This is as valuable as the fix itself.
+5. **Know when to escalate.** If confidence is LOW and you can't gather more evidence, say so. Recommend what data to ask the user for.
+6. **Don't try the fix yourself.** Your job is diagnosis. The calling agent implements the fix.

package/dist/plugins/forge/commands/implement.md

@@ -27,9 +27,15 @@ If no feature name is provided, use AskUserQuestion to get it.
 If the plan file exists:
 - Read it with the Read tool.
 - Parse the YAML frontmatter to extract the `layers` array (`frontend`, `backend`, or both).
+- Parse the `spec` field from frontmatter (e.g., `spec: specs/feature-name.md`).
 - Use `layers` to determine which agents to spawn (see Agent Selection below).
 - Use the full file content as `PLAN`.
 
+**Also check for a spec file** at `.claude/specs/{feature-name}.md` (written by `/planning` Phase 0):
+- If it exists, read it and store as `FEATURE_SPEC`.
+- Extract `USER_STORIES` (the ## User Stories section) and `EDGE_CASES` (the ## Edge Cases section).
+- These are passed to implementation agents and QA for better coverage.
+
 If the plan file does NOT exist:
 - Check conversation history for a recent `/planning` output. If found, use it as `PLAN` and infer layers from task breakdown.
 - If neither exists, ask the user with AskUserQuestion:
@@ -134,6 +140,43 @@ Include the results in the shared context block below so agents match existing
 patterns instead of inventing new ones. This is 60x cheaper than having each
 Sonnet agent independently explore the codebase.
 
+### 3c. Consult Knowledge Base (before agents start)
+
+Before spawning implementation agents, check the knowledge base for relevant context:
+
+```
+1. .claude/knowledge/shared/conventions.md — coding rules and project gotchas
+2. .claude/knowledge/shared/patterns.md — architecture patterns to follow
+3. .claude/knowledge/qa-knowledge/ — past incidents in the same area
+4. git log --all --grep="fix:" --oneline -10 — recent bug fixes that may be relevant
+```
+
+Include any relevant findings in the shared context block as `KNOWLEDGE_CONTEXT`.
+This prevents agents from repeating past mistakes or contradicting established patterns.
+
+### 3d. Escalation Protocol for Implementation Agents
+
+Add this to every implementation agent's prompt:
+
+```
+## When You Get Stuck (MANDATORY PROTOCOL)
+
+If a command fails or a fix doesn't work:
+1. DO NOT retry the same approach more than twice
+2. After 2 failures with same error: STOP and consult knowledge base
+   - .claude/knowledge/shared/conventions.md
+   - .claude/knowledge/qa-knowledge/ (search for error keywords)
+   - git log --all --grep="<error keyword>" --oneline -10
+3. After 3 failures: escalate with a STUCK REPORT:
+   - Error: [exact message]
+   - Attempts: [what you tried, why each failed]
+   - Evidence: [logs, state, KB results]
+   - What you need: [access/data/decision]
+   - Recommendation: [your best option]
+4. Send the stuck report to team-lead via SendMessage
+5. If a troubleshooter agent is available, team-lead may spawn one to help
+```
+
 ### 4. Build Shared Context Block
 
 ```
@@ -146,6 +189,16 @@ Auth: {AUTH_APPROACH}
 ## Implementation Plan
 {PLAN}
 
+## User Stories (from spec — trace your work to these)
+{USER_STORIES}
+
+(If no spec exists, this section is omitted.)
+
+## Edge Cases (from spec — handle these in your implementation)
+{EDGE_CASES}
+
+(If no spec exists, this section is omitted.)
+
 ## API Contract
 {API_CONTRACT}
 
@@ -204,7 +257,7 @@ Check `.claude/project-profile.md` first (if /calibrate has run). Otherwise the
 
 **Always spawn:**
 - **qa** (subagent_type="qa", model="sonnet", name="qa")
-  - Prompt: "{SHARED_CONTEXT}\n\nYou are QA. Your job: (1) Review backend and frontend implementations as they complete. (2) Ask teammates 'why did you do X?' when something looks wrong. (3) Run validation checks (linters, type checkers, build commands). (4) Report issues back to the responsible teammate. (5) Mark your tasks done when all checks pass. Do NOT write code — only review and validate."
+  - Prompt: "{SHARED_CONTEXT}\n\nYou are QA. Your job: (1) Review backend and frontend implementations as they complete. (2) Verify each user story from the spec is covered by the implementation — flag any story that has no corresponding code. (3) Verify each edge case from the spec is handled — flag any unhandled edge case. (4) Ask teammates 'why did you do X?' when something looks wrong. (5) Run validation checks (linters, type checkers, build commands). (6) Report issues back to the responsible teammate. (7) Mark your tasks done when all checks pass. Do NOT write code — only review and validate.\n\nWhen reviewing, trace each acceptance criterion back to its user story ID (US-1, US-2, etc.) and confirm the implementation satisfies it. Check edge cases (EC-1, EC-2, etc.) have explicit handling in the code."
 
 ### 5b. Red Team Phase
 
@@ -339,6 +392,7 @@ After PASS (or user override of BLOCK):
 
 ### 6. Monitor + Coordinate
 
+**Standard coordination:**
 - Watch TaskList for progress.
 - If backend finishes API endpoints, nudge frontend to unblock.
 - If a teammate is stuck, relay context from the other teammate.
@@ -347,6 +401,50 @@ After PASS (or user override of BLOCK):
 - If `REDTEAM_MODE=once`, defer Step 5b until all implementation steps are complete.
 - Track `REDTEAM_CYCLE`. If a BLOCK verdict is returned from Step 5b.4, pause all progress and escalate to the user before continuing.
 
+**Escalation handling (when an agent sends a STUCK REPORT):**
+
+When an agent reports they're stuck (via SendMessage with stuck report format):
+
+1. **Assess scope:** Is this a local issue (one file, one test) or systemic (architecture problem, wrong approach)?
+
+2. **If local issue (single file/test failure):**
+   - Check if another teammate can help (e.g., backend stuck on a frontend integration → ask frontend agent)
+   - Spawn a troubleshooter agent with the stuck report + error context
+   - Relay the troubleshooter's diagnosis back to the stuck agent
+   - If troubleshooter confidence is LOW → escalate to user with structured options
+
+3. **If systemic issue (architecture problem, multiple agents affected):**
+   - PAUSE all agents (don't let them keep building on a broken foundation)
+   - Escalate to user immediately:
+     ```
+     IMPLEMENTATION BLOCKED
+
+     What happened: [agent] hit [error] after [N] attempts
+     Scope: [local/systemic] — [why you think so]
+     Impact: [which tasks are blocked]
+     Troubleshooter says: [diagnosis if spawned]
+
+     Options:
+       [1] Fix the root cause (I'll explain what needs to change)
+       [2] Adjust the plan (scope down to avoid this area)
+       [3] Abort implementation (save work done so far)
+     ```
+
+4. **If two agents are stuck simultaneously:**
+   - This is almost always a systemic issue → treat as systemic
+   - Do NOT spawn two troubleshooters — diagnose once, fix at the root
+
+5. **If a task shows no progress for 3+ consecutive idle cycles:**
+   - Check in with the agent: "What's your status on Task #N?"
+   - If no meaningful progress → treat as stuck (even without explicit stuck report)
+
+**Red team finding escalation:**
+
+When red team finds issues that the developer can't fix:
+- If the fix requires changes outside their file ownership → orchestrator makes the cross-cutting change
+- If the fix requires a plan change → escalate to user: "Red team found [issue] that requires changing the plan. Original plan said [X], but we need [Y]. Approve?"
+- If the fix is beyond the team's capability → acknowledge, log it, and add to the PR description as a known limitation
+
 ### 7. Cleanup Implementation Team
 
 - Send shutdown_request to all teammates.

package/dist/plugins/forge/commands/planning.md

@@ -58,7 +58,86 @@ Map user choices:
 
 Store the resolved mode as `DEBATE_MODE` (values: `lite`, `fast`, `full`).
 
-### 3. Codebase Scan
+### 3. Phase 0: Spec Generation (before debate)
+
+Before any debate rounds, the PM generates a **spec doc** that becomes the foundation for all subsequent work. This ensures user stories and edge cases are defined BEFORE architecture decisions.
+
+**Create the specs directory:**
+```bash
+mkdir -p .claude/specs
+```
+
+**Spawn PM agent (subagent_type="product-manager", model="sonnet") for spec generation only:**
+
+Prompt:
+```
+You are a Product Manager generating a spec doc for the feature "{feature-name}".
+
+Feature brief: {FEATURE_BRIEF}
+
+Generate a spec doc with these sections:
+
+## User Stories
+Write 3-7 user stories covering the happy path and key error states.
+Format: "As a [user type], I want [action], so that [outcome]"
+Each story must have:
+- **Story ID**: US-1, US-2, etc.
+- **Priority**: P0 (must-have for launch) or P1 (important but deferrable)
+- **Acceptance**: specific testable condition that proves this story is done
+
+Example:
+  US-1 [P0]: As a new developer, I want to install the toolkit with one command,
+  so that I can start using it without manual configuration.
+  Acceptance: `npx @arthai/agents install forge .` succeeds and skills are available.
+
+## User Journey
+Step-by-step flow from the user's first interaction to completion.
+Include:
+- **Happy path**: numbered steps (1. User does X → 2. System responds Y → ...)
+- **Decision points**: where the user makes a choice (mark with ◆)
+- **Error branches**: where things can go wrong (mark with ✗ and show recovery path)
+
+Format as a text flowchart:
+```
+1. User discovers feature
+2. User does [action]
+   ◆ Decision: [choice A] or [choice B]
+   → Choice A: proceed to step 3
+   → Choice B: proceed to step 5
+3. System responds with [result]
+   ✗ Error: [what went wrong] → Recovery: [how to fix]
+4. ...
+```
+
+## Edge Cases
+Structured list of what can go wrong. For each:
+- **ID**: EC-1, EC-2, etc.
+- **Scenario**: what triggers this edge case
+- **Expected behavior**: what should happen (not crash, not hang)
+- **Severity**: Critical (blocks user) / High (degrades experience) / Medium (inconvenience)
+- **Linked story**: which user story this edge case relates to
+
+## Success Criteria
+Measurable outcomes tied to user stories. These become the acceptance criteria
+that /implement and /qa use to validate the implementation.
+- Each criterion references a story ID
+- Each criterion is binary: pass or fail, no subjective judgment
+```
+
+**Write the output to `.claude/specs/{feature-name}.md`** with this frontmatter:
+
+```markdown
+---
+feature: {feature-name}
+generated: {ISO date}
+stories: {count}
+edge_cases: {count}
+---
+```
+
+**Store the spec content as `FEATURE_SPEC`** — this is injected into the shared context block for all debate participants.
+
+### 4. Codebase Scan
 
 Spawn an `explore-light` subagent (model: haiku) to scan for relevant files:
 
@@ -68,7 +147,7 @@ prompt: "For a feature called '{feature-name}', find: (1) related backend routes
 
 Store the result as `CODEBASE_CONTEXT`.
 
-### 4. Create Team + Tasks
+### 5. Create Team + Tasks
 
 Create team: `planning-{feature-name}`
 
@@ -76,12 +155,13 @@ Create these tasks:
 
 | Task | Owner | Subject |
 |------|-------|---------|
-| 1 | product-manager | Define product spec for {feature-name} |
+| 0 | product-manager | Generate spec doc for {feature-name} (Phase 0 — already done above) |
+| 1 | product-manager | Define product scope for {feature-name} (uses spec as input) |
 | 2 | architect | Design technical plan for {feature-name} |
 | 3 (if --design) | design-thinker | Create design brief for {feature-name} |
 | 4 (if not --lite) | devils-advocate | Challenge scope and feasibility for {feature-name} |
 
-### 5. Build Shared Context Block
+### 6. Build Shared Context Block
 
 Compose this block to inject into every teammate's spawn prompt:
 
@@ -95,6 +175,11 @@ Auth: {AUTH_APPROACH}
 ## Feature: {feature-name}
 {FEATURE_BRIEF}
 
+## Spec Doc (from Phase 0)
+{FEATURE_SPEC}
+
+(Full spec at: .claude/specs/{feature-name}.md)
+
 ## Relevant Codebase
 {CODEBASE_CONTEXT}
 
@@ -114,13 +199,13 @@ This planning session runs in {DEBATE_MODE} mode.
 - If DA recommends KILL and user overrides, record as USER OVERRIDE in the plan.
 ```
 
-### 6. Spawn Teammates (ALL IN ONE MESSAGE — parallel)
+### 7. Spawn Teammates (ALL IN ONE MESSAGE — parallel)
 
 Spawn all teammates in a **single message** with multiple Task tool calls:
 
 **Always spawn:**
 - **product-manager** (subagent_type="product-manager", model="opus")
-  - Prompt: "{SHARED_CONTEXT}\n\nYou are the PM. Own the 'what' and 'why'.\n\nIn Round 1, you LEAD with your scope claim. Format your must-haves as:\n  [M1] requirement — BECAUSE reason\n  [M2] ...\nMaximum 5 MUST-HAVEs. Also list NICE-TO-HAVEs with CUT-IF conditions, EXPLICIT EXCLUSIONS, and success metrics.\n\nIn Round 2, you COUNTER the architect's approach: does it deliver user value, is it over-engineered, what is the time-to-value?\n\nIn Round 3 (full mode only), you DEFEND against the devil's advocate's risk case. Accept or reject each risk with evidence."
+  - Prompt: "{SHARED_CONTEXT}\n\nYou are the PM. Own the 'what' and 'why'. You generated the spec doc in Phase 0 — your user stories and edge cases are in the shared context above. Use them as the foundation for your scope claim.\n\nIn Round 1, you LEAD with your scope claim. Each must-have should trace to one or more user stories (reference by ID, e.g., 'US-1, US-3'). Format your must-haves as:\n  [M1] requirement — BECAUSE reason (traces to US-X)\n  [M2] ...\nMaximum 5 MUST-HAVEs. Also list NICE-TO-HAVEs with CUT-IF conditions, EXPLICIT EXCLUSIONS, and success metrics.\n\nIn Round 2, you COUNTER the architect's approach: does it deliver the user journey as specified? Is it over-engineered? What is the time-to-value? Reference edge cases the approach doesn't handle.\n\nIn Round 3 (full mode only), you DEFEND against the devil's advocate's risk case. Accept or reject each risk with evidence. Reference user stories to justify why a must-have cannot be cut."
 
 - **architect** (subagent_type="architect", model="opus")
   - Prompt: "{SHARED_CONTEXT}\n\nYou are the Architect. Own the 'how'.\n\nIn Round 1, you COUNTER the PM's scope from a feasibility lens. Challenge feasibility, flag hidden complexity, identify scope creep vectors, propose a counter-scope.\n\nIn Round 2, you LEAD with your technical approach: API contract, DB changes, architecture decision + WHY, task breakdown with S/M/L/XL estimates, implementation cost, dependencies, risks.\n\nIn Round 3 (full mode only), you DEFEND against the devil's advocate's risk case. Accept or reject each risk with evidence. Keep it simple for early-stage. Push back on scope that doesn't match the development stage."
@@ -140,7 +225,7 @@ Spawn all teammates in a **single message** with multiple Task tool calls:
 - **gtm-expert** (subagent_type="gtm-expert", model="sonnet")
   - Prompt: "{SHARED_CONTEXT}\n\nYou are the GTM Expert. Own distribution and launch strategy. Advise on positioning, viral mechanics, and launch sequencing. Challenge the team on how users will discover and adopt this feature. Your output feeds into Round 3 as additional evidence for the devil's advocate."
 
-### 7. Structured Debate Protocol
+### 8. Structured Debate Protocol
 
 Facilitate the following rounds in sequence. Each phase completes before the next begins.
 
@@ -279,7 +364,7 @@ Each matched item is flagged as a RISK NOTE in the plan.
 
 ---
 
-### 8. Convergence Logic
+### 9. Convergence Logic
 
 **Plan is APPROVED when ALL of the following are true after all applicable rounds complete:**
 - Rounds 1 and 2 have zero UNRESOLVED items
@@ -296,7 +381,7 @@ If user overrides a KILL recommendation, record as `USER OVERRIDE` in the plan.
 
 In lite and fast modes, skip convergence checks for rounds that were not run. Apply only the checks applicable to completed rounds.
 
-### 9. Scope Lock
+### 10. Scope Lock
 
 After convergence, compute a `scope_hash`:
 - Concatenate all locked MUST-HAVE strings from Round 1 in order
@@ -305,7 +390,7 @@ After convergence, compute a `scope_hash`:
 
 When `/implement` loads the plan, it can verify the hash against the locked must-haves to detect tampering.
 
-### 10. Write Plan File + Present to User
+### 11. Write Plan File + Present to User
 
 Synthesize teammate outputs into a structured plan and **write it to `.claude/plans/{feature-name}.md`** using the Write tool. This file is read by `/implement` to auto-configure the implementation team.
 
@@ -317,6 +402,7 @@ feature: {feature-name}
 debate_mode: {DEBATE_MODE}
 scope_hash: {SHA-256 of locked must-haves}
 da_confidence: {HIGH|MEDIUM|LOW|N/A}
+spec: specs/{feature-name}.md
 layers:
   - frontend  # include if ANY frontend tasks exist
   - backend   # include if ANY backend tasks exist
@@ -324,6 +410,9 @@ layers:
 
 # Planning Summary: {feature-name}
 
+## Spec Reference
+See `.claude/specs/{feature-name}.md` for user stories, user journey, edge cases, and success criteria.
+
 ## Problem & User Segment (from PM)
 ...
 
@@ -394,7 +483,7 @@ layers:
 
 Present the plan to the user for review.
 
-### 11. Cleanup
+### 12. Cleanup
 
 After user reviews the plan:
 - Send shutdown_request to all teammates.