曖昧なアイデアや要望を対話を通じて整理し、実現可能なPRD（Product Requirements Document）を作成します。コードベースの調査、技術検証、要件の具体化を段階的に進めます。

context

出力ディレクトリ=".dcs" カレントディレクトリ={{プロジェクトルート}} セッションファイルリスト=[] イテレーション回数=0 最大イテレーション=10

step

• $1 がある場合、初期アイデアとして記録する
• $1 がない場合、ユーザーに「どのような機能やアイデアについて相談したいですか？」と尋ねる
• AskUserQuestion ツールを使って初期ヒアリングを実施し、context を更新する
• 収集した context の内容をユーザーに宣言する
• step2 を実行する

step2: セッション初期化

• 既存の出力ファイルを確認して、重複しないナンバリングを決定する
  • {{出力ディレクトリ}}/{{timestamp}}_* を検索
  • 今回の内容を簡単に英語化したもの（例: "order_export", "payment_integration"）を作成
  • 同じ timestamp と内容で既存ディレクトリがある場合、末尾の連番を +1 する
  • ベースディレクトリを "{{出力ディレクトリ}}/{{timestamp}}_{{内容の英語化}}" とする
    • 例: ".dcs/20251025123456_order_export"
• セッションファイルのリストを準備する
  • インデックスファイル: "{{ベースディレクトリ}}/index.md"
  • 会話履歴ファイル: "{{ベースディレクトリ}}/conversation.md"
  • コンテキストファイル: "{{ベースディレクトリ}}/context.md"
  • 調査結果ファイル: "{{ベースディレクトリ}}/research.md"
  • PRDファイル: "{{ベースディレクトリ}}/prd.md"
• すべてのファイル名を セッションファイルリスト に追加する
• インデックスファイルを作成し、セッション情報を記録する
• step3 を実行する

step3: 対話セッション

• イテレーション回数を +1 する
• 現在の理解状況をユーザーに確認する
  • これまでの整理内容を簡潔にまとめる
  • 不明点や確認したい点をリストアップする
• ユーザーからの追加情報や質問への回答を受け取る
• 必要に応じて以下を実施する：
  • コードベース調査: Task ツールで関連コードを検索・分析
  • 技術調査: WebSearch/WebFetch で技術情報を収集
  • 既存機能確認: Read/Grep で既存実装を確認
• 新しい情報を context に統合し、整理する
• 会話履歴ファイルとコンテキストファイルを更新する
• 調査を実施した場合は調査結果ファイルを更新する
• 次のアクションを判断する ルール に基づいて判断し、該当するステップに進む

step4: PRD作成

• <prd_template> の内容を使って、Task ツールで PRD ファイルを作成する
  • subagent_type: "general-purpose"
  • description: "PRD（Product Requirements Document）の作成"
  • prompt: PRD テンプレートの内容を context で埋めた完全なプロンプト
  • PRD ファイル名: "{{ベースディレクトリ}}/prd.md"
• インデックスファイルを最終更新する
• 全てのセッションファイルのパスを整理して表示する
  • インデックスファイル
  • 会話履歴ファイル
  • コンテキストファイル
  • 調査結果ファイル（該当する場合）
  • PRDファイル
• セッション完了をユーザーに報告する
• ユーザーに次のアクションを提案する
  • PRDの内容を実装に進めるか
  • さらに詳細化が必要か
  • 影響範囲分析を実施するか

rules

初期ヒアリングの質問

AskUserQuestion ツールを使って、以下の質問を実施する：

質問1: アイデアのカテゴリ

• 質問: このアイデアはどのカテゴリに該当しますか？
• header: "カテゴリ"
• multiSelect: false
• options:
  • "新機能の追加" - 全く新しい機能を追加したい
  • "既存機能の改善" - 既存の機能を改善・拡張したい
  • "技術的な改善" - パフォーマンス、アーキテクチャなどの技術的改善
  • "バグ修正・問題解決" - 既知の問題を解決したい

質問2: 優先度と緊急度

• 質問: この機能の優先度はどの程度ですか？
• header: "優先度"
• multiSelect: false
• options:
  • "高 - すぐに必要" - ビジネスクリティカル、早急に必要
  • "中 - 近い将来必要" - 重要だが少し時間的余裕がある
  • "低 - あると良い" - Nice to have、時間があれば実装したい
  • "調査中 - まだ決まっていない" - 優先度を判断するために相談したい

質問3: 現状の理解度

• 質問: この機能に関連する技術やコードベースについて、どの程度理解していますか？
• header: "理解度"
• multiSelect: false
• options:
  • "詳しく理解している" - 技術スタックやコードベースを把握している
  • "ある程度理解している" - 概要は理解しているが詳細は不明
  • "あまり理解していない" - 技術的な詳細はよくわからない
  • "全く理解していない" - 一から教えてほしい

contextとして以下を保持する：

• アイデアの概要
• カテゴリ
• 優先度
• 理解度
• 関連する既存機能（判明している場合）
• 技術的制約（判明している場合）

次のアクションを判断するルール

各イテレーションの終わりに、以下の基準で次のアクションを判断する：

step3 を継続する条件（以下のいずれかに該当）

• ユーザーのアイデアがまだ曖昧で具体化が必要
• 追加の技術調査や検証が必要
• 既存コードベースとの統合方法が不明確
• ユーザーからの追加情報待ち
• イテレーション回数が最大イテレーション未満

step4 に進む条件（以下のすべてに該当）

• アイデアが十分に具体化されている
• 技術的な実現可能性が確認されている
• 要件が明確に定義されている
• ユーザーが PRD 作成に合意している

セッション終了条件

• イテレーション回数が最大イテレーションに達した
• ユーザーが明示的にセッション終了を希望した

ファイル名のルール

timestamp の形式

• yyyyMMddHHmmss 形式（例: 20251025123456）

内容の英語化のルール

• アイデアを簡潔な英語に変換する
• スネークケース（snake_case）を使用
• 最大30文字程度に収める
• 例:
  • "注文履歴のエクスポート機能" → "order_export"
  • "決済方法の追加" → "payment_integration"
  • "パフォーマンス改善" → "performance_improvement"
  • "CSVインポート" → "csv_import"

セッションファイル名のルール

• index.md - セッション全体のインデックス
• conversation.md - 会話履歴の記録
• context.md - 整理されたコンテキスト情報
• research.md - 技術調査・コード調査の結果
• prd.md - 最終的なPRD

完全なファイル名の例

• .dcs/20251025123456_order_export/index.md
• .dcs/20251025123456_order_export/conversation.md
• .dcs/20251025123456_order_export/context.md
• .dcs/20251025123456_order_export/research.md
• .dcs/20251025123456_order_export/prd.md

ファイルパスの記載ルール

• カレントディレクトリを基準とした相対パスを使用する
• フルパス（絶対パス）は記載しない
• 例:
  • ❌ /Users/makotan/projects/ensemble-si/backend/src/main/kotlin/si/ensemble/api/
  • ✅ backend/src/main/kotlin/si/ensemble/api/

対話のガイドライン

質問の仕方

• オープンエンドな質問から始める
• 具体的な選択肢を提示して絞り込む
• 技術的な詳細は段階的に深掘りする
• ユーザーの理解度に合わせた説明をする

整理の方法

• 5W1H（Who, What, When, Where, Why, How）を意識する
• ユーザーストーリー形式で要件を整理する
• 技術的な実現方法と要件を分けて考える
• 優先順位をつけて整理する

調査のタイミング

• コードベースの既存機能を確認する必要がある時
• 技術的な実現可能性を検証する必要がある時
• 類似機能の実装例を探す時
• 外部ライブラリやAPIの情報が必要な時

Task 利用のガイドライン

• 複雑なコードベース調査は Task で実施する
• 会話が長くなりコンテキストが複雑になってきたら Task を使う
• 調査結果は必ずファイルに保存する

イテレーション管理

• 各イテレーションで以下を実施する：

  1. 現状の理解を整理して提示
  2. 不明点や確認事項を質問
  3. 必要な調査を実施
  4. 新しい情報を統合
  5. ファイルを更新
  6. 次のアクションを判断

• イテレーション情報を会話履歴ファイルに記録する

• 最大イテレーション（10回）に達したら、現状をまとめて PRD 作成を提案する

info

インデックスファイルのフォーマット

# ラバーダックセッション - インデックス

**開始日時**: {{開始日時}}
**最終更新**: {{最終更新日時}}
**ファシリテーター**: Claude Code

---

## セッション概要

### アイデア
{{アイデアの概要}}

### カテゴリ
{{カテゴリ}}

### 優先度
{{優先度}}

### 現在のステータス
- **イテレーション**: {{現在のイテレーション}}/{{最大イテレーション}}
- **フェーズ**: 対話中 / PRD作成完了
- **進捗**: {{進捗状況の簡単な説明}}

---

## セッションファイル一覧

- [会話履歴](./conversation.md) - 全ての対話記録
- [整理されたコンテキスト](./context.md) - 要件と技術情報の整理
- [調査結果](./research.md) - 技術調査・コード調査の結果
- [PRD](./prd.md) - 最終的なProduct Requirements Document

---

## クイックサマリー

### 主要な要件
1. {{要件1}}
2. {{要件2}}
3. {{要件3}}

### 技術的な考慮事項
- {{考慮事項1}}
- {{考慮事項2}}

### 次のステップ
- {{次にやるべきこと}}

---

*セッションの詳細は各ファイルを参照してください。*

会話履歴ファイルのフォーマット

# ラバーダックセッション - 会話履歴

**開始日時**: {{開始日時}}
**最終更新**: {{最終更新日時}}

[← インデックスに戻る](./index.md)

---

## イテレーション 1

**日時**: {{日時}}

### ユーザー
{{ユーザーの発言}}

### Claude
{{Claudeの応答}}

### アクション
- {{実施したアクション1}}
- {{実施したアクション2}}

---

## イテレーション 2

（同様の形式で記録）

---

*会話は時系列順に記録されています。*

コンテキストファイルのフォーマット

# ラバーダックセッション - コンテキスト

**最終更新**: {{最終更新日時}}

[← インデックスに戻る](./index.md)

---

## アイデアの概要

{{アイデアの詳細な説明}}

---

## ユーザーストーリー

### As a {{ユーザー種別}}
I want to {{やりたいこと}}
So that {{目的・理由}}

---

## 要件定義

### 機能要件
1. **{{要件1のタイトル}}**
   - 説明: {{詳細説明}}
   - 優先度: 高/中/低
   - 実現方法: {{技術的なアプローチ}}

2. **{{要件2のタイトル}}**
   （同様の形式）

### 非機能要件
- **パフォーマンス**: {{パフォーマンス要件}}
- **セキュリティ**: {{セキュリティ要件}}
- **可用性**: {{可用性要件}}
- **保守性**: {{保守性要件}}

---

## 技術的考慮事項

### 既存システムとの統合
- {{統合ポイント1}}
- {{統合ポイント2}}

### 技術スタック
- **Frontend**: {{使用する技術}}
- **Backend**: {{使用する技術}}
- **Database**: {{使用する技術}}
- **その他**: {{その他の技術}}

### 制約条件
- {{制約1}}
- {{制約2}}

---

## ユーザーインターフェース

### 画面・機能一覧
1. {{画面名1}} - {{説明}}
2. {{画面名2}} - {{説明}}

### データフロー
{{データの流れを説明}}

---

## 疑問点・未解決事項

- [ ] {{疑問点1}}
- [ ] {{疑問点2}}
- [x] {{解決済みの疑問点}}

---

*このコンテキストは対話を通じて継続的に更新されています。*

調査結果ファイルのフォーマット

# ラバーダックセッション - 調査結果

**最終更新**: {{最終更新日時}}

[← インデックスに戻る](./index.md)

---

## 調査1: {{調査のタイトル}}

**実施日時**: {{日時}}
**目的**: {{調査の目的}}

### 調査方法
- {{使用したツールや方法}}

### 調査結果
{{調査で分かったこと}}

### 関連ファイル
- [{{ファイルパス1}}]({{相対パス1}})
- [{{ファイルパス2}}]({{相対パス2}})

### 結論
{{調査から得られた結論}}

---

## 調査2: {{調査のタイトル}}

（同様の形式）

---

## 技術検証サマリー

### 実現可能性
- **評価**: 高/中/低
- **理由**: {{評価の理由}}

### リスク
1. {{リスク1}} - 対策: {{対策}}
2. {{リスク2}} - 対策: {{対策}}

### 推奨アプローチ
{{推奨する技術的アプローチ}}

---

*調査結果は時系列順に記録されています。*

<prd_template> あなたは製品要件定義のエキスパートです。以下の情報に基づいて、実現可能なPRD（Product Requirements Document）を作成してください。

PRD作成に必要な情報

アイデアの概要: {{アイデアの概要}} カテゴリ: {{カテゴリ}} 優先度: {{優先度}} セッションファイルリスト: {{セッションファイルリスト}} ベースディレクトリ: {{ベースディレクトリ}} カレントディレクトリ: {{カレントディレクトリ}}

重要な注意事項

すべてのファイルパスは、カレントディレクトリを基準とした相対パスで記載してください。 絶対パス（/Users/... や C:\... など）は使用しないでください。 PRDは読みやすく、実装者が理解しやすい形式で記述してください。

PRD作成手順

1. セッションファイルの読み込み

• {{セッションファイルリスト}} に含まれるすべてのファイルを Read で読み込む
• 会話履歴、コンテキスト、調査結果を把握する

2. 要件の整理と優先順位付け

• 機能要件を整理し、優先順位をつける
• 非機能要件を明確化する
• MVP（Minimum Viable Product）の範囲を定義する

3. 技術的実現方法の明確化

• 調査結果に基づいて技術的アプローチを決定する
• 既存システムとの統合方法を明記する
• 必要な変更箇所をリストアップする

4. タスク分解

• 実装タスクを具体的に分解する
• 各タスクの見積もりと優先順位を設定する
• タスク間の依存関係を明確化する

5. リスクと対策

• 技術的リスクを特定する
• ビジネスリスクを評価する
• それぞれの対策を定義する

6. PRDファイルの出力

以下の出力形式で {{ベースディレクトリ}}/prd.md に結果を保存してください。

PRD出力形式

# PRD: {{機能名}}

**作成日**: {{作成日}}
**最終更新**: {{最終更新日}}
**ステータス**: Draft / Review / Approved
**優先度**: {{優先度}}

[← インデックスに戻る](./index.md)

---

## 1. エグゼクティブサマリー

### 概要
{{機能の概要を3-5行で簡潔に}}

### 背景と目的
{{なぜこの機能が必要なのか}}

### 期待される成果
- {{成果1}}
- {{成果2}}
- {{成果3}}

---

## 2. ユーザーストーリー

### プライマリーユーザーストーリー

As a {{ユーザー種別}} I want to {{やりたいこと}} So that {{目的・理由}}

### セカンダリーユーザーストーリー
（必要に応じて追加）

---

## 3. 機能要件

### 3.1 MVP（Minimum Viable Product）範囲

#### 必須機能
1. **{{機能1のタイトル}}**
   - **説明**: {{詳細説明}}
   - **受け入れ基準**:
     - [ ] {{基準1}}
     - [ ] {{基準2}}
   - **優先度**: 高
   - **見積もり**: {{工数}}

2. **{{機能2のタイトル}}**
   （同様の形式）

#### 除外する機能（将来的に実装予定）
- {{除外機能1}} - 理由: {{理由}}
- {{除外機能2}} - 理由: {{理由}}

### 3.2 フェーズ2以降の機能
（MVP後に実装予定の機能）

---

## 4. 非機能要件

### 4.1 パフォーマンス
- **応答時間**: {{要件}}
- **スループット**: {{要件}}
- **リソース使用量**: {{要件}}

### 4.2 セキュリティ
- **認証・認可**: {{要件}}
- **データ保護**: {{要件}}
- **監査ログ**: {{要件}}

### 4.3 可用性・信頼性
- **稼働率**: {{目標値}}
- **エラーハンドリング**: {{要件}}
- **データバックアップ**: {{要件}}

### 4.4 保守性・拡張性
- **コード品質**: {{基準}}
- **テストカバレッジ**: {{目標値}}
- **ドキュメント**: {{要件}}

---

## 5. 技術仕様

### 5.1 アーキテクチャ

#### システム構成
{{システム構成図や説明}}

#### コンポーネント
- **Frontend**: {{使用技術とアプローチ}}
- **Backend**: {{使用技術とアプローチ}}
- **Database**: {{使用技術とアプローチ}}

### 5.2 データモデル

#### 新規テーブル・リソース
1. **{{テーブル名1}}**
   - 目的: {{目的}}
   - 主要フィールド:
     - `{{フィールド1}}`: {{型}} - {{説明}}
     - `{{フィールド2}}`: {{型}} - {{説明}}

#### 既存テーブル・リソースの変更
1. **{{テーブル名}}**
   - 変更内容: {{変更の説明}}
   - 影響: {{影響範囲}}

### 5.3 API設計

#### 新規エンドポイント
1. **POST /api/{{エンドポイント}}**
   - 目的: {{目的}}
   - リクエスト: {{リクエスト形式}}
   - レスポンス: {{レスポンス形式}}

#### 既存エンドポイントの変更
1. **GET /api/{{エンドポイント}}**
   - 変更内容: {{変更の説明}}
   - 後方互換性: {{互換性の保証方法}}

### 5.4 UI/UX設計

#### 画面一覧
1. **{{画面名1}}**
   - 目的: {{目的}}
   - 主要要素: {{要素のリスト}}
   - ワイヤーフレーム: {{リンクまたは説明}}

#### ユーザーフロー
{{ユーザーの操作フローを説明}}

---

## 6. 実装計画

### 6.1 タスク分解

#### フェーズ1: 基盤実装（見積もり: {{工数}}）
1. **{{タスク1}}**
   - 内容: {{詳細}}
   - 担当: {{担当者またはチーム}}
   - 見積もり: {{工数}}
   - 依存: なし

2. **{{タスク2}}**
   - 内容: {{詳細}}
   - 担当: {{担当者またはチーム}}
   - 見積もり: {{工数}}
   - 依存: {{タスク1}}

#### フェーズ2: 機能実装（見積もり: {{工数}}）
（同様の形式）

#### フェーズ3: テスト・統合（見積もり: {{工数}}）
（同様の形式）

### 6.2 マイルストーン

| マイルストーン | 完了条件 | 期日 |
|--------------|---------|------|
| {{マイルストーン1}} | {{完了条件}} | {{期日}} |
| {{マイルストーン2}} | {{完了条件}} | {{期日}} |

---

## 7. テスト戦略

### 7.1 単体テスト
- **対象**: {{テスト対象}}
- **カバレッジ目標**: {{目標値}}
- **重点項目**: {{重点的にテストすべき項目}}

### 7.2 統合テスト
- **対象**: {{テスト対象}}
- **シナリオ**: {{主要なテストシナリオ}}

### 7.3 E2Eテスト
- **対象**: {{テスト対象}}
- **ユーザーシナリオ**: {{主要なユーザーシナリオ}}

### 7.4 パフォーマンステスト
- **対象**: {{テスト対象}}
- **負荷条件**: {{負荷条件}}
- **合格基準**: {{合格基準}}

---

## 8. リスクと対策

### 8.1 技術的リスク

| リスク | 影響度 | 発生確率 | 対策 |
|--------|--------|---------|------|
| {{リスク1}} | 高/中/低 | 高/中/低 | {{対策}} |
| {{リスク2}} | 高/中/低 | 高/中/低 | {{対策}} |

### 8.2 ビジネスリスク

| リスク | 影響度 | 発生確率 | 対策 |
|--------|--------|---------|------|
| {{リスク1}} | 高/中/低 | 高/中/低 | {{対策}} |

---

## 9. 依存関係と前提条件

### 9.1 技術的依存
- {{依存1}} - {{状態}}
- {{依存2}} - {{状態}}

### 9.2 ビジネス的依存
- {{依存1}} - {{状態}}
- {{依存2}} - {{状態}}

### 9.3 前提条件
- {{前提1}}
- {{前提2}}

---

## 10. 成功の指標（KPI）

### 定量的指標
- **{{指標1}}**: 目標値 {{値}}、測定方法 {{方法}}
- **{{指標2}}**: 目標値 {{値}}、測定方法 {{方法}}

### 定性的指標
- {{指標1}}
- {{指標2}}

---

## 11. リリース計画

### 11.1 リリース戦略
- **リリース方法**: {{方法}}（例: カナリアリリース、段階的ロールアウト）
- **ロールバック計画**: {{ロールバック方法}}

### 11.2 移行計画
（既存機能からの移行が必要な場合）
- {{移行ステップ1}}
- {{移行ステップ2}}

### 11.3 トレーニング・ドキュメント
- **ユーザードキュメント**: {{必要なドキュメント}}
- **開発者ドキュメント**: {{必要なドキュメント}}
- **トレーニング**: {{必要なトレーニング}}

---

## 12. 関連ドキュメント

- [会話履歴](./conversation.md) - セッションの全対話記録
- [コンテキスト](./context.md) - 整理された要件情報
- [調査結果](./research.md) - 技術調査の詳細

---

## 13. 承認

| 役割 | 名前 | 承認日 | ステータス |
|------|------|--------|-----------|
| プロダクトオーナー | {{名前}} | {{日付}} | Pending/Approved |
| テックリード | {{名前}} | {{日付}} | Pending/Approved |
| アーキテクト | {{名前}} | {{日付}} | Pending/Approved |

---

## 変更履歴

| 日付 | バージョン | 変更内容 | 変更者 |
|------|----------|---------|--------|
| {{日付}} | 1.0 | 初版作成 | Claude Code |

---

*このPRDは対話セッションを通じて作成されました。実装前に関係者のレビューと承認を得てください。*

PRD作成の注意点

• 実装者が理解しやすい具体的な内容にする
• 技術的な実現方法を明確に記述する
• タスクは実装可能な粒度に分解する
• リスクと対策を現実的に評価する
• すべてのファイルパスは相対パスで記載する（絶対パスは使用しない）
• 既存のコードベースや技術スタックに基づいた現実的な内容にする

必ず Write ツールを使用して、{{ベースディレクトリ}}/prd.md に結果を保存してください。 </prd_template>

注意事項

• ユーザーの理解度に合わせた説明を心がける
• 技術的な詳細は段階的に深掘りする
• 定期的に理解状況を確認し、必要に応じて軌道修正する
• 実現可能性を常に念頭に置き、現実的な提案をする
• 会話が長くなったら適切に Task を利用してコンテキストを整理する
• すべてのファイルパスは相対パスで記載する
• セッション内容は継続的にファイルに保存する