메뉴
要件定義書をもとに、MVPに絞った矛盾のない詳細設計書を作成する isdd 第2ステップのスキル。 「詳細設計して」「設計書を作りたい」「要件から設計に落として」「内部設計まで詰めたい」などの依頼では必ずこのスキルを使うこと。 docs/requirements.md から docs/detail_design.md を作る作業、設計の網羅性確認、冗長設計の排除、実装タスク化までを行う場面で必ず起動すること。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | isdd-design |
| description | 要件定義書をもとに、MVPに絞った矛盾のない詳細設計書を作成する isdd 第2ステップのスキル。 「詳細設計して」「設計書を作りたい」「要件から設計に落として」「内部設計まで詰めたい」などの依頼では必ずこのスキルを使うこと。 docs/requirements.md から docs/detail_design.md を作る作業、設計の網羅性確認、冗長設計の排除、実装タスク化までを行う場面で必ず起動すること。 |
| license | CC-BY-4.0 |
| metadata | {"version":"v1.0.14"} |
isdd-reverse-engineering スキルを実行して要件定義書と設計書を生成・確定させること。isdd-external-research による整合チェックが完了し、未解消の不整合がないことを確認してから開始すること。あなたはシステムエンジニアのスペシャリストとして振る舞い、要件定義書をもとに矛盾のない完全な詳細設計書を作成する。 不足情報がある場合はユーザーに確認し、設計の完全性が担保されるまで継続すること。 絶対にMVP、最小の設計に徹してください。
MVP とは「requirements.md に記載のない要件を設計に追加しない」ことを意味する。 requirements.md に記載された要件を設計から削ることは MVP ではなく、要件違反である。 「MVPのため」「最小構成のため」を理由に、ユーザーの承認なく要件を設計から除外することは禁止する。
requirements.md の全ての RQ-*（RQ-BK・RQ-BZ 除く）は、ユーザーの明示的な承認がない限り必ず設計に反映すること。
設計の過程で RQ-* を設計に含めないと判断した場合は、以下の手順を必ず踏むこと：
除外したい RQ-ID を明示する
以下のいずれかの除外理由を特定する：
ユーザーに確認を取り、承認を得る
承認を得た場合のみ、設計書の「除外要件」セクションに以下の形式で記録する：
| RQ-ID | 除外理由 | 吸収先 DS-ID（統合の場合） |
|---|---|---|
| RQ-NF-... | RQ-FT-... の設計で実現済みのため | DS-FN-... |
ユーザーの承認なしに除外した要件がある状態でレビューへ進むことを禁止する
.agents/skills/isdd-common/references/id-definitions.md を参照し、全ての設計要素に設計ID（DS-*）を付与すること。設計IDは対応する要件ID（RQ-*）と紐付けて採番する。IDなしで設計要素を記述することは絶対に禁止する。
RQ-* と DS-* の未マッピングが出た場合は、未マッピング一覧を作成すること。docs/requirements.md とし、差分を別の変更要件へ積み増して逃がしてはならない。isdd-post-implementation-review は利用せず、要件更新は本スキル内で直接実施すること。docs/detail_design.md へ必ず伝播すること。.agents/skills/isdd-common/references/design-chapters.md を参照し、全項目を漏れなく作成すること。
.agents/skills/isdd-common/references/design-completeness.md を参照し、全項目をチェックし必ず遵守すること。
docs/detail_design.md に保存する.history/[YYYYMMDD]-[タスク名]/tasks.md を作成し、実装タスクを列挙する.agents/skills/isdd-common/references/design-tasks-rules.md を参照し、全て遵守すること。
注記：isdd-design は「isdd-change-design 固有の記載」セクションは不要。
詳細設計書が完成したら、以下のスクリプトを bash で必ず実行する：
python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py \
docs/requirements.md \
docs/detail_design.md
出力:
完了ゲート（レビューへ進む前に全て満たすこと）：
rq_ds_link_checker.py を bash で実行し、実行ログをレスポンスに記載したdocs/requirements.md を更新したdocs/detail_design.md へ伝播した.agents/skills/isdd-common/references/document-rules.md のルールに従い、必ず遵守すること。
なお、設計固有ルールとして「冗長コード・処理の再実装禁止」は「基本方针」に定める通り適用すること。
詳細設計書を作成または修正したら、必ず以下をレビューし、結果を報告する。
問題があれば修正してから報告し、問題がなければ完了とする。
完了を報告する際に、ユーザーに次のスキルを提案する。
isdd-traceable-coding を実行してトレーサブルコメントを付与しながら実装を行う変更要件定義書をもとに、既存設計との整合を保った変更詳細設計書を作成する 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 などのスキルから参照される。
外部連携を含む要件定義の前に、接続可否・認証方式・主要制限のみを確認する軽量事前調査スキル。 外部調査の範囲を確定し、要件定義に進んで良いかを判定する。 「外部連携の事前確認をしたい」「要件前に連携リスクだけ見たい」などの依頼では必ずこのスキルを使うこと。
要件定義書または変更要件定義書の出力後に、外部連携システムの詳細調査を行い、要件との整合性を確認するスキル。 「要件と外部仕様の整合を確認したい」「要件出力後に連携先を調査したい」「設計前に外部連携の差分を確定したい」などの依頼では必ずこのスキルを使うこと。 isdd-requirements / isdd-change-req の後段として実行し、整合確認結果を設計に引き継ぐ。
実装完了後に、要件定義書・詳細設計書・実装コードの整合性を逆引きで検証するスキル。 未マッピング要件の一覧化、要件ヒアリング更新、要件IDの再整理、設計へのID伝播、再整合チェックまでを実施する。 「実装後に仕様整合を確認したい」「実装差分を要件と設計に反映したい」「実装後の逆引きレビューをしたい」などの依頼では必ずこのスキルを使うこと。