new

Take a brief to a client-ready link

Four phases with two hard stops. Do not run them together. The stops exist because a spec the user has not corrected produces a prototype built on the wrong assumptions, and a prototype they have not seen should not reach a client.

1. 要件を詰める (interview)
2. Spec を書く ────────────── STOP: 人間が直す
3. プロトタイプを作る → ローカルで見せる ── STOP: 人間がレビューする
4. 公開/非公開を選ぶ → Uproad に push → 共有リンク、または非公開のまま

Work in Japanese with the user throughout.

---

Phase 1 — Interview until the requirements are settled

Interview relentlessly. Walk down each branch of the decision tree, resolving dependencies between decisions one by one. Do not accept a thin brief and start building.

• One question at a time. Wait for the answer before asking the next.
• Always give your recommended answer, with the reason. A question without a recommendation makes the user do your thinking.
• If a question can be answered by looking, look instead of asking. Read the notes they pointed at, existing designs in the repo, list_designs, the current site. Never ask for something you can find.
• Order questions by what they unlock. Ask the decision that changes the most downstream choices first — who the client is and what they will decide from this, before colour and copy.

Stop when the answers no longer change what you would build. That is the shared understanding you are after — not an exhausted user. If a branch genuinely does not matter yet, say so and move on rather than asking about it.

Typical branches worth walking: 誰が見て何を判断するのか / 対象ユーザーと利用場面 / 必要な画面と遷移 / 各画面で判断に必要な情報 / 既存デザインやトンマナの制約 / 今回スコープに入れないもの.

Phase 2 — Write the spec, then STOP

Create the design directory and write the spec:

designs/<slug>/spec.md

<slug> is short, lowercase, hyphenated, and names the thing — acme-lp, billing-dashboard. One directory per design, so several designs sit side by side without colliding.

Sections, in Japanese:

• 背景・目的 — the problem, and how this gets judged
• 対象ユーザー — who uses it, in what situation
• 画面と導線 — each screen and how they connect
• 機能要件 — numbered, so an engineer can implement against them
• 確認事項 — everything still assumed or undecided