agentsclimarketplace

Isdd change design

Skill notfolder/isdd/skills/isdd-change-design

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

Install
npx -y skills add notfolder/isdd --skill isdd-change-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

変更要件定義書をもとに、既存設計との整合を保った変更詳細設計書を作成する isdd の変更設計スキル。 docs/requirements.md と docs/detail_design.md を理解したうえで、指定された .history 配下の change_requirements.md から change_detail_design.md を作成し、差分設計の網羅性チェックと実装タスク化まで行う。 「変更設計書を作って」「既存設計への差分設計をまとめて」「change_requirements から詳細設計を作成して」などの依頼では必ずこのスキルを使うこと。

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.3 KB, as published. Nobody here has run it

isdd-change-design - 変更詳細設計スキル

事前確認（必須）

  • 既存のコードベースがすでに存在するプロジェクトにこのスキルを適用する場合: 先に isdd-reverse-engineering スキルを実行して要件定義書と設計書を生成・確定させること。
  • 外部システムとの連携が含まれる場合: 変更要件定義書出力後に isdd-external-research による整合チェックが完了し、未解消の不整合がないことを確認してから開始すること。

あなたはシステムエンジニアのスペシャリストとして振る舞い、変更要件定義書をもとに矛盾のない完全な変更設計書を作成する。

MVP の定義（必須理解）

MVP とは「change_requirements.md に記載のない設計要素を追加しない」ことを意味する。 change_requirements.md に記載された [追加] 要件を設計から削ることは MVP ではなく、要件違反である。 「MVPのため」「最小構成のため」を理由に、ユーザーの承認なく [追加] 要件を設計から除外することは禁止する。

変更要件除外ゲート（必須）

change_requirements.md の全ての [追加] RQ-*（RQ-BK・RQ-BZ 除く）は、ユーザーの明示的な承認がない限り必ず変更設計に反映すること。

除外が必要と判断した場合の手順

設計の過程で [追加] RQ-* を設計に含めないと判断した場合は、以下の手順を必ず踏むこと：

  1. 除外したい RQ-ID を明示する

  2. 以下のいずれかの除外理由を特定する：

    • 既存設計（docs/detail_design.md）または他の [追加] 要件の設計で実現されており重複している（→ 吸収先の DS-ID を示す）
    • 実装上不可能または他の要件と矛盾がある（→ 具体的な根拠を示す）

  3. ユーザーに確認を取り、承認を得る

  4. 承認を得た場合のみ、変更設計書の「除外要件」セクションに以下の形式で記録する：

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

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

最重要制約

  • 既存の docs/detail_design.md は絶対に変更しない
  • ユーザーから変更要件定義書の指定がない場合は、対象の change_requirements.md を必ず確認する
  • 入力の変更要件定義書は .history/[YYYYMMDD]-[タスク名]/change_requirements.md を前提とする
  • 変更設計書は同ディレクトリの change_detail_design.md として保存する

ID付与ルール（必須）

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

基本方針

  • 作業前に docs/requirements.md と docs/detail_design.md を読んで既存仕様を理解する
  • 差分（追加・削除）を既存設計との差分として整理し、変更のないセクションは既存設計参照として明記する
  • 削除する要素は必ず削除理由を記載する
  • 不足情報があれば要件レベル不足のみユーザーに確認する
  • 設計、検証、修正を繰り返し、完全性が担保されるまで継続する
  • change_requirements.md の全 [追加] RQ-* を変更設計に反映する（除外は変更要件除外ゲートを経ること）
  • change_requirements.md に記載のない設計要素は追加しない
  • 同じ意味の処理の再実装を禁止し、共通化方針を明記する

設計から要件へのフィードバック方式（必須）

  • 変更設計工程で RQ-* と DS-* の未マッピングが出た場合は、未マッピング一覧を作成すること。
  • 未マッピング一覧は要件単位で管理し、1件ずつユーザーへ再ヒアリングして変更要件を再定義すること。
  • 再定義方針は「削除」「修正」「分割」「統合」「追加」のいずれかを必ず明示すること。
  • 反映先は起点となる .history/[YYYYMMDD]-[タスク名]/change_requirements.md とし、差分を次の新しい変更要件として積み増してはならない。
  • 本スキルは実装スキルではないため、isdd-post-implementation-review は利用せず、変更要件更新は本スキル内で直接実施すること。
  • 要件更新後は要件ID体系を再整理し、更新IDを change_detail_design.md へ必ず伝播すること。
  • 未マッピングがゼロになるまで、変更要件更新と再設計を繰り返すこと。

変更設計書に必須の内容

.agents/skills/isdd-common/references/design-chapters.md を参照し、以下の変更固有ルールを適用すること。

変更固有ルール

  • 全ての設計要素に「[追加]」または「[削除]」のどちらかを必ず明記すること
  • 「変更」という区分は使わない。変更が必要な場合は旧設計要素を「[削除]」、新設計要素を「[追加]」として分解して記述する
  • CRUDテーブルは変更内容にかかわらず全エンティティ分を必ず記載すること（省略不可）
  • 削除要素は削除理由を必ず明記する
  • 変更がないセクションは「変更なし。既存設計 docs/detail_design.md セクション[N] を参照」と明記するだけでよい

完全性制約（必須）

.agents/skills/isdd-common/references/design-completeness.md を参照し、全項目をチェックし必ず遵守する。残余タスクを確認し、既存設計書との整合性を検証する。

実行ルール

  • 設計、検証、修正を繰り返す
  • 矛盾、不足は必ず指摘する
  • 基本はユーザー確認なしで進める
  • 外部連携先API仕様、外部スキーマなど要件不足は確認する
  • 完全性確認後にレビューし、問題がなければ完了とする
  • 完了時に .history/[YYYYMMDD]-[タスク名]/change_detail_design.md を保存する
  • 保存後に .history/[YYYYMMDD]-[タスク名]/tasks.md を作成し、実装タスクを列挙する

tasks.md 作成ルール

.agents/skills/isdd-common/references/design-tasks-rules.md を参照し全て遵守する。加えて、以下を必ず tasks.md の最後に記載する：

  • 設計中に change_requirements.md を直接更新した場合、更新した要件IDと更新理由を tasks.md に明記し、change_detail_design.md へのID伝播完了を確認するタスク を明記する

ドキュメント作成ルール

.agents/skills/isdd-common/references/document-rules.md のルールに従い、必ず遵守すること。

レビュー（必須）

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

  1. 内容に矛盾がないか
  2. 冗長な記述や冗長設計がないか
  3. 完全性制約およびドキュメント作成ルールを全て満たしているか
  4. 未マッピング要件が検出された場合、変更要件への1件ずつヒアリング反映とID伝播が完了しているか

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

次のステップ

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

  • isdd-traceable-coding を実行して変更詳細設計書にもとづく実装を行う

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.