plnplan

name	pln:plan
description	Read a design doc and produce a concrete, ordered implementation plan at specs/[feature]/implementation-plan.md.
argument-hint	["feature-name"]
allowed-tools	Read, Write, Edit, Glob, Grep, Bash(mkdir *)

Step 0: Validate argument

If no argument is provided, deduce from context or tell the user: /pln:plan [feature-name]

---

Step 1: Read the design doc

Resolve the design doc at specs/[feature]/design.md where [feature] is the argument.

If the file doesn't exist, tell the user and suggest they run /pln:design [feature] first.

Read the design doc thoroughly. Understand the feature, its architecture, data flow, and any open questions.

Step 2: Explore the codebase

Explore the codebase to understand:

• Existing architecture and patterns relevant to the design
• Files that will need to be modified or serve as reference
• Testing patterns and conventions already in use
• Any existing code that overlaps with or relates to the planned feature

Step 3: Write the implementation plan

Create specs/[feature]/implementation-plan.md with the following sections:

• Steps: Ordered implementation steps, each with file paths and a description of what to do. For large tasks, break steps into subtasks suitable for parallel subagents, each with a clear, agent-executable verification step (e.g., "run bun test src/foo.test.ts and confirm it passes", not "verify it works")
• Testing: How to verify each step and the feature overall. Include specific commands and expected outcomes.
• Code Review: The final step should always be running a code review agent to do a thorough review of all changes.
• Open Questions: Anything unclear from the design that affects implementation. Flag decisions that need user input.

Step 4: Iterate

Tell the user what you've planned and ask for feedback. As the user requests changes, update specs/[feature]/implementation-plan.md accordingly.

When the user is satisfied, suggest they run /clear and then /pln:build [feature] to start implementation.