create-implementation-plan

Create Implementation Plan

Planning only — no code changes, no execution. You produce one document: an implementation plan that is the contract for a later execution session.

This is the "how", not the "what". The "what" was settled in an earlier refinement step and lives in the requirements document you're given; do not redefine scope. But you must flag any gap, ambiguity, or inconsistency you find in the requirements — surface it, never paper over it.

Golden rule

Never guess — ask. With one limit: anything resolvable by reading the codebase, resolve by reading the codebase; only questions the code cannot settle go to the user.

Steps

Your task is to produce the implementation plan. The steps below build toward it; grilling the user — interviewing relentlessly to resolve anything the code can't settle — is woven through the design, not a separate phase that runs before planning starts.

1. Read the requirements document the user references (e.g. a *.REQUIREMENTS.md). If the path is ambiguous, ask.

2. Verify against the actual codebase. Open the files the requirements cite and confirm the prior-art references still hold; note anything that has shifted since the requirements were written. The requirements may also carry verified codebase facts — use any that are there to save re-discovery work, aware the code may have moved meanwhile (a pinned commit makes the check cheap: git diff <commit>..HEAD -- <cited paths>). If the requirements gate implementation on missing data or upstream work, verify that gate independently — stale gating claims are a common failure mode and easily inflate into a plan's first step when the data is in fact already addressable.

3. Work out the approach. This is the core of the task: design the "how" — what existing code to reuse, what to introduce, where each change goes, and the order of operations that avoids broken intermediate states (data model before its consumers, code before its tests). Track dependencies between steps. Working this out surfaces the decision tree: the forks where more than one reasonable approach exists. Typical forks to design through (and grill on when the code can't settle them): whether to refactor existing code to reuse it or build anew; which API or interface to call; which unit tests to add; code style, file names, and folder structure.