draft-plan

name	draft-plan
description	Turn a spec into an ordered, phased build plan and create the work-item nibs for it. Use when you have a spec (PRD) and need to break it into vertical-slice phases (tracer bullets) ready to implement.

Draft a Plan

Break a PRD into a phased implementation plan using vertical slices (tracer bullets). Output work items to a tracking system or fall back to a Markdown file.

Process

1. Confirm the PRD is in context

The PRD should already be in the conversation. If it isn't, ask the user to paste it or point you to the file.

2. Explore the codebase

If you have not already explored the codebase, do so to understand:

• Current architecture and module boundaries
• Tech stack and project language
• Existing test patterns and infrastructure
• Deployment shape (what layers a vertical slice must cut through)

3. Check for deviation rules

Check the project's CLAUDE.md for a "When Executing Plans" section (or similar deviation rules). If none exists, offer to add one. This defines what the AI can decide autonomously vs. what requires human input during plan execution.

## When Executing Plans

When working from a plan or work item:

• Auto-fix without asking: bug fixes, type errors, missing imports, broken references, missing null checks, obvious error handling gaps
• Auto-add without asking: necessary validation, missing error handling on external calls, required interface implementations
• Ask before doing: new dependencies/packages, schema or data model changes, architectural decisions not covered in the plan, changes to public APIs or contracts, anything that affects other projects or services
• Never without explicit approval: delete or restructure files not mentioned in the plan, change build/CI configuration, modify security boundaries

Present the template to the user and let them adjust the boundaries before adding it. If the user declines, proceed without it.

This step can run in parallel with steps 2 and 4.

4. Determine the output target

@../../conventions/work-items.md

Detect the available system and confirm with the user. This can run in parallel with steps 2 and 3.

5. Identify durable architectural decisions

Before slicing, identify high-level decisions that are unlikely to change throughout implementation. Examples (adapt to the project type):

• Route structures / URL patterns (web apps)
• Database schema shape
• Key data models / domain types
• Authentication / authorization approach
• Third-party service boundaries
• CLI command structure (CLI tools)
• Public API surface (libraries)

Express these using the project's language idioms (e.g., structs for Go, records/classes for C#, structs/enums for Rust).

These go in the root work item body (or plan header for markdown) so every phase can reference them.

6. Draft vertical slices

Break the PRD into tracer bullet phases. Each phase is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.

- Each slice delivers a narrow but COMPLETE path through every layer identified in the codebase exploration - A completed slice is demoable or verifiable on its own - Prefer many thin slices over few thick ones - Do NOT include specific file names, function names, or implementation details that are likely to change as later phases are built - DO include durable decisions: route paths, schema shapes, data model names - DO include scope boundaries per phase (see below)

Scope boundaries per phase: Each phase should include a brief "Touches" and "Off limits" section. This prevents scope creep during implementation — Claude won't "helpfully" refactor adjacent code or add features that belong to a different phase.

• Touches: Areas of the codebase this phase modifies (modules, layers, subsystems — not specific file names)
• Off limits: Areas that are explicitly out of scope for this phase, even if they seem related

7. Quiz the user

Present the proposed breakdown as a numbered list. For each phase show:

• Title: short descriptive name
• User stories covered: which user stories from the PRD this addresses

Ask the user:

• Does the granularity feel right? (too coarse / too fine)
• Should any phases be merged or split further?

Iterate until the user approves the breakdown.

8. Create the plan

Create work items using the target system from step 4 and the conventions in work-items.md.

Each phase work item carries a ## Acceptance section in its body, in the format below.

@../../conventions/acceptance-criteria.md

Root work item:

• Title: Plan: <Feature Name>
• Body: Source PRD reference + architectural decisions from step 5 + checklist of all phases

One child work item per phase:

• Title: Phase N: <Title>
• Body: "What to build" description (end-to-end behavior, not layer-by-layer) + a ## Acceptance section (runnable [run] checks where possible, prose tagged [manual] otherwise) + user stories covered + scope boundaries (touches / off limits)

For markdown output, use the template below instead.

# Plan:

Source PRD:

Architectural decisions

Durable decisions that apply across all phases:

• Routes: ...
• Schema: ...
• Key models: ...
• (add/remove sections as appropriate for the project type)

---

Phase 1:

User stories:

What to build

A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.

Acceptance

Runnable checks where possible; prose tagged [manual] otherwise (see acceptance-criteria.md):

• [run] <command> — expect:
• [run] <command> — expect:
• [manual]

Scope boundaries

Touches: <modules, layers, or subsystems this phase modifies> Off limits: <areas explicitly out of scope, even if related>

---

Phase 2:

User stories:

What to build

...

Acceptance

• [run] <command> — expect:
• [manual]

Scope boundaries

Touches: ... Off limits: ...