interview-plan

Plan Interview

Produce one ambiguity-free implementation plan by interviewing the user one question at a time. The crucial goal is a plan with no ambiguity across three lenses:

• Business requirements — what problem, measurable success, who, why not simpler.
• Backward compatibility — every consumer, stored record, in-flight message, and deployed client affected, enumerated from the actual code.
• Technical — behaviour, edge cases, data model, contracts, testing, rollout.

The model discovers and interrogates — it reads the codebase first, confronts the user with findings, and pushes back with alternatives. It does not prepare a plan from the user's words alone. A plan built only from what the user said is the failure mode this skill exists to prevent.

The single output is one plan markdown file written to disk — authored by the write-plan skill from the spec this interview assembles, then verified by this skill's Audit Pass. It must be complete enough that a fresh reader can implement it without a follow-up question.

The goal is not "minimum questions to start coding". It is "no ambiguity left that would bite us at code-review or in production".

Rules

1. One question per turn. Never bundle multiple questions, sub-questions, or "while we're at it" asides. If you catch yourself writing "and also" — delete it and save it for the next turn. (Batch-confirmations of clearly out-of-scope checklist items are not bundled questions; see "Using the Checklist Efficiently".)
2. Discover before asking. Run the Discovery Phase first. Any fact that the codebase, configs, docs, or git history can answer — read it, don't ask. Questions of intent ("should we retry on this error?", "is partial success acceptable?", "do we need an audit log?") must always be asked; the code tells you what is, not what should be. Every question you do ask should be grounded in something you read, not in the user's framing.
3. Walk the decision tree depth-first. Resolve a decision's dependencies before moving to the next sibling. Don't jump branches until the current one is settled.
4. Always recommend an answer. For every question, propose your recommended answer with a one-sentence reason. The user can accept, override, or refine — this prevents stall. When the user overrides a recommendation, record the decision as D<n>. <decision> (overrides recommendation: <user's reason>). Pushback with no reason → ask once for the reason before recording; never silently flip. Code-grounded findings remain facts regardless of the user's framing.
5. Tag the type of decision. Mark each question as [technical], [product], [compat], or [scope] so the user knows whether they're being asked an engineering tradeoff, a business call, a backward-compat call, or a boundary call.
6. Write the decision log to disk as you go. Append each agreed answer, explicit non-goal, and open risk to docs/specs/<TICKET-ID>/spec.md at the moment it is decided (create the file from the Spec File Template below on the first decision). Every behavioral decision carries a Check: line — a runnable command or named test that proves it (or manual QA: <step>). Cannot write one = decision too vague; sharpen it in the same turn before recording. Long interviews degrade chat recall; the file cannot forget. The end-of-interview spec assembly (Output Step 1) organizes this file — it does not reconstruct decisions from memory. Also track the consumer list from Discovery in the same file so the backward-compat lens can be closed item by item. On every append, check the new decision against the existing decisions and non-goals — if it contradicts one, surface both immediately and ask which wins; do not record two conflicting decisions.
7. Push back with code-grounded findings, not just questions. When you spot a simpler design, a non-obvious risk, a broken consumer, or a more idiomatic approach for this codebase — surface it on your own turn. Ground it in something you actually read. Use this format: