write-prd

このスキルは、プロダクト要件定義書（PRD）を作成します。PRD では、機能要件、ユーザーフロー、UX/UI、ペルソナ、ビジネス上の制約を扱います。技術アーキテクチャ、実装上の判断、テスト戦略は PRD の対象ではありません。これらは後のステップで作成する別の ADR ドキュメントに記載します。

明らかに該当しないステップは省略できますが、必須の質問ステップは省略しないでください。ユーザーがすでに提供した情報を繰り返さないでください。

---

プロセス

ステップ 1 — 初期説明を収集する

まだ説明が提供されていない場合は、プロダクトまたは機能の詳細な説明をユーザーに求めます。解決する問題、対象ユーザー、すでに考えている動作方法を確認してください。

ステップ 2 — リポジトリを調査する（該当する場合）

既存のコードベースに機能を追加する場合は、現在の状態を把握するために調査します。ユーザーの想定を検証してください。関連する既存コードがある場合は、この手順を省略しないでください。

ステップ 3 — 確認質問をする（必須 — 最低 5 問）

PRD を作成する前に、焦点を絞った確認質問を少なくとも 5 つユーザーに尋ねてください。回答を得るまでは作成を始めないでください。説明にすでに記載されている項目については、同じ質問を繰り返さず、別の判断について掘り下げてください。

最低限、次の項目を確認してください。

• ユーザーは誰ですか？ 特定のペルソナや例外的なケースはありますか？
• メインの正常系の操作の後に何が起きますか？（例：フォーム送信後、AI による判断の後）
• この PoC／MVP で明示的に対象外とする項目は何ですか？
• エラーや不明確・曖昧なケースでは、どのように動作すべきですか？
• 法的要件、API 制限、サードパーティーの規則、ファイル形式など、作成前に検証すべき外部制約はありますか？
• ワイヤーフレームのレベルで、UI/UX はどのようなものにする必要がありますか？
• AI／エージェントが関与する場合、明確な判断ができないときにエージェントはどう動作すべきですか？ エージェントに許可されていないことは何ですか？

メインフローに影響する判断は、作成前に確定してください。残っている前提や未解決の質問は、答えを作り上げずに PRD に記録してください。

ステップ 4 — 外部情報を調査する（必要な場合）

プロダクトに外部 API、ファイル形式の制約、法的要件、サードパーティーサービスの制限が関係する場合は、作成前に調査してください。未検証の数値や制約を PRD に記載しないでください。

ステップ 5 — PRD を作成する

以下のテンプレートを使用してください。結果を docs/PRD.md（またはユーザーが指定したパス）に保存してください。

ステップ 6 — 作業を止めてから ADR について尋ねる

PRD を保存したら、そこで作業を止めてください。実装を始めず、同じ実行内で ADR を作成しないでください。

この PRD をもとに ADR を作成するため、write-adr スキルで続けるかどうかをユーザーに尋ねてください。判断するのはユーザーです。促されていないのに開始したり、回答が「はい」だと決めつけたりしないでください。

---

ルール

• 言語：説明や会話の言語にかかわらず、PRD は必ず英語で作成してください。
• マーケティング表現の禁止：誇張や、「ユーザーが喜ぶでしょう」といった表現、曖昧な最上級表現は使わないでください。すべての文は、プロダクトを実装する開発者やエージェントにとって有用でなければなりません。
• 技術的な実装詳細の禁止：フレームワーク、ライブラリ、ファイルパス、SDK の選択、データベーススキーマ、コードパターンを指定しないでください。これらは ADR（アーキテクチャ決定記録）に記載します。機能上の動作のみを記述してください。
• テスト戦略の禁止：テストケースやテストに関する判断は PRD ではなく、ADR に記載します。
• 測定可能な受け入れ基準：すべての AC は検証可能でなければなりません。「正しく動作する」は AC ではありません。「10 MB を超えるファイルの場合、プロダクトはファイルを保存せず、『File exceeds the 10 MB limit』と表示する」のように記述してください。
• 対象外の明記は必須：対象に含まれないものを明示することは、対象を明記することと同じくらい重要です。これにより、実装中のスコープの拡大を防げます。
• 目的：この PRD は、開発者エージェントが ADR を作成し、その後アプリケーションを実装するために使用されます。その対象読者に向けて記述してください。

---

PRD テンプレート

# PRD — [Product / Feature Name]

---

## 1. Executive Summary

2-3 sentences. What is being built, for whom, and what problem it solves. This is a PoC/MVP/feature — state it.

---

## 2. Problem Statement

What problem exists today. Why it matters. What the user currently has to do instead. No solution here — only the problem.

---

## 3. Users / Personas

2-3 concrete personas. For each: who they are, what they want to do, what they expect from the outcome.

---

## 4. Main Flows

One subsection per scenario (happy path + key alternative paths). Step-by-step numbered list. Include what the system does at each step, not just what the user does.

---

## 5. User Stories

Format: "As [who], I want [what], so that [why]."

Minimum 4 user stories. Cover:
- Happy path (main scenario)
- Error cases (invalid input, service unavailable, ambiguous result)
- Session/state scenarios (if applicable)

---

## 6. Acceptance Criteria

Group by area (Form, AI Decision, Chat, Session, General, etc.).
Each criterion is prefixed AC-XX and is a single, testable, measurable statement.
Do not use subjective language.

---

## 7. Out of Scope

Explicit list of what is NOT being built. Use bold headers for each item.
Include: auth, integrations, admin UI, notifications, multilingual support, mobile apps, etc. — whatever does not apply.

---

## 8. Constraints

### Business
Policy, legal, or operational constraints the product must respect.

### Functional
Concrete limits: file size, accepted formats, number of items, supported browsers/devices, language, etc.

### External document / data references (if applicable)
If the product uses external files (policy docs, knowledge base, etc.), list them in a table: document name | file path | when it is used.

---

## 9. UI Description (wireframe level)

One subsection per screen. Describe:
- What the user sees (layout structure, key elements)
- What each interactive element does
- Error states and empty states
- Loading states
- Navigation between screens

No visual design details (colors, fonts, spacing). Functional and UX detail only.

---

## 10. User Flow Diagram

Mermaid flowchart covering all main flows from Section 4, including branching and error paths.

```mermaid
flowchart TD
    ...
```

---

## 11. Agent / System Behavior Specification (if applicable)

Include this section if the product involves an AI agent, LLM, or automated decision system.

- Role and purpose of the agent
- What the agent is allowed to do and what it is NOT allowed to do
- Decision categories and how each should be communicated
- Mandatory disclaimers or legal notices the agent must always include
- How the agent should handle off-topic questions or out-of-scope requests
- Language and tone requirements

---

## 12. Further Notes (optional)

Any open questions, assumptions made, or decisions deferred to a later stage.