prd-update-decisions

vfarcic/dot-ai の shared-prompts/prd-update-decisions.md から取り込まれています（MIT、Copyright (c) 2025 Viktor Farcic）。原著者：Viktor Farcic。

PRD 更新決定スラッシュコマンド

手順

会話中に決定された設計上の判断、戦略の変更、アーキテクチャ上の選択に基づいて PRD を更新します。このコマンドでは、まだコードに反映されていなくても、要件、アプローチ、スコープに影響する概念的な変更を記録します。

プロセスの概要

1. 対象の PRD を特定する - 更新する PRD を決定します
2. 会話のコンテキストを分析する - 設計上の判断や戦略の変更に関する議論を確認します
3. 決定事項を特定する - アーキテクチャ、ワークフロー、要件、スコープの変更を探します
4. PRD のセクションに対応付ける - PRD のどの部分を更新する必要があるかを判断します
5. 更新を提案する - 要件、アプローチ、制約の変更を提案します
6. 決定ログを更新する - 新たな決定事項と、その根拠や影響を記録します

ステップ 1：PRD の分析

更新する PRD をユーザーに尋ねてから、次の作業を行います。

• prds/[issue-id]-[feature-name].md から PRD ファイルを読み込みます
• 現在の要件、アプローチ、制約を把握します
• 設計上の判断によって影響を受ける可能性が最も高い領域を特定します

ステップ 2：会話の分析

意思決定のパターンを把握するため、会話のコンテキストを確認します。

設計上の判断を示す指標

戦略の変更を示唆する会話の要素を探します。

• ワークフローの変更：「これを次のように簡略化しましょう……」「代わりにこうするのはどうでしょう……」
• アーキテクチャ上の決定：「これを使うべきだと思います……」「より良いアプローチは……」
• 要件の変更：「実際には、これは必要ありません……」「これも含めるべきです……」
• スコープの調整：「これは後回しにしましょう……」「これは想定より複雑です……」
• ユーザーエクスペリエンスの方向転換：「ユーザーは……のほうを好むでしょう」「このワークフローのほうが理にかなっています」

具体的な決定の種類

• 技術アーキテクチャ：フレームワークの選択、設計パターン、データ構造
• ユーザーエクスペリエンス：ワークフローの変更、インターフェースの決定、インタラクションモデル
• 要件：新規要件、変更された要件、削除された要件
• スコープ管理：追加、延期、または削除された機能
• 実装戦略：段階的な実施方法の変更、優先順位の調整、アプローチの変更

ステップ 3：決定による影響の評価

特定した決定ごとに、次の点を評価します。

影響の分類

• 要件への影響：どの要件を追加、変更、または削除する必要がありますか？
• スコープへの影響：プロジェクトのスコープは拡大しますか、それとも縮小しますか？
• スケジュールへの影響：プロジェクトの各段階や納期に影響しますか？
• アーキテクチャへの影響：技術的な制約やアプローチは変わりますか？
• コード例への影響：どの例、インターフェース、スニペットが古くなりますか？
• リスクへの影響：新たなリスクが生じますか、それとも既存のリスクが軽減されますか？

決定事項の記録形式

決定ごとに、次の項目を記録します。

• 決定：何が決定されたか
• 日付：決定された日付
• 根拠：このアプローチが選ばれた理由
• 影響：PRD の要件、スコープ、またはアプローチへの影響
• コードへの影響：更新が必要なコード例、インターフェース、スニペット
• 担当者：決定または承認を行った人

ステップ 4：PRD の更新

該当する PRD のセクションを更新します。

決定ログの更新

• 新たに確定した決定事項を、日付と根拠とともに追加します
• 決定が行われた場合、未解決の質問を解決済みとして記録します
• 要件とスコープに対する決定の影響を更新します

要件の更新

• 設計の変更に基づいて機能要件を変更します
• パフォーマンスや品質の基準が変わった場合は、非機能要件を更新します
• 測定方法や目標が変わった場合は、成功基準を調整します

実装アプローチの更新

• 順序や優先順位が変わった場合は、各段階を更新します
• 技術的なアプローチが変化した場合は、アーキテクチャ上の決定を変更します
• 機能の追加、延期、または削除に応じて、スコープ管理を調整します

コード例の検証と更新

• 古くなった例の特定：設計上の決定の影響を受ける可能性があるコードスニペットを PRD から探します
• インターフェースの変更：関数シグネチャ、パラメーターの型、または戻り値が変更された場合、例を更新します
• API の変更：メソッド名、クラス構造、またはデータ形式が変更された場合、例を修正します
• ワークフローの更新：ユーザーとのやり取りのパターンや手順が変更された場合、プロセスの例を更新します
• 検証が必要な項目に印を付ける：引き続き動作することを確認するために手動テストが必要なコード例に印を付けます

タスクとマイルストーンの更新

• 既存のタスクではカバーされていない作業が決定によって発生する場合は、新しいタスクを作成します（例：新しい統合、移行手順、検証要件）
• 決定によってプロジェクトの範囲や段階に大きな変更が生じる場合は、新しいマイルストーンを追加します（例：延期された機能の新しいフェーズ、または追加の納品チェックポイント）
• タスクで必要な作業や実装方法が決定によって変わる場合は、既存のタスクを更新します
• 範囲の変更や要件の削除によって不要になったタスクは、削除するか延期します
• 決定によって優先順位が変わり、最初に納品すべきものが変わる場合は、優先順位を並べ替えます

リスクと依存関係の更新

• 設計上の決定によって新たに生じるリスクを追加します
• アプローチが変わった場合は、リスク軽減策を更新します
• アーキテクチャの変更が統合に影響する場合は、依存関係を変更します