メニュー
要件ID・設計IDを用いたトレーサブルなコードコメント規則を定義するスキル。 全関数・クラス・モジュールへの必須コメント内容、要件ID・設計IDのフォーマット、変更管理ポリシーを規定する。 「実装して」「トレーサブルコメントをつけて」「コードにID体系を適用して」「isddのコメントルールを適用して」などの依頼では必ずこのスキルを使うこと。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
変更要件定義書をもとに、既存設計との整合を保った変更詳細設計書を作成する 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 などのスキルから参照される。
要件定義書をもとに、MVPに絞った矛盾のない詳細設計書を作成する isdd 第2ステップのスキル。 「詳細設計して」「設計書を作りたい」「要件から設計に落として」「内部設計まで詰めたい」などの依頼では必ずこのスキルを使うこと。 docs/requirements.md から docs/detail_design.md を作る作業、設計の網羅性確認、冗長設計の排除、実装タスク化までを行う場面で必ず起動すること。
外部連携を含む要件定義の前に、接続可否・認証方式・主要制限のみを確認する軽量事前調査スキル。 外部調査の範囲を確定し、要件定義に進んで良いかを判定する。 「外部連携の事前確認をしたい」「要件前に連携リスクだけ見たい」などの依頼では必ずこのスキルを使うこと。
要件定義書または変更要件定義書の出力後に、外部連携システムの詳細調査を行い、要件との整合性を確認するスキル。 「要件と外部仕様の整合を確認したい」「要件出力後に連携先を調査したい」「設計前に外部連携の差分を確定したい」などの依頼では必ずこのスキルを使うこと。 isdd-requirements / isdd-change-req の後段として実行し、整合確認結果を設計に引き継ぐ。
| name | isdd-traceable-coding |
| description | 要件ID・設計IDを用いたトレーサブルなコードコメント規則を定義するスキル。 全関数・クラス・モジュールへの必須コメント内容、要件ID・設計IDのフォーマット、変更管理ポリシーを規定する。 「実装して」「トレーサブルコメントをつけて」「コードにID体系を適用して」「isddのコメントルールを適用して」などの依頼では必ずこのスキルを使うこと。 |
| license | CC-BY-4.0 |
| metadata | {"version":"v1.0.14"} |
あなたはisdd仕様駆動開発のトレーサビリティ専門家として振る舞う。 要件定義書・詳細設計書とソースコードを1対1で対応付けるためのID体系とコメント規則を適用する。
docs/requirements.md と docs/detail_design.md とするdocs/requirements.md と docs/detail_design.md のみとする例外なし。新規・既存問わず全て適用する。
コメントには以下を全て記載する。
| 項目 | 内容 |
|---|---|
| 一般的なドキュメントコメント | 言語に合わせた形式で記述。処理の説明や引数、戻り値など |
| 要件ID | 対応する要件ID（RQ-*） |
| 設計ID | この要素の設計ID（DS-*） |
| 要件概要 | 要件定義書の該当要件の内容を1〜3文で要約 |
| 設計概要 | 詳細設計書の該当設計の内容を1〜3文で要約 |
| 呼び出し先設計ID | この要素が呼び出す設計要素のDS-*IDの一覧 |
| 呼び出し元設計ID | この要素を呼び出す設計要素のDS-*IDの一覧（判明している範囲） |
| その他 | 変更履歴や注意点など、必要に応じて自由に記載 |
コメント内のトレーサビリティ項目は、次のラベルを絶対にそのまま使う。 必ず下記の6ラベルを全て記載すること（例外なし）。ラベル名は日本語で固定し、コロン付きで記載する。
Trace: のような独自ラベルのみで済ませてはならない。上記ラベルを必ず明記する。
Design ID、Requirement ID、Caller、Callee などの英語ラベルを使用してはならない。
ラベルは日本語で固定し、設計ID: のようにコロン付きで記載する。
以下の形式は誤りとして扱い、出力してはならない。
DS-ID: / RQ-ID: の英語ラベル# [DS-...][RQ-...] の角括弧トレース形式Traceable: / Trace: だけで要件を表現する形式要件ID や 設計ID でコロンを省略した形式必ず「要件ID:」「設計ID:」「要件概要:」「設計概要:」「呼び出し先設計ID:」「呼び出し元設計ID:」の6ラベルをそのまま記載する。
以下の3要素は、全てトレーサビリティ項目を持つコメントを必須とする。
DS-MD-* を記載するDS-CL-* を記載するDS-FN-* を記載するラベル名は省略・別名化せず、出力ラベル固定ルールの表記をそのまま使う。
コメント形式はプログラミング言語のdocstring・コメント文化に従う。
Python モジュール先頭の例:
"""
注文管理モジュール。
要件トレーサビリティ:
要件ID: RQ-FT-CREATE-ORDER
設計ID: DS-MD-ORDER-MODULE-FT-CREATE-ORDER
要件概要: ユーザーが商品を選択して注文を確定する機能を提供する。
設計概要: 注文作成・在庫引当・注文IDの発行を担うモジュール。
呼び出し先設計ID: DS-CL-ORDER-SERVICE-FT-CREATE-ORDER
呼び出し元設計ID: DS-IF-ORDER-API-FT-CREATE-ORDER
"""
Python 関数の例:
def create_order(user_id: str, items: list) -> dict:
"""
注文作成処理を実行する。
Args:
user_id (str): 注文を作成するユーザーID。
items (list): 注文対象の商品一覧。
Returns:
dict: 作成された注文情報。
要件トレーサビリティ:
要件ID: RQ-FT-CREATE-ORDER
設計ID: DS-FN-CREATE-ORDER-FT-CREATE-ORDER
要件概要: ユーザーが商品を選択して注文を確定する機能。注文確定時に在庫を引き当て、注文IDを発行する。
設計概要: 引数のユーザーIDと商品リストを受け取り、在庫確認・引当・注文レコード生成を順次実行して注文IDを返す。
呼び出し先設計ID: DS-FN-RESERVE-STOCK-FT-CREATE-ORDER, DS-SC-ORDER-RECORD-DT-ORDER
呼び出し元設計ID: DS-IF-CREATE-ORDER-API-FT-CREATE-ORDER
"""
TypeScript（JSDoc）の例:
/**
* 注文作成処理を実行する。
* @param userId 注文を作成するユーザーID
* @param items 注文対象の商品一覧
* @returns 作成された注文情報
* 要件ID: RQ-FT-CREATE-ORDER
* 設計ID: DS-FN-CREATE-ORDER-FT-CREATE-ORDER
* 要件概要: ユーザーが商品を選択して注文を確定する機能。
* 設計概要: 在庫確認・引当・注文レコード生成を順次実行して注文IDを返す。
* 呼び出し先設計ID: DS-FN-RESERVE-STOCK-FT-CREATE-ORDER
* 呼び出し元設計ID: DS-IF-CREATE-ORDER-API-FT-CREATE-ORDER
*/
docs/ への反映ルール本スキルはコードコメントのトレーサビリティ整備と検証に責務を限定する。
docs/requirements.md と docs/detail_design.md の正本更新は本スキルの責務に含めないdocs/proposals.md に提案を追記するisdd-post-implementation-review が実施し、完了時に docs/proposals.md を削除するisdd-design または isdd-change-design を呼び出して設計を修正してから実装を再開するdocs/requirements.md と docs/detail_design.md を読み込み、全要件ID・設計IDを把握するls .agents/skills/isdd-common/scripts/trace_comment_coverage_checker.py \
.agents/skills/isdd-common/scripts/rq_ds_link_checker.py
python3 .agents/skills/isdd-common/scripts/trace_comment_coverage_checker.py \
<source_dir>
python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py \
docs/requirements.md \
docs/detail_design.md
python3 .agents/skills/isdd-common/scripts/implementation_completeness_checker.py .
docker-compose.yml が見つかりません → docker-compose.yml を作成するe2e/ ディレクトリが存在しません → E2Eテストを実装し e2e/ に配置するREADME.md に不足があります → 起動方法・初期ユーザー情報を README.md に追記する以下を全て満たさない限り、完了をユーザーに報告してはならない：
trace_comment_coverage_checker.py の実行ログをレスポンスに貼り付けたrq_ds_link_checker.py の実行ログをレスポンスに貼り付けたimplementation_completeness_checker.py の実行ログをレスポンスに貼り付けた（全項目 OK であること）docker-compose.yml が存在し起動確認済みであるe2e/ 配下に存在し mock モードで全件通過しているREADME.md に「起動方法」と「初期ユーザー」が記載されている要件ID: / 設計ID: / 要件概要: / 設計概要: / 呼び出し先設計ID: / 呼び出し元設計ID:）が揃っている# [DS-...] などの角括弧形式が1件もないDesign ID: Requirement ID: などの英語ラベルが1件もない以下の全てを満たすことをこの実装スキル（isdd-traceable-coding）の完了条件とする。1つでも未達の場合は完了を報告してはならない。
trace_comment_coverage_checker.py でトレーサブルコメントのカバレッジが100%であるimplementation_completeness_checker.py の全項目（docker-compose / E2E / README）が OK である完了を報告する際に、ユーザーに次のスキルを提案する。
isdd-post-implementation-review を実行して実装後の逆引き整合チェックを行い、要件・設計・コードの正本を確定する