prd-next

vfarcic/dot-ai の shared-prompts/prd-next.md からベンダー提供されています（MIT、Copyright (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。

PRD Next - 次のタスクに取り組む

手順

既存の製品要件定義書（PRD）を分析し、次に取り組むべき最優先のタスクを1つ提案します。その後、ユーザーが取り組むことを確認した場合は、その設計について話し合います。

プロセスの概要

1. コンテキストの明確さを確認する - 直近の会話からPRDが明らかかどうかを判断します
2. 対象PRDを自動検出する - コンテキストが不明確な場合、分析するPRDを適切に特定します
3. 現在の実装を分析する - 実装済みの内容と未実装の内容を把握します（直近の会話に関連情報がある場合は省略）
4. 次に取り組むべき最適なタスクを1つ特定する - 次に取り組むべきタスクを1つ見つけます
5. 推奨事項を提示する - 明確な根拠を示し、確認を待ちます
6. 設計について話し合う - 確認された場合、実装設計の詳細に踏み込みます
7. 実装 - ユーザーがタスクを実装します
8. 進捗を更新する - /prd-update-progress を実行するようユーザーに促します

ステップ 0：コンテキストの認識チェック

最初に、直近の会話からPRDのコンテキストがすでに明確かどうかを確認します。

直近の会話に次の内容があれば、検出／分析を省略します。

• 最近PRDについて話し合った - 「PRD 29に取り組んだばかり」「PRDの更新を完了したばかり」など
• 特定のPRDについて言及がある - 「PRD #X」「MCP Prompts PRD」など
• PRD固有のコマンドを使用した - 特定のPRDを指定した /prd-update-progress や /prd-start の最近の使用
• 作業コンテキストが明確 - 既知のPRDに関する特定の機能、タスク、要件についての話し合い

コンテキストが明確な場合：

• 既知のPRDを使用して、ステップ 6（単一タスクの推奨）に進みます
• 会話履歴から現在の状態と最近の進捗を把握します
• 既知のPRDの状況に基づいて、直接タスクを推奨します

コンテキストが不明確な場合：

• ステップ 1（PRDの検出）に進み、全体を分析します

ステップ 1：PRDのスマート検出（コンテキストが不明確な場合のみ）

次のコンテキスト情報を優先順位順に使用して、対象PRDを自動検出します。

1. Gitブランチの分析 - 現在のブランチ名にPRDのパターンがあるか確認します。

   • feature/prd-12-* → PRD 12
   • prd-13-* → PRD 13
   • feature/prd-* → PRD番号を抽出

2. 最近のGitコミット - 最近のコミットメッセージにPRDへの参照があるか確認します。

   • 「fix: PRD 12 documentation」 → PRD 12
   • 「feat: implement prd-13 features」 → PRD 13

3. Gitステータスの分析 - 変更済み／ステージ済みファイルにPRDを特定する手がかりがあるか確認します。

   • prds/12-*.md の変更 → PRD 12
   • 機能固有のディレクトリ内の変更

4. 利用可能なPRDの検出 - prds/ ディレクトリ内のすべてのPRDを一覧表示します。

   • prds/12-documentation-testing.md
   • prds/13-cicd-documentation-testing.md

5. ユーザーに選択を委ねる - コンテキストの検出に失敗した場合にのみ、ユーザーに指定を求めます

PRD検出の実装：

# Use these tools to gather context:
# 1. Check git branch: gitStatus shows current branch
# 2. Check git status: Look for modified PRD files  
# 3. List PRDs: Use LS or Glob to find prds/*.md files
# 4. Recent commits: Use Bash 'git log --oneline -n 5' for recent context

検出ロジック：

• 高い確度：ブランチ名がPRDのパターンに一致する（例：feature/prd-12-documentation-testing）
• 中程度の確度：Gitステータスに変更済みPRDファイルがある、または最近のコミットでPRDに言及している
• 低い確度：複数のPRDが利用可能な場合は、ヒューリスティックを使用する（最も新しいもの、規模が最大のもの）
• コンテキストなし：利用可能な選択肢をユーザーに提示する

検出結果の例：

🎯 **Auto-detected PRD 12** (Documentation Testing)
- Branch: `feature/prd-12-documentation-testing` ✅
- Modified files: `prds/12-documentation-testing.md` ✅
- Recent commits mention PRD 12 features ✅

PRDを特定したら：

• prds/[issue-id]-[feature-name].md からPRDファイルを読み込みます
• すべてのセクションの完了状況を分析します
• 完了済みの作業と残りの作業の傾向を特定します

ステップ 2：ドキュメントと実装の分析（コンテキストが不明確な場合のみ）

タスクの優先順位を評価する前に、文書化された仕様と現在の実装状況の両方を分析します。

ドキュメント分析（ドキュメント優先の PRD）

ドキュメント優先のアプローチを採用する PRD の場合：

• 参照ドキュメントを読む：PRD の「コンテンツの場所マップ」を確認し、機能仕様の記載場所を特定します
• 目標状態を把握する：どの機能が文書化されているものの、まだ実装されていないかを確認します
• ドキュメントの完全性を確認する：ユーザーのワークフローと例がすべて完全に文書化されているかを確認します
• 相互参照を検証する：ドキュメントのリンクと参照がすべて正しく機能するかを確認します

コードの調査

• 関連ファイルを検索する：Grep/Glob を使用して、機能に関連するファイルを探します
• 主要なモジュールを特定する：PRD に記載されている主要な実装ファイルを特定します
• テストファイルを探す：機能の既存のテストカバレッジを調べます
• 依存関係を確認する：インポートとモジュール間の関係を確認します

実装とドキュメントのギャップ分析

• ドキュメントとコードを比較する：文書化されている内容と、実際に実装されている内容を比較します
• 部分的な実装：未完成の機能や TODO コメントを特定します
• ドキュメントを検証する：記載されている例やコマンドが実際に動作するかを確認します
• アーキテクチャとの整合性：現在のコードが、文書化された動作や PRD のアーキテクチャ上の決定に沿っているかを確認します
• 品質を評価する：コードスタイル、エラー処理、テストカバレッジの不足を確認します

技術的な実現可能性の分析

• 依存関係の競合：PRD の要件が既存のコードと両立するかを確認します
• 破壊的変更：残りのタスクで既存のコードのリファクタリングが必要になるかを確認します
• 統合ポイント：新しい作業が現在の実装とどのようにつながるかを確認します
• 技術的負債：今後の作業を妨げたり、遅らせたりする可能性のある問題を確認します

ステップ 3：完了状況の評価（状況が不明確な場合のみ）

チェックボックスの状態を分析する

すべてのチェックボックスを数え、分類します：

• 完了：[x] の項目
• 未対応：[ ] の項目
• 延期：[~] の項目
• ブロック中：[!] の項目

フェーズ分析

実装フェーズごとに：

• 完了率を算出します
• ボトルネックや停滞している作業を特定します
• 次のフェーズに進む準備ができているかを評価します

要件の網羅性

要件のカテゴリを確認します：

• 機能要件：主要機能の完了状況
• 非機能要件：品質とパフォーマンスに関する側面
• 成功基準：測定可能な成果
• 依存関係：外部要件
• リスク軽減：リスク管理の進捗

ステップ 4：依存関係の分析（状況が不明確な場合のみ）

クリティカルパスの項目を特定する

次のような項目を探します：

• 他の作業をブロックする項目 - 他の作業を開始する前に完了する必要があります
• 主要な機能を可能にする項目 - 完了すると大きな価値をもたらします
• 現在のブロッカーを解消する項目 - 進捗を妨げる要因を取り除きます

依存関係のパターン

PRD レベルの依存関係

• 順次依存関係 - B を始める前に A を完了する必要があります
• 並行作業の機会 - 複数の項目を同時に進められます
• 基盤要件 - 複数の機能で必要となるコア機能です
• 統合ポイント - システムの異なる部分をつなぐ項目です

コードレベルの依存関係

• インポートの依存関係 - 先に実装される必要のあるモジュールへの依存です
• インターフェースの契約 - 利用側より先に定義する必要がある API や型です
• データベーススキーマ - ビジネスロジックより先に必要となるデータモデルの変更です
• テストの依存関係 - 特定のインフラストラクチャやモックを必要とするテストです
• ビルド／デプロイ - 複数のコンポーネントに影響する設定変更です

ステップ 5：戦略的価値の評価（状況が不明確な場合のみ）

価値の高い次のステップ

次のような項目を優先します：

• 複数の項目のブロックを解除する - 高いレバレッジ効果があります
• ユーザーに見える価値を提供する - ユーザーに直接メリットをもたらします
• 技術的リスクを減らす - 重大な不確実性に対処します
• 検証を可能にする - 重要な前提をテストできるようにします
• 知見を得る - 今後の作業に役立つ洞察をもたらします

優先度の低い項目

次の項目を特定します。

• 依存関係が多い - まだ着手できません
• あると便利 - 中核となる価値提案には影響しません
• 最適化が中心 - 既存の動作する機能を改善します
• 外部依存関係が必要 - 他者の対応待ちです

Step 6: タスクを1つ提案する

注：Step 0（明確なコンテキスト）からここに進んだ場合は、会話履歴と既知の PRD の状態を踏まえて提案してください。分析をすべて行ってここに進んだ場合は、詳細な調査結果を使用してください。

次の形式に絞って調査結果を提示します。

# Next Task Recommendation: [Feature Name]

## Recommended Task: [Specific Task Name]

**Why this task**: [2-3 sentences explaining why this is the highest priority right now]

**What it unlocks**: [What becomes possible after completing this]

**Dependencies**: [What's already complete that makes this ready to work on]

**Success criteria**: [How you'll know it's done]

---

**Do you want to work on this task?** 

If yes, I'll plan and implement it. If no, let me know what you'd prefer to work on instead.

Step 7: タスクを計画する（確認された場合）

ユーザーが確認した場合は、タスクを自分で計画してください。ユーザーとの設計議論に持ち込まないでください。技術的な選択はあなたが行い、その理由とともに PRD の Decision Log に記録してください。

• アプローチ：タスクが既存のコードにどう適合するか、影響するモジュールとインターフェース、テストを行う箇所を示します。
• 順序：最小のエンドツーエンドの手順から始め、早い段階でスライスを検証できるようにします。最もリスクの高い前提は、できるだけ早く確認します。
• 技術的な選択：ライブラリ、インターフェース、エラー処理、パフォーマンスのトレードオフを決定して記録し、ユーザーには尋ねません。
• エスカレーションするのは、既存のルールでエスカレーションが必要な事項（外部 API 契約の変更、既存データに影響するスキーマの変更、認証またはセキュリティモデルの変更、取り消し不能な操作）または未解決のプロダクトの意図のみです。推奨する回答を添えて、質問はまとめて1回で行います。

成功基準

このコマンドでは、次のことを行います。

• ✅ 現在の PRD の状態に基づいて、次に取り組む最も価値の高いタスクを1つ特定する
• ✅ この特定のタスクを優先すべき理由を、明確かつ説得力をもって提示する
• ✅ 続行する前にユーザーの確認を待つ
• ✅ 確認された場合、実装設計の詳細なガイダンスを提示する
• ✅ 選択肢を提示しすぎてチームを圧倒するのではなく、最も重要な作業に集中できるようにする
• ✅ 推奨から設計の議論へ移行し、すぐに行動に移せるようにする

Step 8: 完了後に進捗を更新する

重要：PRD を自分で更新しないでください。PRD ファイルを直接編集しないでください。更新コマンドを実行するよう、ユーザーに促してください。

ユーザーがタスクの実装を完了した後は、次のメッセージのみを出力してください。

---

タスクの実装が完了しました。

PRD の進捗を更新して作業をコミットするには、/prd-update-progress を実行してください。

---

その後、停止してください。先へ進まないでください。/prd-update-progress コマンドが PRD の更新、進捗の追跡、コミットを処理します。この分離により、適切なワークフローを維持し、更新の重複や競合を防げます。