| name | prd |
| description | Generates a PRD (Product Requirements Document) from Japanese requirement notes or memos. Triggers: prd, requirements, 要件定義, PRD作成, 要求仕様. Source-code read-only — never modifies source code or test files. Outputs structured PRD to output/prd/ (requires Write permission to output/prd/). Takes a file path as argument: /prd <file-path>
|
| context | fork |
PRD Generator
日本語の要求メモ・要件メモファイルを入力として、Claude Codeが理解しやすい構造化された
PRD（Product Requirements Document）を生成するスキル。ソースコードは一切変更しない。
前提条件
| 参照ファイル | 用途 | スタブ時のフォールバック |
|---|
docs/project.md | 技術スタック・ルーティング | project-config.md §1〜§3 を直接参照 |
docs/architecture.md | ディレクトリ構成・テスト配置 | project-config.md §4 を直接参照 |
docs/data-model.md | 既存スキーマ | スキップ（新規プロジェクトでは未生成） |
docs/development-patterns.md | コード規約・落とし穴 | project-config.md §11 を直接参照 |
docs/ がスタブの場合でもPRD生成は可能。project-config.md を直接参照してフォールバックする。
基本姿勢
- 読み取り専用（ソースコード変更禁止）
- 入力ファイルの内容を忠実に反映する（勝手な要件追加・削除をしない）
- 曖昧な記述は「【要確認】」として明示し、選択肢を提示する
- 出力は人間がレビュー・承認するためのもの
- 既存の
docs/ ドキュメントと整合性を保つ
使い方
/prd <要求メモファイルのパス>
引数のファイルパスは絶対パス・相対パスどちらも可。
複数ファイルを指定する場合はスペース区切りで列挙する。
例
/prd requirements.md
/prd input/requirements/REQ_001.md
/prd memo1.md memo2.md
出力先
- デフォルト:
output/prd/PRD_<機能名>.md（output/ディレクトリが存在する場合）
- フォールバック:
docs/PRD.md
他スキルとの連携
| 前工程 | 本スキル | 後工程 |
|---|
| 要求メモ作成 | /prd | /architecture → /plan → /implementing-features |
ワークフロー
Phase 1: 入力分析
- ファイル読み込み — 引数で渡されたファイルを
Read ツールで読み込む
- 構造分析 — 要求の種類を分類する:
- 新機能追加
- 既存機能の変更・改善
- バグ修正
- 非機能要件（パフォーマンス、セキュリティ等）
- 用語整理 — ドメイン固有の用語を抽出・定義する
Phase 2: 現状調査
- 既存コードベース調査 — 関連する既存機能・コンポーネント・ストアを特定する
- 既存ドキュメント確認 —
docs/ 配下の関連情報を確認する
- 技術的制約の把握 — 技術スタック・アーキテクチャ上の制約を整理する
Phase 3: PRD生成
- 構造化 — 下記の出力フォーマットに従ってPRDを生成する
- 整合性チェック — 要件間の矛盾・抜け漏れがないか確認する
- 曖昧箇所の明示 — 判断が必要な箇所を「【要確認】」で明示する
Phase 4: 出力
- ファイル出力 —
output/prd/PRD_<機能名>.md に書き出す（output/ が存在しない場合は docs/PRD.md）
- サマリー提示 — PRDの概要をユーザーに提示する
出力フォーマット
# PRD: [機能/プロジェクト名]
> 生成元: [入力ファイル名]
> 生成日: [YYYY-MM-DD]
> ステータス: Draft
## 1. 概要
### 1.1 背景・目的
### 1.2 スコープ
#### スコープ内
#### スコープ外
## 2. 用語定義
| 用語 | 定義 |
| ---- | ---- |
## 3. 機能要件
### FR-001: [機能名]
- **概要**: [機能の説明]
- **ユーザーストーリー**: [誰が][何を][なぜ]したい
- **受け入れ基準**:
- [ ] [具体的な条件]
- **画面・操作フロー**: [UIの動作説明]
- **データモデル変更**: [必要なスキーマ変更]
- **優先度**: Must / Should / Could / Won't
## 4. 非機能要件
### NFR-001: [要件名]
- **カテゴリ**: パフォーマンス / セキュリティ / ユーザビリティ / 保守性
- **要件**: [具体的な基準]
- **計測方法**: [どう検証するか]
## 5. データモデル
### 新規スキーマ
### 既存スキーマ変更
| スキーマ | フィールド | 変更内容 | 後方互換性 |
| -------- | ---------- | -------- | ---------- |
## 6. 画面・UI仕様
## 7. 技術的考慮事項
## 8. テスト戦略
## 9. 実装フェーズ（推奨）
## 10. 要確認事項
| # | 項目 | 選択肢 | 影響範囲 |
| - | ---- | ------ | -------- |
## 11. リスク・懸念事項
| リスク | 影響度 | 対策 |
| ------ | ------ | ---- |
出力契約
セクション定義
| # | セクション | 必須 | 制約 |
|---|
| 1 | 概要（背景・目的, スコープ） | ✅ | スコープ内/外を明示的に分離 |
| 2 | 用語定義 | ✅ | ドメイン固有用語をテーブルで定義。最低1件 |
| 3 | 機能要件 | ✅ | FR-NNN形式のID。各FRに受け入れ基準必須 |
| 4 | 非機能要件 | 条件付き | 入力メモに非機能要件がある場合 |
| 5 | データモデル | ✅ | 新規/変更スキーマ。後方互換性を明記 |
| 6 | 画面・UI仕様 | ✅ | パス, レイアウト, ダークモード対応 |
| 7 | 技術的考慮事項 | ✅ | アーキテクチャ影響, 依存方向 |
| 8 | テスト戦略 | ✅ | ユニット/E2Eの対象と方針 |
| 9 | 実装フェーズ | ✅ | Phase単位。依存関係を明記 |
| 10 | 要確認事項 | 条件付き | 曖昧な判断箇所がある場合 |
| 11 | リスク・懸念事項 | 条件付き | リスクがある場合 |
機能要件（FR）の記述制約
- FR-IDは
FR-001 から連番。ゼロ埋め3桁
- 受け入れ基準は「〜であること」形式で記述（検証可能な文）
- 優先度の列挙値:
Must / Should / Could / Won't
語彙制約
| 用語 | 定義 |
|---|
| 【要確認】 | ユーザー判断が必要な曖昧箇所。選択肢を併記する |
| スコープ内 | このPRDでカバーする機能・変更の範囲 |
| スコープ外 | 明示的に除外する機能・変更 |
| 後方互換 | 既存データの読み込みが壊れないこと |
構造制約
- セクションは番号順（1〜11）で出力
- 入力メモにない要件をFRに追加しない
- 技術選定は決定せず、選択肢と根拠を提示する
- 【要確認】には必ず選択肢（A案/B案）と影響範囲を併記する
PRD品質チェックリスト
既存ドキュメントとの整合
PRD生成時に以下のドキュメントを参照し、整合性を確保する:
| ドキュメント | 参照目的 |
|---|
docs/project.md | 技術スタック・ルーティング・ストア一覧 |
docs/architecture.md | ディレクトリ構成・テスト配置 |
docs/data-model.md | 既存スキーマ・バリデーションルール |
docs/development-patterns.md | コード規約・落とし穴 |
出力ファイル
output/prd/ ディレクトリが存在する場合: output/prd/PRD_<機能名>.md- フォールバック:
docs/PRD.md
- すでに存在する場合: ユーザーに上書き確認を取る
- 複数PRDが必要な場合:
PRD_<機能名>.md のように命名する
禁止事項
- ソースコードの変更（テストファイルも含む）
- 入力メモにない要件の追加（推測で機能を膨らませない）
- 技術選定の決定（選択肢の提示にとどめる）
- プロジェクト固有のデータ（ID、パスワード等）をドキュメントに含めること
- 既存ドキュメント（
docs/ 配下）の変更
