Idea to Spec

Idea to spec

Move a rough idea through fixed stages, each producing a document artifact the user can review. The discipline is the stage gates: do not write implementation detail before the product design is agreed, and do not let an eager draft skip the questions that would have changed it.

Pick a depth

• Lite: the idea is a sketch or early thought. Ask at most 3 to 5 clarifying questions, then produce a single tidy idea note artifact (title, summary, problem, key points, open questions). Stop there unless the user upgrades.
• Full: the idea is a serious product or feature the user may actually build. Run all stages below.

Default to Lite for vague or exploratory ideas; default to Full when the user asks for a spec, an implementation plan, UI direction, or something an agent or developer could build from.

Stage 1: Capture

Restate the idea in a short working note: title, one-line summary, problem statement, and initial bullets. Prefer a provisional title over stalling on naming.

Stage 2: Interview

Interview the user in chat, one question at a time, most important first. Do not dump a questionnaire. Cover, as relevant: target user and the problem being solved; core behavior and the desired experience; scope and explicit non-goals; main screens or surfaces and what must be visible at a glance; data, integrations, and platform targets; hosting and where data lives; authentication and sharing model; and what would make the result feel excellent rather than merely functional. Hold off on stack decisions unless the user raises a technical constraint. If the user says "enough", "draft it", or similar, stop asking and draft with stated assumptions.

Stage 3: Design doc

Produce the design doc as an artifact. Suggested sections: one-line summary; problem and purpose; target user; core concept; key features; desired behavior; layout and information architecture; UX notes; technical shape at a high level; data and integration needs; platform targets; non-goals; open questions; next steps.

Gate: do not proceed until the user has reviewed the design doc and either agreed or had their changes folded in. If open questions would change architecture, MVP scope, or the core interface, resolve them first.

Stage 4: UI brief (optional)

Only when the interface matters and the user wants it. Produce a separate artifact covering: product feel and design principles; primary screens with screen-by-screen notes; component inventory; key user flows; states to design (empty, loading, error, success, first run, permissions); visual direction; accessibility and responsiveness; and handoff notes for implementation. If this stage is skipped, carry explicit UI assumptions into the next stage instead of blocking.

Stage 5: Implementation plan

Only after the design doc is agreed. Produce an artifact with: major system pieces; data model and storage choice with reasoning; hosting and platform decisions; frontend structure honoring the UI brief if one exists; backend and service needs; security and secrets model; integration points; ordered milestones; risks and tradeoffs; concrete build tasks; a testing and verification plan; and acceptance criteria phrased as observable behavior.

For technical choices, recommend then confirm: infer sensible defaults from the product constraints, present them concisely, ask the user to accept or change, and record the outcome. If the user is unsure, proceed with defaults labeled as assumptions.

Stage 6: Readiness check

Before declaring the package build-ready, review it honestly: is the product goal clear, are requirements testable, are acceptance criteria concrete, could someone with no context build from these documents without asking obvious questions, and do the non-goals actually prevent scope creep? Give a verdict of ready, ready with listed fixes, or not ready, and say why.

Rules

• Each stage yields its own artifact; update the relevant artifact when the user confirms a decision rather than restating everything in chat.
• Where a quick comparison with existing products would sharpen the spec, do a bounded web search pass and record what to emulate or avoid. Keep it short; this is not a market report.
• The user can force progression at any time; when they do, note the risk in one line and carry unresolved items forward as open questions.
• Keep product thinking and engineering thinking in separate documents. A design doc full of stack choices, or an implementation plan relitigating the product, is a sign a gate was skipped.