plan

Implementation Plan (P Phase — Part 2)

The design answered "where are we going?" The outline answered "how do we get there?" The plan answers "what exactly do we write?" — specific file changes, code snippets, type definitions, and verification commands for each phase.

This is a tactical doc for the agent. The human has already aligned on direction (design) and structure (outline). The plan just fills in the implementation details. Spot-check it, don't deep-review it — save the deep review for the actual code.

If individual file paths were provided, read them all fully.

If no parameters provided, respond with:

"I'll create an implementation plan. Point me to the thoughts folder (e.g., thoughts/001-auth-endpoint/), or provide the outline and design documents."

Then wait for the user's input.

If either is unapproved or missing, stop and tell the user which step to complete first:

The [design/outline] is not yet approved. Please finalize it first:
  run /qrspiv:[design|outline] thoughts/<id>-<title>/

Do not proceed without an approved outline.

For each phase, write:

1. Overview — one paragraph restating the phase goal
2. Changes Required — for each file touched:
   • Full file path
   • Summary of what changes
   • Code snippets showing the specific additions or modifications (use the language's syntax)
   • Reference to patterns from research.md that this code follows
3. Success Criteria — split into:
   • Automated Verification: commands that can be run (make test, go test ./..., npm run typecheck, etc.)
   • Manual Verification: things a human should check (UI behavior, performance, edge cases)

Never plan all database changes first, then all services, then all API changes. That produces untestable intermediate states.

• Overview — 2-3 sentences on what we're implementing and why
• Current State — brief summary from research.md of what exists today
• Desired End State — from design.md, what the system looks like when done, and how to verify it
• What We're NOT Doing — out-of-scope items from the design's resolved decisions (prevents scope creep during implementation)

After the phases, include:

• Testing Strategy — unit tests, integration tests, and manual testing steps across the whole feature
• Files Touched — complete list grouped by phase (carried forward from outline)

[Feature/Task Name] Implementation Plan

Overview

[2-3 sentences: what and why]

Current State

[What exists today — key constraints from research]

Desired End State

[What the system looks like when done — verification criteria from design]

What We're NOT Doing

[Out-of-scope items — prevents scope creep]

Phase 1: [Name from outline]

Overview

[One paragraph: what this phase accomplishes]

Changes Required

1. [Component/File Group]

File: path/to/file.ext Changes: [Summary]

// Specific code to add or modify

Pattern reference: follows [pattern name] from path/to/existing.ext

2. [Next Component/File Group]

...

Success Criteria

Automated Verification:

• [Test command]: make test-xxx or go test ./...
• [Type check]: npm run typecheck
• [Lint]: make lint

Manual Verification:

• [What to check manually]

Checkpoint: After automated verification passes, pause for human confirmation before proceeding to Phase 2.

---

Phase 2: [Name from outline]

[Same structure...]

---

Testing Strategy

Unit Tests:

• [What to test, which files]

Integration Tests:

• [End-to-end scenarios]

Manual Testing:

1. [Specific steps]

Files Touched

Phase 1: file1 (new), file2 (modify) Phase 2: file3 (new), file4 (modify) ...

</template>