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: never ask what the code can answer. 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 ...