# Write a spec by interview

Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
I want to build: {{feature}}
{{#decided}}

Already decided:
{{decided}}
{{/decided}}

Interview me in detail before writing anything. Use the AskUserQuestion tool if it is available; otherwise ask in the chat.

- Ask about technical implementation, UI and UX, edge cases, concerns and tradeoffs.
- Skip obvious questions. Dig into the hard parts I may not have considered.
- Pace: {{pace}}. Build on my earlier answers.
- Do not reopen what is already decided unless it conflicts with something else I tell you.

Keep interviewing until we have covered everything, then write a complete spec to SPEC.md. Make the spec usable on its own: say which files and interfaces change, what is deliberately left out, and finish with one check a developer can run to confirm the whole feature works. Do not start implementing.
```

## Fields

- `{{feature}}` (required): The feature, in a sentence or two. Keep it short. The interview is where the detail comes from.
- `{{decided}}`: What you have already decided. Optional. Decisions Claude should build on rather than question again.
- `{{pace}}`: Questions per turn. Choose one:
  - A few questions at a time (default)
  - One question at a time

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You have a feature idea that is bigger than a single change, and the requirements still live mostly in your head.
- You want the hard questions, such as edge cases, failure states and tradeoffs, raised before any code exists, while they are still cheap to answer.
- You plan to hand the implementation to a fresh Claude Code session, a teammate or a future you, and need a written spec to work from.

## When not to use it

- The task is small and already clear. An interview adds turns without adding much; ask for the change directly or use the planning template.
- The decisions belong to someone else, such as a product owner or a client. Collect their answers first, or run the interview with them in the room.
- You want a polished document for readers outside the team. The spec this produces is a working document for building the feature, not a proposal.

## Why this structure

- The prompt starts from a minimal description on purpose. The interview, not your first paragraph, is where the detail comes from, so you do not need to know everything up front.
- It names the AskUserQuestion tool, which Claude Code can use to ask structured questions, and falls back to plain chat questions where that tool is not available.
- The four question areas, implementation, UX, edge cases and tradeoffs, steer the interview toward topics that tend to surface late and cause rework.
- Listing what is already decided keeps the interview from relitigating settled choices, while still allowing Claude to flag a real conflict.
- The closing paragraph defines what the spec must contain: the files and interfaces that change, what is left out, and a final check that confirms the whole feature. With those three parts, someone who was not in the interview can build the feature and verify it.
- Ending with "do not start implementing" keeps the spec session separate. Start a new session to build from the spec, so it begins with clean context.

## Example input (fictional)

The feature, in a sentence or two:

```
Per-workspace rate limits for the public API
```

What you have already decided:

```
Limits are set per plan. Admins can raise them for a single workspace.
```

Questions per turn:

```
A few questions at a time
```

## Follow-ups to send Claude

- Before you write the spec, list the three decisions you think I am most likely to regret, and why.
- Read SPEC.md back and mark every sentence that a developer could interpret in two ways.
- Split the spec into changes that can each be built, tested and merged on their own, in order.

## Common mistakes

- Writing a long feature description first. It front-loads your assumptions and gives the interview less to question.
- Answering "whatever you think is best" to most questions. The spec then records Claude's defaults, not your requirements.
- Implementing in the same long session. The context is full of discarded options; a fresh session working from the written spec stays focused.

## Related templates

- [Plan a code change before editing](https://awesomeclaudeprompts.com/prompts/plan-code-change/): Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.
- [Write tests first, then implement](https://awesomeclaudeprompts.com/prompts/test-first-feature/): Have Claude Code write tests that describe a feature before any implementation, confirm they fail, then write code until they all pass.
- [Turn a meeting into tickets](https://awesomeclaudeprompts.com/prompts/turn-meeting-into-tickets/): Have Claude Code read meeting notes, draft the action items as tickets with acceptance criteria, and create them in your tracker through MCP.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Let Claude interview you](https://code.claude.com/docs/en/best-practices#let-claude-interview-you) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.