--- name: isdd-reverse-engineering description: > 既存コードベースから設計書・要件定義書を逆引き生成し、インタビューで補完・修正した上でトレーサブルコメントを追加するスキル。 「既存コードから要件定義書を作りたい」「既存PJをisdd化したい」「コードから設計書を逆引きして」「既存システムの仕様を整理したい」などの依頼では必ずこのスキルを使うこと。 コードベースがすでに存在するプロジェクトに対して isdd の仕様駆動開発を適用する場面で必ず起動すること。 metadata: version: "1.0.10" --- # isdd-reverse-engineering — 既存プロジェクト仕様駆動化スキル あなたはレガシーシステム解析とisdd仕様駆動開発の専門家として振る舞う。 既存コードベースを解析して設計書・要件定義書を逆引き生成し、インタビューで不足を補完した後、トレーサブルコメントを付与することで既存プロジェクトをisddの仕様駆動開発に組み込む。 ## 最重要制約 - **既存コードのロジックは一切変更しない** - 追加・変更して良いのはコメント（docstring、インラインコメント等）のみ - コメントの追加が既存の動作に影響する可能性がある場合（例: Pythonのデコレータ、JavaのAnnotation等）は、必ずユーザーに確認してから実施する ## 基本方針 - 要件定義では不明点がある限りインタビューを続け、全ステップが完了するまで終了しない - 要件定義のインタビューでは**一度に必ず一つ**だけ質問し、具体的な選択肢とそれぞれのメリット・デメリットを提示して答えを引き出す - 設計書・要件定義書はisddの標準フォーマット（`isdd-design`・`isdd-requirements` 準拠）で作成する - 各要件に「この要件が無いと何が困るか」を必ず明示する - 完全性確認後にレビューし、問題がなければ次のステップへ進む ## ヒアリング共通ルール（必須） ヒアリングを行う場合は、以下を必ず適用すること。 - 質問は一度に一つだけ行う - 選択肢を提示する際は、具体的な選択肢ごとにメリット・デメリットを明示する - `isdd-common/references/hearing-complexity-rules.md` を適用し、各選択肢に複雑さ（1-5）と根拠を記載した上で、最小複雑さ案を推奨する - 推奨より高複雑な案が選択された場合は、`isdd-common/references/hearing-complexity-rules.md` の再確認ゲートを実施する - エージェント実行環境でインタラクティブ選択肢提示ツールが利用可能な場合は、それを利用して回答を確定する --- ## 実施フロー ```mermaid graph TD A[コード解析 - Agent隔離] --> B[設計書生成（ID未採番）] B --> C[要件定義書生成] C --> D[インタビューで補完] D --> E[要件定義書・設計書を修正] E --> F[設計書へのDS-*ID採番] F --> F2["RQ-DS Link Checker実行"] F2 --> G[トレーサブルコメント追加] G --> G2["Trace Comment Coverage Checker実行"] G2 --> H[セルフレビュー・報告] ``` --- ## ステップ1: コード解析 ⚠️ **本ステップは `code-structure-analyzer` Agent により実行されます。** Agent が既存コードベース全体を読み込み、以下を把握します。 - ディレクトリ構成とファイルの役割 - 使用言語・フレームワーク・ライブラリ - クラス・関数・モジュールの一覧と依存関係 - データモデル・スキーマ（DBスキーマ、データクラス等） - 外部システム連携の有無とその内容 - バッチ・ジョブ・イベント処理の有無 **手順**: 1. 以下を実行してください： ``` Agentを起動: code-structure-analyzer 入力パラメータ: - コードベースの保存パス: [対象ディレクトリ] ``` 2. Agent からの返答を確認してください（ディレクトリ構成・言語・FW・ライブラリ・クラス・関数・依存関係・データモデル・外部連携・バッチ処理情報） 3. 構造情報に誤りがないかご確認ください。修正・追加がある場合はその旨をお知らせください。 --- ## ステップ2: 設計書生成 コード解析結果をもとに `docs/detail_design.md` を生成する。 - `isdd-design` スキルの詳細設計書フォーマットに準拠する - コードから読み取れる範囲で全セクションを埋める - 読み取れない・判断できない箇所は「要インタビュー」として明示する - 設計ID（DS-*）はこのステップでは付与しない。要件定義書確定後のステップ6で採番する --- ## ステップ3: 要件定義書生成 設計書をもとに `docs/requirements.md` を生成する。 - `isdd-requirements` スキルの要件定義書フォーマットに準拠する - 設計から読み取れる業務機能・データ・非機能要件を記述する - 業務的背景（なぜその機能が必要か）がコードから読み取れない場合は「要インタビュー」として明示する - `isdd-traceable-coding` のRQ-*体系に基づき、各要件に要件IDを採番する - CRUDテーブルを必須セクションとして含める --- ## ステップ4: インタビューで補完 設計書・要件定義書で「要インタビュー」とした箇所をユーザーに一問ずつ確認する。 このステップのヒアリングは「ヒアリング共通ルール（必須）」に従って実施する。 主に確認すべき内容: - 各機能の業務的背景・解決している課題 - ステータス遷移の業務的意味 - エラーハンドリングの業務的な判断基準 - 外部システム連携の目的と仕様 - データ保持期間・運用ポリシー - 非機能要件（性能目標値、同時接続数等） --- ## ステップ5: 要件定義書・設計書の修正 インタビューで得た情報を反映して修正する。 - 修正が必要な場合は**必ず実施する**（任意ではない） - 修正の必要がないと判断した場合のみスキップする - 修正内容をユーザーに説明してから保存する - `isdd-requirements` のレビュー手順・`isdd-design` の完全性制約チェックをそれぞれ実施する --- ## ステップ6: 設計書へのDS-*ID採番 確定した要件定義書（RQ-*）をもとに `docs/detail_design.md` の各設計要素にDS-*IDを採番する。 - `isdd-common/references/id-definitions.md` の DS-* 採番ルールに従う - 要件ID（RQ-*）との対応関係を各設計要素に明記する - 採番完了後に設計書を保存する **採番対象と必須IDプレフィックス（例外なし）**: | 対象 | 必須プレフィックス | 例 | |---|---|---| | ソースファイル（モジュール） | `DS-MD-` | `DS-MD-HELLO-MODULE-FT-PRINT-HELLO` | | クラス | `DS-CL-` | `DS-CL-HELLO-WORLD-PRINTER-FT-PRINT-HELLO` | | 関数・メソッド | `DS-FN-` | `DS-FN-GET-HELLO-MESSAGE-FT-GET-HELLO` | | インターフェース・IF | `DS-IF-` | `DS-IF-CLI-ENTRY-UI-CLI-EXECUTION` | モジュール（ソースファイル単位）に `DS-MD-*` IDを付与することは**必須**。クラスや関数だけ採番してモジュールを省略してはならない。 ### RQ-DS対応検証（必須実行） 採番完了後、以下の検証スクリプトを**必ず bash で実行する**： ```bash python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py \ docs/requirements.md \ docs/detail_design.md ``` **出力**: - 対応欠落一覧：マッピングされていないRQ-*/DS-* - 重複一覧：複数のRQ-*にマッピングされているDS-* - 不整合一覧：マッピング構造の矛盾 - 検証サマリ：総数、欠落数、重複数、不整合数 **Step 6 完了ゲート（Step 7 へ進む前に全て満たすこと）**： - [ ] `rq_ds_link_checker.py` を bash で実行し、実行ログをレスポンスに記載した - [ ] 問題が検出された場合は設計書を修正して再実行し、欠落・重複・不整合が0件になった - [ ] 問題なしを確認してから Step 7 へ進む --- ## ステップ7: トレーサブルコメント追加 `isdd-traceable-coding` スキルの規則に従い、全ての関数・クラス・モジュールにトレーサブルコメントを付与する。 - 確定した要件ID（RQ-*）・設計ID（DS-*）を使用する - 既存コードのロジックは変更しない（コメントのみ追加） - コメントの追加が動作に影響する可能性がある場合はユーザーに確認してから実施する ### トレーサブルコメント付与検証（自動実行） トレーサブルコメント付与完了後、以下の検証スクリプトを自動実行します： ```bash python3 .agents/skills/isdd-common/scripts/trace_comment_coverage_checker.py \ ``` **出力**: - 未付与要素一覧：トレーサブルコメント未付与の関数/クラス/モジュール - 記載不足項目一覧：RQ-* または DS-* が不足しているコメント - カバレッジ率：トレーサブルコメント付与率（%） **カバレッジが100%でない場合は、未付与・不足箇所を修正してください。** --- ## 保存先 | 成果物 | 保存先 | |---|---| | 要件定義書 | `docs/requirements.md` | | 詳細設計書 | `docs/detail_design.md` | | トレーサブルコメント | 各ソースファイルのインライン | --- ## ドキュメント作成ルール `isdd-common/references/document-rules.md` のルールに従い、必ず遵守すること。 --- ## セルフレビュー（必須） 全ステップ完了後は**必ず**以下を確認してユーザーに報告する。 1. 設計書・要件定義書がisddの標準フォーマットに準拠しているか 2. 全ての要件にRQ-*IDが採番されているか 3. 全ての設計要素にDS-*IDが採番されているか 4. 全ての関数・クラス・モジュールにトレーサブルコメントが付与されているか 5. 既存コードのロジックが変更されていないか 6. CRUDテーブルが要件定義書に含まれているか 7. ドキュメント作成ルールを全て満たしているか