---
name: isdd-design
description: >
  要件定義書をもとに、MVPに絞った矛盾のない詳細設計書を作成する isdd 第2ステップのスキル。
  「詳細設計して」「設計書を作りたい」「要件から設計に落として」「内部設計まで詰めたい」などの依頼では必ずこのスキルを使うこと。
  docs/requirements.md から docs/detail_design.md を作る作業、設計の網羅性確認、冗長設計の排除、実装タスク化までを行う場面で必ず起動すること。
metadata:
  version: "1.0.10"
---

# 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-* を設計に含めないと判断した場合は、以下の手順を必ず踏むこと：

1. 除外したい RQ-ID を明示する
2. 以下のいずれかの除外理由を特定する：
   - 他の要件の設計で実現されており重複している（→ 吸収先の RQ-ID と DS-ID を示す）
   - 実装上不可能または他の要件と矛盾がある（→ 具体的な根拠を示す）
3. ユーザーに確認を取り、承認を得る
4. 承認を得た場合のみ、設計書の「除外要件」セクションに以下の形式で記録する：

   | RQ-ID | 除外理由 | 吸収先 DS-ID（統合の場合） |
   |---|---|---|
   | RQ-NF-... | RQ-FT-... の設計で実現済みのため | DS-FN-... |

5. ユーザーの承認なしに除外した要件がある状態でレビューへ進むことを禁止する

## ID付与ルール（必須）

`isdd-common/references/id-definitions.md` を参照し、全ての設計要素に設計ID（`DS-*`）を付与すること。設計IDは対応する要件ID（`RQ-*`）と紐付けて採番する。IDなしで設計要素を記述することは絶対に禁止する。

## 基本方針

- requirements.md の全 RQ-* を設計に反映する（除外は要件除外ゲートを経ること）
- requirements.md に記載のない設計要素は追加しない
- 不足情報は要件レベルの不足に限定してユーザーへ確認する
- 設計、検証、修正を繰り返す
- 矛盾や不足を見つけた場合は必ず指摘して修正する
- 同一意味の処理の再実装を禁止し、共通化を前提に設計する
- 冗長な設計要素は列挙し、要件を満たす範囲で削除する
- 完全性確認とレビューが完了するまで終了しない

---

## 詳細設計書に必須の内容

`isdd-common/references/design-chapters.md` を参照し、全項目を漏れなく作成すること。

---

## 完全性制約（必須）

`isdd-common/references/design-completeness.md` を参照し、全項目をチェックし必ず遵守すること。

---

## 実行ルール

- 基本はユーザー確認なしで進める
- ただし外部連携API仕様や外部スキーマ等、要件レベルの不足情報は確認する
- 設計完了後に必ず完全性チェックとレビューを実施する
- 問題がなければ完了、残課題がある場合はユーザーへ明示する
- MVPに則り必要最低限の設計のみであることを確認する
- 最終成果物を `docs/detail_design.md` に保存する
- 保存後、`.history/[YYYYMMDD]-[タスク名]/tasks.md` を作成し、実装タスクを列挙する

## tasks.md 作成ルール

`isdd-common/references/design-tasks-rules.md` を参照し、全て遵守すること。
**注記**：isdd-design は「isdd-change-design 固有の記載」セクションは不要。

---

## 整合性チェック（必須実行）

詳細設計書が完成したら、以下のスクリプトを **bash で必ず実行する**：

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

**出力**:
- 対応欠落一覧：マッピングされていないRQ-*/DS-*
- 重複一覧：複数のRQ-*にマッピングされているDS-*
- 不整合一覧：マッピング構造の矛盾
- 検証サマリ：総数、欠落数、重複数、不整合数

**完了ゲート（レビューへ進む前に全て満たすこと）**：

- [ ] `rq_ds_link_checker.py` を bash で実行し、実行ログをレスポンスに記載した
- [ ] 問題が検出された場合は設計書を修正して再実行し、欠落・重複・不整合が0件になった
- [ ] 問題なしを確認してからレビューへ進む

## ドキュメント作成ルール

`isdd-common/references/document-rules.md` のルールに従い、必ず遵守すること。
なお、設計固有ルールとして「冗長コード・処理の再実装禁止」は「基本方针」に定める通り適用すること。

---

## レビュー（必須）

詳細設計書を作成または修正したら、必ず以下をレビューし、結果を報告する。

1. 内容に矛盾がないか
2. 冗長な記述や冗長設計がないか
3. 完全性制約およびドキュメント作成ルールを全て満たしているか

問題があれば修正してから報告し、問題がなければ完了とする。