Idea to Plan

Convert an underspecified request into (1) a one-paragraph problem statement, (2) a scoped spec, and (3) a phased implementation plan — each shown to the user for sign-off before moving on. Never jump to code from a vague prompt.

When to use

• The request is a goal, not a specification ("build a dashboard", "add auth").
• Requirements, constraints, or success criteria are missing or implied.
• The user is exploring whether something is worth building.

Do not use this for well-specified tasks, bug fixes with a clear repro, or mechanical changes — those go straight to implementation.

Procedure

1. Restate the problem (before asking anything)

Write one paragraph: who has what problem, why now, and what "solved" looks like. Show it. If you can't write it, you don't understand the request — that gap is your first question.

2. Ask only decision-changing questions

Batch 3–6 questions that would change the design if answered differently. Skip anything with a safe default — state the default instead and move on. Good targets:

• Scope boundaries (what is explicitly out)
• Hard constraints (stack, deadline, data, compliance)
• Success criteria (how we'll know it works)
• The one assumption that, if wrong, wastes the most work

3. Write the spec

## Problem
## Goals / Non-goals
## Constraints
## Approach (1–3 sentences)
## Open questions

Keep it under one screen. Show it, get explicit "yes" on Goals/Non-goals before planning.

4. Write the phased plan

Break into phases that each deliver something verifiable:

Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>
Phase 2: ...

Each phase: concrete deliverable, the files/areas touched, and how it's verified. Flag dependencies and the riskiest phase. Front-load risk.

5. Hand off

Output the spec + plan as the final artifact. Recommend the first phase and stop — implementation is a separate step the user triggers.

Quality bar

• Problem statement fits in one paragraph and names a real user.
• Non-goals are explicit (a spec with no non-goals is not scoped).
• Every phase is independently verifiable.
• No question asked that has an obvious default.
• Zero code until the spec is signed off.

Anti-patterns

• Asking 15 questions when 4 decide the design.
• "Phase 1: set up the project" with no verifiable outcome.
• Restating the user's prompt back as if it were a spec.
• Designing the gold-plated version before the wedge is agreed.