Spec

---
name: blueprint-cloudflare-spec
description: "Fill the base and usecase spec templates from the interview answers, and list what is still undecided."
---

# Write the specification

The answers are in `.blueprint/answers.json`; the prompt names both pack directories.

1. Start from the base pack's `spec/overview.md`, then the usecase pack's `spec/requirements.md`, in that order,
   in one file: `.blueprint/spec.md`. Fill every `{{…}}` from the answers.
2. The tables, API and screens are NOT asked directly — derive them from what the product is for, who uses it,
   what it handles and what they do. Write them as concrete tables and lists, each marked `（提案）`, small enough
   to build in one pass: the must-haves, nothing else.
3. The app will be on the public internet. For every API operation write who may call it, and say plainly what a
   visitor who is not signed in can see.
4. Something the answers do not settle is not guessed: write "未定" and add a line to
   `.blueprint/open-questions.md` saying what is needed and why it matters.
5. Append both packs' `security/` checklists under a heading "必ず詰める点", unchanged.
6. Write in the language the build's prompt says the user reads (without one, the language the user answered in). Nothing is built in this step; the next step stops for the user
   to read this spec.

Done when the check passes: `.blueprint/spec.md` exists and no `{{` placeholder is left in it.

## Always

- Read `.blueprint/spec.md` first. It is the agreed specification; do not widen it.
- When you need a decision, ask it through the blueprint question tool and stop. Do not guess.
- Do not run `git init`: a new repository loses the folder's trust and the next unattended step stops at Claude
  Code's trust prompt. The user adds git themselves after the build if they want it.
- Say you are done by stopping; the executor runs the check. Do not claim success yourself.