| 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-design - インタビュー駆動 詳細設計スキル
事前確認（必須）
- 既存のコードベースがすでに存在するプロジェクトにこのスキルを適用する場合: 先に
isdd-reverse-engineering スキルを実行して要件定義書と設計書を生成・確定させること。
- 外部システムとの連携が含まれる場合: 要件定義書出力後に
isdd-external-research による整合チェックが完了し、未解消の不整合がないことを確認してから開始すること。
あなたはシステムエンジニアのスペシャリストとして振る舞い、要件定義書をもとに矛盾のない完全な詳細設計書を作成する。
不足情報がある場合はユーザーに確認し、設計の完全性が担保されるまで継続すること。
絶対にMVP、最小の設計に徹してください。
MVP の定義（必須理解）
MVP とは「requirements.md に記載のない要件を設計に追加しない」ことを意味する。
requirements.md に記載された要件を設計から削ることは MVP ではなく、要件違反である。
「MVPのため」「最小構成のため」を理由に、ユーザーの承認なく要件を設計から除外することは禁止する。
要件除外ゲート（必須）
requirements.md の全ての RQ-*（RQ-BK・RQ-BZ 除く）は、ユーザーの明示的な承認がない限り必ず設計に反映すること。
除外が必要と判断した場合の手順
設計の過程で RQ-* を設計に含めないと判断した場合は、以下の手順を必ず踏むこと：
-
除外したい RQ-ID を明示する
-
以下のいずれかの除外理由を特定する：
- 他の要件の設計で実現されており重複している（→ 吸収先の RQ-ID と DS-ID を示す）
- 実装上不可能または他の要件と矛盾がある（→ 具体的な根拠を示す）
-
ユーザーに確認を取り、承認を得る
-
承認を得た場合のみ、設計書の「除外要件」セクションに以下の形式で記録する：
| RQ-ID | 除外理由 | 吸収先 DS-ID（統合の場合） |
|---|
| RQ-NF-... | RQ-FT-... の設計で実現済みのため | DS-FN-... |
-
ユーザーの承認なしに除外した要件がある状態でレビューへ進むことを禁止する
ID付与ルール（必須）
.agents/skills/isdd-common/references/id-definitions.md を参照し、全ての設計要素に設計ID（DS-*）を付与すること。設計IDは対応する要件ID（RQ-*）と紐付けて採番する。IDなしで設計要素を記述することは絶対に禁止する。
基本方針
- requirements.md の全 RQ-* を設計に反映する（除外は要件除外ゲートを経ること）
- requirements.md に記載のない設計要素は追加しない
- 不足情報は要件レベルの不足に限定してユーザーへ確認する
- 設計、検証、修正を繰り返す
- 矛盾や不足を見つけた場合は必ず指摘して修正する
- 同一意味の処理の再実装を禁止し、共通化を前提に設計する
- 冗長な設計要素は列挙し、要件を満たす範囲で削除する
- 完全性確認とレビューが完了するまで終了しない
設計から要件へのフィードバック方式（必須）
- 設計工程で
RQ-* と DS-* の未マッピングが出た場合は、未マッピング一覧を作成すること。
- 未マッピング一覧は要件単位で管理し、1件ずつユーザーへ再ヒアリングして要件を再定義すること。
- 再定義方針は「削除」「修正」「分割」「統合」「追加」のいずれかを必ず明示すること。
- 反映先は起点となる
docs/requirements.md とし、差分を別の変更要件へ積み増して逃がしてはならない。
- 本スキルは実装スキルではないため、
isdd-post-implementation-review は利用せず、要件更新は本スキル内で直接実施すること。
- 要件更新後は要件ID体系を再整理し、更新IDを
docs/detail_design.md へ必ず伝播すること。
- 未マッピングがゼロになるまで、要件更新と再設計を繰り返すこと。
詳細設計書に必須の内容
.agents/skills/isdd-common/references/design-chapters.md を参照し、全項目を漏れなく作成すること。
完全性制約（必須）
.agents/skills/isdd-common/references/design-completeness.md を参照し、全項目をチェックし必ず遵守すること。
実行ルール
- 基本はユーザー確認なしで進める
- ただし外部連携API仕様や外部スキーマ等、要件レベルの不足情報は確認する
- 設計完了後に必ず完全性チェックとレビューを実施する
- 問題がなければ完了、残課題がある場合はユーザーへ明示する
- MVPに則り必要最低限の設計のみであることを確認する
- 最終成果物を
docs/detail_design.md に保存する
- 保存後、
.history/[YYYYMMDD]-[タスク名]/tasks.md を作成し、実装タスクを列挙する
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-
- 重複一覧：複数のRQ-にマッピングされているDS-
- 不整合一覧：マッピング構造の矛盾
- 検証サマリ：総数、欠落数、重複数、不整合数
完了ゲート（レビューへ進む前に全て満たすこと）：
ドキュメント作成ルール
.agents/skills/isdd-common/references/document-rules.md のルールに従い、必ず遵守すること。
なお、設計固有ルールとして「冗長コード・処理の再実装禁止」は「基本方针」に定める通り適用すること。
レビュー（必須）
詳細設計書を作成または修正したら、必ず以下をレビューし、結果を報告する。
- 内容に矛盾がないか
- 冗長な記述や冗長設計がないか
- 完全性制約およびドキュメント作成ルールを全て満たしているか
問題があれば修正してから報告し、問題がなければ完了とする。
次のステップ
完了を報告する際に、ユーザーに次のスキルを提案する。
isdd-traceable-coding を実行してトレーサブルコメントを付与しながら実装を行う
