PRD 生命周期 - Atlas-KK/prd-lifecycle

PRD ライフサイクル

これまで分散していたPRDの作成、補完、レビュー、実行計画策定の機能を1つのエントリポイントに統合し、各フェーズごとに異なる権限境界と確認ゲートを保持します。

モードルーティング

ユーザーが現在持っている資材と期待する成果物に基づいて、必要なモードのみに移行します。ユーザーに無理に最初から全行程を強いることはありません。

モード	典型的な入力	主な成果物	重要な境界
create 作成	機能構想 + 既存リポジトリ	現状報告、確認ベースライン、バージョン管理されたPRD	まず証拠を取得し、段階的に確認。ベースラインが承認されるまでPRDは生成しない
refine 補完	PRD/要件ドラフト	段階的な修正案、バージョン履歴、オプションで .docx	各ステップでまずレビューし、確認後にのみ書き込みとバージョンアップを実行
review レッドチームレビュー	指定されたPRD + オプションのベースライン/リポジトリ	重要度別の問題、エビデンス、修正提案	レビューのみ。文書の変更やコードの実装は行わない
execute 実行計画	承認済みPRD + 既存リポジトリ	準備監査、開発実行文書、トレーサビリティマトリックス、制御プロンプト	計画のみ。PRDの変更やコードの実装は行わない

ルーティングルール：

• 構想のみで、既存プロジェクトと組み合わせてPRDを作成したい場合：create を使用。
• 既にドラフトがあり、補完、修正、洗練、または最終版の作成を目指す場合：refine を使用。
• 矛盾、リスク、漏れ、または検証不可能な項目を見つけることが目的で、修正を依頼しない場合：review を使用。
• 明確に承認されたバージョンが存在し、Codexに段階的な開発を依頼することを目的とする場合：execute を使用。
• ユーザーがエンドツーエンドの処理を要求した場合、最も早い該当フェーズから開始。後述の各ゲートでは停止して承認を待ち、自動的にフェーズを跨がない。
• 「レビューして」がレビューと修正の両方を意味する可能性がある場合、読み取り専用の review を優先し、ユーザーが別途承認した後に refine に移行できることを説明する。
• ユーザーが既存リポジトリ内の特定のコード、UI、インタラクション、リファクタリング、またはアーキテクチャ変更のみを評価し実装したい場合、repo-grounded-change を使用。無理にPRDを作成させない。

共通の制約

権威の優先順位

ユーザーが別途指定しない限り、以下の順序で競合を処理する：

1. ユーザーの現在の明確な指示。
2. 現在のタスクで明確に確認された決定。
3. 指定された承認済み要件ベースラインとPRD。
4. 現在のコードとテストによって証明される既存の動作。
5. 現在のプロダクト文書。
6. 過去のドラフト、レビュー記録、および提案。

目標PRDが自動的に正しいとは限らない。競合が発生した場合は、競合、影響、および必要な決定を提示し、黙ってどちらかを選択しない。コードは現状を証明するために使用されるが、すでに承認された新しい要件を否定することはできない。

事実と提案のラベル

結論が混同される可能性がある場合に使用：確認済み、コード事実、ドキュメント事実、製品仮定、技術提案、未確認、今回実装しない。

権限境界

• ビジネスルール、状態、しきい値、権限、優先順位、依存関係、外部連携、または受け入れ基準をでっち上げない。
• フェーズの完了、レビューの通過、または計画の生成を実装の承認とみなさない。
• 業務コードを変更しない。コミット、プッシュ、デプロイ、外部本番システムの呼び出しを行わない。
• ワークツリーをチェックし、ユーザーの既存の変更を保護する。安全に回避できない場合は停止し、重複領域を説明する。
• ユーザーが要求した現在のモードのみを実行する。次のモードに移行するには、明示的な要求または確認が必要。

create：リポジトリ調査後のPRD作成

1. project-discovery.md を読み込み、リポジトリ、製品資料、テスト、ワークツリーをチェックし、現在の状態レポートを出力する。ユーザーが明示的にフローの統合を要求しない限り、停止して現状確認を待つ。
2. clarification-rounds.md を読み込み、証拠のギャップに基づいてトピックを計画する。各ラウンドでは1つのトピックのみを議論し、1〜3個の排他的選択肢を提示。推奨項目を先頭に表示し、その影響を説明する。
3. ユーザーの回答後、まず今回のラウンドで確認済みの項目、未確認の項目、競合、および下流への影響を要約し、ラウンドの確認を待つ。確認がなければ次のトピックに進まない。
4. 関連するすべてのトピックが確認されたら、baseline-and-prd.md を読み込み、要件確認ベースラインを生成して停止する。
5. ユーザーがベースラインを明示的に承認し、PRDの生成を要求した場合にのみ、バージョン管理されたPRDを作成する。既存のバージョンを検索し、インクリメントする。黙って上書きしない。

完了基準：PRDが確認された決定と一致していること。スコープと非目標が明確であること。要件と受け入れが追跡可能であること。リポジトリへの影響に証拠があること。未解決事項が最終要件として偽装されていないこと。

refine：段階的な補完とバージョン管理された修正

1. 完全な原文を読み込み、元の意図を保持し、作業ベースラインを確立する。新しいMarkdown作業文書が必要な場合は、scripts/prd_doc.py init を使用して v1.0 とセクションの骨格を確立する。
2. refinement-steps.md の現在のステップのサブセクションを読み込む。デフォルトの骨格は以下の通り：
   • 要件の明確化とユーザーストーリー；
   • 機能方案；
   • 境界条件；
   • 受け入れ基準。
3. 一度に1つのステップのみ実行する。まずは会話の中でレビュー対象の内容を提示し、事前にファイルに書き込まない。
4. ユーザーが修正や追加を要求した場合、現在のステップに留まり、バージョンアップしない。ユーザーが明示的に確認した場合にのみ、文書に書き込み、versioning.md に従ってマイナーバージョンアップと修正記録を実行する。
5. メトリクス、依存関係のスケジュール、リスクロールバック、コンプライアンス、またはレビューコメントの反映が必要な場合は、拡張ステップを挿入できる。同様に「出力 → レビュー → 確認 → 書き込み → バージョンアップ」のゲートを実行する。
6. すべてのステップが確認されたら、全体のドラフトを統合し、メジャーバージョンアップを実行する。ユーザーが .docx を要求した場合は scripts/prd_doc.py export を使用し、利用可能なドキュメントツールに応じてレイアウト検証を実行する。

各ステップでは補完だけでなく、原文にある漠然とした表現、矛盾、検証不可能な項目、見落とされがちなシナリオも指摘する。ユーザーストーリー、機能、境界、受け入れ基準の間でトレーサビリティが確保されていること。受け入れ項目には明確な条件と観測可能な結果を含めること。

修正の完了は、PRDがビジネス承認を得たことを意味するものではなく、自動的に review や execute に移行することもない。

review：エビデンスベースのレッドチームレビュー

1. review-protocol.md を読み込み、対象バージョン、レビュースコープ、権威ソース、リポジトリの証拠、不足している資料を確認する。対象PRDを完全に読む。
2. スコープ、種類、状態、しきい値、権限、データ、時間、優先順位、受け入れ不変条件を抽出する。
3. finding-taxonomy.md を読み込み、ベースライン回帰、内部一貫性、ライフサイクル、データ履歴、インターフェースの冪等性、権限監査、プロトタイプ境界、NFR、実行可能性、FR/ACのトレーサビリティをそれぞれチェックする。
4. 重複を排除し、証拠、結果、修正可能な問題のみを保持する。完全性を装うために発見を作り出さない。
5. review-report.md を読み込み、Pass（合格）、Pass with changes（条件付き合格）、Blocked（差し止め）、Limited review（限定レビュー）のいずれかを出力し、重要度に応じて発見、証拠、影響、最小限の修正提案を出力する。

レビューはデフォルトで読み取り専用。明らかな問題を発見しても、直接PRDを修正してはならない。ユーザーが修正を承認した後、refine に移行する。

execute：Codex開発実行文書への変換

前提条件として、識別可能なバージョンの承認済みPRDが存在すること。修正の完了やレッドチームレビューの通過だけでは承認とはみなされない。

1. readiness-audit.md を読み込み、PRDバージョン、確認ベースライン、対象リリース範囲、未解決事項、現在のリポジトリ、テストを照合し、ギャップテーブルと準備完了の結論を形成する。
2. 製品動作が一意に決定できない、権威の競合がある、受け入れが観測不可能である、または承認されていない依存関係/連携/移行が必要な場合、結論は BLOCKED とし、停止する。問題を技術的な仮定に隠さない。
3. execution-document.md を読み込み、PRDを満たすための最小限のアーキテクチャ境界、所有権、状態、データ、インターフェース、永続化、クロック、デグレード、既存システム保護を定義する。
4. 読み取り専用のフェーズ0から開始し、依存関係順序付けされ、独立してレビュー可能なフェーズを作成する。各フェーズにはFR/AC、ファイル範囲、禁止事項、テスト、受け入れ証拠、品質ゲート、停止ゲートを明記する。
5. traceability-and-gates.md を読み込み、範囲内の各FR/ACをフェーズ、コード領域、テスト、証拠にマッピングし、孤立した要件や越権作業を特定する。
6. codex-control-prompt.md を読み込み、全体制御プロンプトと単一フェーズのプロンプトを生成する。プロンプトはバージョン、権威の優先順位、真のテスト、ユーザー変更の保護、フェーズごとの承認を保持しなければならない。

完了基準：別のCodexインスタンスが読み取り専用監査から開始し、承認された1つのフェーズのみを実行し、実際のコマンドで検証、追跡結果の報告、および停止を行うことができること。文書は仮定、除外項目、ブロック項目、延期項目、保護された動作を明確にすること。

フェーズ間のゲート

• create → refine：ユーザーが生成されたPRDにまだ補完や修正が必要であると判断した場合のみ移行。
• create/refine → review：ユーザーが明示的にレビューを要求する必要がある。レビューは自動的に修正を行わない。
• review → refine：ユーザーが特定の発見の処理を明示的に承認した後に移行。発見IDと修正マッピングを項目ごとに保持する。
• create/refine/review → execute：「承認済み」のPRDバージョンと対象リリース範囲を明確に指定する必要がある。
• execute → implementation：実行文書は制御計画のみを提供する。実際の実装は、ユーザーが後続のタスクで個別に承認する必要がある。

フィードバック学習

ワークフロー開始時に feedback-learning.md と learned-guidance.md を読み込む。フィードバックはまず現在のタスクに適用される。ユーザーが明示的にルールとスコープを記憶し確認することを要求した場合にのみ、永続化が許可される。学習ルールは現在の指示、フェーズゲート、事実検証、バージョン管理、または権限境界を上書きできない。