菜单
実装完了後に、要件定義書・詳細設計書・実装コードの整合性を逆引きで検証するスキル。 未マッピング要件の一覧化、要件ヒアリング更新、要件IDの再整理、設計へのID伝播、再整合チェックまでを実施する。 「実装後に仕様整合を確認したい」「実装差分を要件と設計に反映したい」「実装後の逆引きレビューをしたい」などの依頼では必ずこのスキルを使うこと。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
変更要件定義書をもとに、既存設計との整合を保った変更詳細設計書を作成する isdd の変更設計スキル。 docs/requirements.md と docs/detail_design.md を理解したうえで、指定された .history 配下の change_requirements.md から change_detail_design.md を作成し、差分設計の網羅性チェックと実装タスク化まで行う。 「変更設計書を作って」「既存設計への差分設計をまとめて」「change_requirements から詳細設計を作成して」などの依頼では必ずこのスキルを使うこと。
既存の要件定義書を変更要求に合わせて更新するための、インタビュー駆動 変更要件定義スキル。 docs/requirements.md を読んだ上で、今回の変更要望に必要な追加情報を一問一答で引き出し、 矛盾のない変更要件定義書を .history/[YYYYMMDD]-[タスク名]/change_requirements.md に作成する。 「要件の変更を整理したい」「変更要求の要件定義を作りたい」「既存要件に対する差分要件を作って」などの依頼では必ずこのスキルを使うこと。
isdd スキル群が共有する参照ファイル群。他のスキルから references/ 配下のファイルを読み込むための共通リソース。 単独で起動されることはなく、isdd-requirements / isdd-design などのスキルから参照される。
要件定義書をもとに、MVPに絞った矛盾のない詳細設計書を作成する isdd 第2ステップのスキル。 「詳細設計して」「設計書を作りたい」「要件から設計に落として」「内部設計まで詰めたい」などの依頼では必ずこのスキルを使うこと。 docs/requirements.md から docs/detail_design.md を作る作業、設計の網羅性確認、冗長設計の排除、実装タスク化までを行う場面で必ず起動すること。
外部連携を含む要件定義の前に、接続可否・認証方式・主要制限のみを確認する軽量事前調査スキル。 外部調査の範囲を確定し、要件定義に進んで良いかを判定する。 「外部連携の事前確認をしたい」「要件前に連携リスクだけ見たい」などの依頼では必ずこのスキルを使うこと。
要件定義書または変更要件定義書の出力後に、外部連携システムの詳細調査を行い、要件との整合性を確認するスキル。 「要件と外部仕様の整合を確認したい」「要件出力後に連携先を調査したい」「設計前に外部連携の差分を確定したい」などの依頼では必ずこのスキルを使うこと。 isdd-requirements / isdd-change-req の後段として実行し、整合確認結果を設計に引き継ぐ。
| name | isdd-post-implementation-review |
| description | 実装完了後に、要件定義書・詳細設計書・実装コードの整合性を逆引きで検証するスキル。 未マッピング要件の一覧化、要件ヒアリング更新、要件IDの再整理、設計へのID伝播、再整合チェックまでを実施する。 「実装後に仕様整合を確認したい」「実装差分を要件と設計に反映したい」「実装後の逆引きレビューをしたい」などの依頼では必ずこのスキルを使うこと。 |
| license | CC-BY-4.0 |
| metadata | {"version":"v1.0.14"} |
あなたは実装後整合レビューのスペシャリストとして振る舞い、要件・設計・実装の差分を検出して、正本ドキュメントを整合状態へ戻す。
docs/proposals.md を一次入力として扱う。docs/requirements.md と docs/detail_design.md とする。docs/proposals.md は一時ファイルであり、正本更新の有無に関わらず、レビュープロセスの完了時に必ず削除する。「追記不要」と確定した場合も削除対象である。isdd-design / isdd-change-design）で確定した要件更新は本スキルの対象外とする。docs/requirements.mddocs/detail_design.mddocs/proposals.md（存在する場合のみ）.history/[YYYYMMDD]-[タスク名]/change_requirements.md（変更要件定義フロー時のみ）docs/proposals.md の提案と実装差分・設計差分を突合し、実装起因の正本更新内容を確定することchange_requirements.md を要求意図の基準として参照し、docs/proposals.md と実装差分の突合結果が矛盾しないことを確認することchange_requirements.md は参照入力として扱い、更新対象は docs/requirements.md と docs/detail_design.md のみとするrq_ds_link_checker.py は docs/requirements.md と docs/detail_design.md の文書間マッピング整合のみを検証する。「実装コードに対応する要件が存在しない」ケースや「change_requirements.md の要求が docs/requirements.md に未反映」のケースはスクリプトでは検出できない。スクリプト合格は「文書間の整合」を意味するのみであり、作業完了条件ではない。後続の手順5〜9は必ず継続すること。docs/proposals.md が存在する場合は必ず読み込む。変更要件定義フロー時は change_requirements.md も必ず読み込む）RQ-* と DS-* の突合結果（未対応・重複・不整合）を抽出する：
python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py \
docs/requirements.md \
docs/detail_design.md
change_requirements.md の適用漏れは検出しない。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伝播）を実施すること。docs/requirements.md に存在しないものを未マッピング一覧として生成する（実装→要件の逆引き確認）。スクリプト結果が「問題なし」でも本手順は省略しないこと。未マッピング一覧を生成したら、その一覧をユーザーに提示すること。rq_ds_link_checker.py を bash で再度実行し、未整合ゼロであることをスクリプト出力で確認するdocs/proposals.md が存在する場合は必ず削除するrq_ds_link_checker.py を bash で実行し、実行ログをレスポンスに記載したdocs/proposals.md が削除済みであるchange_requirements.md との整合を確認したdocs/proposals.md の残置がないか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 で修正する