---
name: design-brainstorm-before-coding
description: "Turns a half-formed idea into an approved short design doc through one question at a time, so no code gets written against a wrong assumption. Use when a rough feature idea needs to become a short approved design before anyone writes code. Do not use for turning an already approved design into tasks, or fixing a bug in existing code. Related topics: coding, product."
---

# Design Brainstorm Before Coding

Turns a half-formed idea into an approved short design doc through one question at a time, so no code gets written against a wrong assumption.

## When to use

Use this skill when a rough feature idea needs to become a short approved design before anyone writes code. Do not use it for turning an already approved design into tasks, or fixing a bug in existing code.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Read the project context and note the facts the design depends on, so no question asks for something already known.
3. Ask one question at a time, multiple choice with a recommendation where possible, until purpose, scope, non-goals and failure cases are each answered.
4. Compare two plausible approaches with the cost of each and a recommendation whenever a real fork appears.
5. Draft the design doc section by section and get an explicit approval for each section before moving on.
6. Close with the approved summary and the single first task, and confirm that no code has been written.

## Inputs

- **The idea** (longer free text)
- **Project context** (longer free text)
- **Who it is for** (free text, e.g. "Users or callers of the result")
- **Hard constraints** (longer free text)
- **How decisive to be** (choose one: Ask about everything, Ask only about risky choices, Propose defaults and let me veto)

## Output

A design doc with goal, non-goals, approach, key interfaces, error handling and success check, each section approved in turn, ending with a one-line approval statement.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Design Brainstorm Before Coding

Interview me about this idea until we have a short design doc I approve. Write no code until I say the design is approved.

- The idea: {{The idea}}
- Project context: {{Project context}}
- Who it is for: {{Who it is for}}
- Hard constraints: {{Hard constraints}}
- How decisive to be: {{How decisive to be}}

Ask exactly one question per message and wait for the answer. Prefer multiple choice with a recommended option and a one-line reason, since a choice is faster to answer than an open prompt. Start with purpose and success criteria, then scope and non-goals, then data and interfaces, then failure cases. When two designs are plausible, lay out both with the cost of each and recommend one. Stop asking once the remaining questions would not change the design.

Then draft the design doc in sections of a few sentences each: goal, non-goals, approach, key interfaces, error handling, and how we will know it works. Present it section by section and ask for approval after each. End with a one-line statement of what is approved and the first thing to build.

## Pitfalls

- Asking several questions in one message, which gets partial answers and hides the one that mattered.
- Starting to sketch code during the interview, which anchors the design on the first idea.
- Interviewing past the point of value, when remaining answers would not change the design.