Clarify draft planning as specification-building, not summarization

commands/start-planning.md

@@ -39,7 +39,25 @@ Which discussion would you like to create a plan for?
 
 Ask: **Which discussion would you like to plan?**
 
-## Step 3: Choose Output Destination
+## Step 3: Choose Planning Path
+
+Ask: **Do you want to create a draft plan first, or proceed directly to formal planning?**
+
+**Path A: Draft Planning**
+- Use when: Source materials need enrichment or filtering
+- Creates `draft-plan.md` to build the specification collaboratively
+- After draft is signed off, proceed to formal planning
+
+**Path B: Formal Planning**
+- Use when: Source materials already contain complete specification
+- Go straight to creating phases and tasks
+
+If user chooses Path A, skip to Step 5 (invoke skill with draft planning).
+If user chooses Path B, continue to Step 4.
+
+## Step 4: Choose Output Destination
+
+*Skip this step if doing draft planning (Path A).*
 
 Ask: **Where should this plan live?**
 
@@ -60,7 +78,7 @@ Ask: **Where should this plan live?**
 
 **If Linear or Backlog.md selected**: Check if MCP is available. If not, inform the user and suggest alternatives.
 
-## Step 4: Gather Additional Context
+## Step 5: Gather Additional Context
 
 **For Linear destination**:
 - Which team should own this project?
@@ -69,30 +87,36 @@ Ask: **Where should this plan live?**
 - Any additional context or priorities to consider?
 - Any constraints since the discussion concluded?
 
-## Step 5: Invoke Planning Skill
+## Step 6: Invoke Planning Skill
 
 Pass to the technical-planning skill:
 - Discussion path: `docs/specs/discussions/{topic-name}/`
-- Output destination: (local-markdown | linear | backlog-md)
+- Planning path: (draft | formal)
+- Output destination: (local-markdown | linear | backlog-md) - only if formal
 - Additional context gathered
 
-Example handoff:
+**Example handoff for Path A (Draft)**:
+```
+Planning session for: {topic-name}
+Discussion: docs/specs/discussions/{topic-name}/discussion.md
+Path: Draft planning
+
+Begin planning using the technical-planning skill.
+Reference: draft-planning.md
+```
+
+**Example handoff for Path B (Formal)**:
 ```
 Planning session for: {topic-name}
 Discussion: docs/specs/discussions/{topic-name}/discussion.md
+Path: Formal planning
 Output destination: Linear
 Team: Engineering
 
 Begin planning using the technical-planning skill.
-Reference: output-linear.md for output format.
+Reference: formal-planning.md, then output-linear.md
 ```
 
-The skill will:
-1. Read the discussion document
-2. Create phases and tasks
-3. Output in the specified format
-4. Create `plan.md` with appropriate frontmatter format
-
 ## Notes
 
 - Ask questions clearly and wait for responses before proceeding

skills/technical-planning/SKILL.md

@@ -5,156 +5,48 @@ description: "Transform technical discussion documents into actionable implement
 
 # Technical Planning
 
-Act as **expert technical architect** translating discussion decisions into TDD-ready implementation plans. Break complex features into testable phases and atomic tasks that implementation can execute without ambiguity.
+Act as **expert technical architect**, **product owner**, and **plan documenter**. Collaborate with the user to translate discussion decisions into actionable implementation plans.
 
-Convert discussion docs into implementation plans. Output location depends on chosen destination.
+Your role spans product (WHAT we're building and WHY) and technical (HOW to structure the work).
 
-## Output Destinations
+## You Must Ask Before Proceeding
 
-Plans can be stored in different formats depending on user preference. You will be told which destination to use (typically via the `start-planning` command).
+**If you don't know which path to take, ask the user.**
 
-| Destination | Best For | Output |
-|-------------|----------|--------|
-| **Local Markdown** | Simple features, solo work | Single `plan.md` file |
-| **Linear** | Team collaboration, visual tracking | Linear project + local pointer |
-| **Backlog.md** | Local Kanban with MCP support | Task files in `backlog/` |
+There are two paths:
+- **Path A**: Draft planning first, then formal planning
+- **Path B**: Formal planning directly
 
-Reference the appropriate adapter for output format:
-- **[output-local-markdown.md](references/output-local-markdown.md)** - Single plan.md file
-- **[output-linear.md](references/output-linear.md)** - Linear project with labeled issues
-- **[output-backlog-md.md](references/output-backlog-md.md)** - Backlog.md Kanban format
+The user decides. If they haven't told you, ask:
+> "Should we create a draft plan first to work through the details, or proceed directly to formal planning?"
 
-**Default**: If no destination specified, use local markdown.
+## Path A: Draft Planning
 
-The planning *approach* is the same regardless of destination. Only the output format changes.
+User wants to build the specification collaboratively before creating the formal plan.
 
-## Four-Phase Workflow
+**Load**: [draft-planning.md](references/draft-planning.md)
 
-1. **Discussion** (previous): WHAT and WHY - decisions, architecture, edge cases
-2. **Planning** (YOU): HOW - phases, tasks, acceptance criteria
-3. **Implementation** (next): DOING - strict TDD execution of your plan
-4. **Review** (final): VALIDATING - check work against decisions and plan
+**Output**: `draft-plan.md` - standalone specification
 
-You're at step 2. Don't implement.
+**When complete**: User signs off, then proceed to Path B.
 
-## Draft Planning for Complex Features
+## Path B: Formal Planning
 
-For complex or deeply technical work, planning itself requires discussion. Figuring out phases and tasks IS a conversation that needs capturing.
+User wants to create the formal implementation plan (directly, or after draft).
 
-**Two-phase planning**:
-1. **Draft Planning**: Back-and-forth about structure, captured in `draft-plan.md`
-2. **Formal Planning**: Convert draft to structured `plan.md` (or Linear/Backlog.md)
+**Load**: [formal-planning.md](references/formal-planning.md)
 
-See **[planning-conversations.md](references/planning-conversations.md)** for the draft planning workflow.
-
-**When to use draft planning**:
-- Complex features with unclear phase boundaries
-- Deeply technical work requiring back-and-forth
-- Multiple valid ways to structure the work
-
-**Skip to formal planning when**:
-- Structure is obvious from discussion doc
-- Small feature with clear phases
-
-## Capture Planning Conversations Immediately
-
-> **After each user response, IMMEDIATELY update the planning document before asking your next question. Capture the user's exact words and reasoning, not summaries.**
-
-Context windows refresh without warning. Hours of planning discussion can vanish.
-
-**Capture frequency**:
-- Update after every natural break in discussion
-- Never let more than 2-3 exchanges pass without writing
-- When in doubt, write it down NOW
-
-**What to capture**:
-- What the user said AND why, not just conclusions
-- Trade-offs considered and rejected
-- Scope decisions with reasoning
-- The journey, not just the destination
-
-## Commit Frequently
-
-**Commit planning docs often** to `docs/specs/plans/{topic-name}/`:
-
-- After each significant exchange
-- At natural breaks in planning discussion
-- When phases/tasks become clearer
-- **Before any context refresh**
-- When creating new files
-
-**Why**: You lose memory on context refresh. Commits prevent losing hours of planning work. This is non-negotiable.
-
-## You Create Plans, NOT Code
-
-**Your job**: Write plan document with phases, tasks, and acceptance criteria
-**NOT your job**: Implement it, modify files, write production code
-
-## Phase > Task Hierarchy
-
-Plans use a two-level structure:
-
-```
-Phase (higher level)
-├── Goal: What this phase accomplishes
-├── Acceptance Criteria: How we know the phase is complete
-└── Tasks (granular work units)
-    ├── Task 1: Description + micro acceptance + edge cases
-    ├── Task 2: Description + micro acceptance
-    └── Task 3: Description + micro acceptance
-```
-
-**Phase**: Independently testable unit. Has acceptance criteria.
-**Task**: Single TDD cycle. One task = one test = one commit.
-
-## Plan Contents
-
-Use **[template.md](references/template.md)**:
-- Phases with acceptance criteria
-- Tasks with micro acceptance criteria (specific test that proves completion)
-- Code examples for complex patterns
-- Edge case handling from discussion
-- Testing strategy
-- Rollback plan
+**Then load output adapter** (ask user which format):
+- [output-local-markdown.md](references/output-local-markdown.md) - Single `plan.md` file (default)
+- [output-linear.md](references/output-linear.md) - Linear project
+- [output-backlog-md.md](references/output-backlog-md.md) - Backlog.md tasks
 
 ## Critical Rules
 
-**Do**:
-- Create phases with clear acceptance criteria
-- Break phases into TDD-sized tasks
-- Reference discussion rationale
-- Make each task independently testable
-
-**Don't**:
-- Write production code
-- Modify project files
-- Execute the plan
-- Re-debate decisions
-
-## How Implementation Uses Your Plan
-
-Implementation will:
-1. Read your plan
-2. For each phase, announce start and review acceptance criteria
-3. For each task, derive test from micro acceptance, write failing test, implement, commit
-4. Verify phase acceptance criteria before proceeding
-5. Ask user before starting next phase
-
-**Your plan quality determines implementation success.**
-
-## Reference Files
-
-**Planning approach**:
-- **[planning-conversations.md](references/planning-conversations.md)** - Draft planning for complex features
-- **[planning-approach.md](references/planning-approach.md)** - Workflow, step-by-step
-- **[guidelines.md](references/guidelines.md)** - Best practices, task sizing
-- **[template.md](references/template.md)** - Plan document template (for local markdown)
+**Capture immediately**: After each user response, update the planning document BEFORE your next question. Never let more than 2-3 exchanges pass without writing.
 
-**Output adapters** (use based on chosen destination):
-- **[output-local-markdown.md](references/output-local-markdown.md)** - Single plan.md file
-- **[output-linear.md](references/output-linear.md)** - Linear project integration
-- **[output-backlog-md.md](references/output-backlog-md.md)** - Backlog.md Kanban format
+**Commit frequently**: Commit at natural breaks, after significant exchanges, and before any context refresh. Context refresh = lost work.
 
-## Remember
+**Never invent reasoning**: If it's not in the document, ask again.
 
-You're the architect, not the builder. Create clear phases with acceptance criteria, break into TDD-sized tasks, then hand off to implementation.
+**Create plans, not code**: Your job is phases, tasks, and acceptance criteria - not implementation.