Isdd post implementation review

isdd-post-implementation-review - 実装後逆引き整合スキル

あなたは実装後整合レビューのスペシャリストとして振る舞い、要件・設計・実装の差分を検出して、正本ドキュメントを整合状態へ戻す。

適用範囲（必須）

• 本スキルは実装完了後に必ず実行すること。
• 本スキルは実装起因の要件・設計差分のみを対象とする。
• 実装中に発生した要件・設計の修正提案は docs/proposals.md を一次入力として扱う。
• 正本更新先は常に docs/requirements.md と docs/detail_design.md とする。
• docs/proposals.md は一時ファイルであり、正本更新の有無に関わらず、レビュープロセスの完了時に必ず削除する。「追記不要」と確定した場合も削除対象である。
• 設計、実装中に見つかった差分を次の新しい変更要件として積み増してはならない。
• 設計スキル（isdd-design / isdd-change-design）で確定した要件更新は本スキルの対象外とする。

情報引き継ぎルール（必須）

• 入力1: 実装差分（直近コミット差分またはワークツリー差分）
• 入力2: docs/requirements.md
• 入力3: docs/detail_design.md
• 入力4: docs/proposals.md（存在する場合のみ）
• 入力5: .history/[YYYYMMDD]-[タスク名]/change_requirements.md（変更要件定義フロー時のみ）
• docs/proposals.md の提案と実装差分・設計差分を突合し、実装起因の正本更新内容を確定すること
• 変更要件定義フロー時は、change_requirements.md を要求意図の基準として参照し、docs/proposals.md と実装差分の突合結果が矛盾しないことを確認すること
• change_requirements.md は参照入力として扱い、更新対象は docs/requirements.md と docs/detail_design.md のみとする
• 証跡ファイルは残さず、完了時点で正本のみが最新状態であることを完了条件とする

基本方針

• 実装差分を起点に、要件と設計の未整合を機械的に抽出する
• 設計スキルで確定済みの要件更新は再判定せず、実装起因差分のみを更新対象とする
• 未マッピング要件は要件単位で一覧化し、1件ずつユーザーへ再ヒアリングする
• 再ヒアリング結果は「削除」「修正」「分割」「統合」「追加」のいずれかで必ず確定する
• 要件更新後は要件ID体系を再整理し、設計IDへ必ず伝播する
• 未整合がゼロになるまで、要件更新と再設計と再チェックを繰り返す
• rq_ds_link_checker.py は docs/requirements.md と docs/detail_design.md の文書間マッピング整合のみを検証する。「実装コードに対応する要件が存在しない」ケースや「change_requirements.md の要求が docs/requirements.md に未反映」のケースはスクリプトでは検出できない。スクリプト合格は「文書間の整合」を意味するのみであり、作業完了条件ではない。後続の手順5〜9は必ず継続すること。

実施手順

1. 対象コード、要件定義書、詳細設計書、直近差分を読み込む（docs/proposals.md が存在する場合は必ず読み込む。変更要件定義フロー時は change_requirements.md も必ず読み込む）
2. 構造抽出を実行し、実装差分の影響範囲を要約する
3. 以下のスクリプトを bash で必ず実行し、RQ-* と DS-* の突合結果（未対応・重複・不整合）を抽出する：

   python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py \
     docs/requirements.md \
     docs/detail_design.md
   

   注意: スクリプトが「問題なし」を返しても、手順4以降を必ず継続すること。本スクリプトは文書間マッピングのみを検証し、実装起因の未反映要件・change_requirements.md の適用漏れは検出しない。
4. 変更要件定義フロー時は、change_requirements.md と docs/proposals.md と実装差分の三者突合を行い、要求意図との不一致を抽出する。特に change_requirements.md で定義・変更されたRQ-IDが docs/requirements.md に反映されているかを確認すること（この確認はスクリプトでは行えない）。未反映のRQ-IDが存在する場合は、change_requirements.md に定義された内容は既確定の要件変更であるため、ユーザーへのヒアリングは不要。手順5・6をスキップし、直接 docs/requirements.md と docs/detail_design.md を更新して手順8（設計ID伝播）を実施すること。
5. 実装コード内の全関数・処理を起点に、対応する要件IDが docs/requirements.md に存在しないものを未マッピング一覧として生成する（実装→要件の逆引き確認）。スクリプト結果が「問題なし」でも本手順は省略しないこと。未マッピング一覧を生成したら、その一覧をユーザーに提示すること。
6. ユーザーの回答を受領し、更新方針（「削除」「修正」「分割」「統合」「追加」）を1件ずつ確定する
7. 起点ドキュメントへ要件更新を反映する
8. 更新後の要件IDを設計へ伝播し、再設計を実施する
9. rq_ds_link_checker.py を bash で再度実行し、未整合ゼロであることをスクリプト出力で確認する
10. レビュープロセスの完了時（正本更新の有無・追記不要の確定を問わず）、docs/proposals.md が存在する場合は必ず削除する

出力成果物

• 実装後逆引き整合レポート
• 未マッピング一覧
• 要件更新結果一覧
• 設計ID再伝播結果

完了判定（必須）

• rq_ds_link_checker.py を bash で実行し、実行ログをレスポンスに記載した
• 未整合がゼロになった
• 要件更新が必要な場合、要件ヒアリング更新を1件ずつ完了した
• 要件ID再整理の結果を設計へ伝播した
• 再整合チェックで問題なしを確認した
• docs/proposals.md が削除済みである
• 変更要件定義フロー時は change_requirements.md との整合を確認した

セルフレビュー（必須）

1. 要件更新先が起点ドキュメントに正しく反映されているか
2. 更新方針（削除、修正、分割、統合、追加）が各要件で明確か
3. 要件IDと設計IDの伝播結果に欠落がないか
4. 実装差分が要件と設計へ過不足なく反映されているか
5. docs/proposals.md の残置がないか
6. 変更要件定義フロー時に change_requirements.md の要求意図と正本更新結果が矛盾していないか

---

次のステップ

完了を報告する際に、整合状態に応じて次のアクションをユーザーに案内する。

未整合が残っている場合

• 新規開発フロー中の場合: isdd-design を実行して設計を更新する
• 変更開発フロー中の場合: isdd-change-design を実行して変更設計を更新する

未整合がゼロになった場合（プロジェクト完了）

以下の内容を含む完了報告をユーザーに行い、成果物の利用方法を案内する。

確定した成果物の案内:

• docs/requirements.md — 確定要件定義書。業務課題と要件がRQ-*IDで管理されており、次回の変更要件定義の起点となる
• docs/detail_design.md — 確定詳細設計書。全設計要素にDS-*IDが付与されており、要件との対応が追跡可能
• 実装ソースファイル — 要件ID: / 設計ID: コメントにより仕様とコードが1対1で対応づけられている
• e2e/ — 実装を検証するE2Eテスト。docker-compose でmock/realの両モードで実行できる

今後の開発サイクルの案内:

• 新たな要求が発生した場合は isdd-change-req から開始する
• 既存の実装にバグや仕様誤りが見つかった場合は docs/requirements.md を直接修正し、isdd-design で設計を更新してから isdd-traceable-coding で修正する