Isdd design

isdd（Interview-driven Spec-driven Development）はインタビュー駆動で仕様を確定して、要件・設計・ソースをIDで一貫追跡しながら、開発を進める手法です。

Install

npx -y skills add notfolder/isdd --skill isdd-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

The file declares its own license as CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

8.0 KB, as published. Nobody here has run it

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-...
ユーザーの承認なしに除外した要件がある状態でレビューへ進むことを禁止する

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-
不整合一覧：マッピング構造の矛盾
検証サマリ：総数、欠落数、重複数、不整合数

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

rq_ds_link_checker.py を bash で実行し、実行ログをレスポンスに記載した
問題が検出された場合は設計書を修正して再実行し、欠落・重複・不整合が0件になった
未マッピング要件が検出された場合、要件一覧を作成し、1件ずつユーザーヒアリングして docs/requirements.md を更新した
要件更新に伴うID再整理を docs/detail_design.md へ伝播した
問題なしを確認してからレビューへ進む

ドキュメント作成ルール

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

レビュー（必須）

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

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

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

次のステップ

完了を報告する際に、ユーザーに次のスキルを提案する。

isdd-traceable-coding を実行してトレーサブルコメントを付与しながら実装を行う