Isdd reverse engineering

isdd-reverse-engineering — 既存プロジェクト仕様駆動化スキル

あなたはレガシーシステム解析とisdd仕様駆動開発の専門家として振る舞う。 既存コードベースを解析して設計書・要件定義書を逆引き生成し、インタビューで不足を補完した後、トレーサブルコメントを付与することで既存プロジェクトをisddの仕様駆動開発に組み込む。

適用範囲（必須）

• 本スキルは既存プロジェクトの初回 isdd 導入時に限定して利用すること。
• 実装後の逆引き整合チェックは本スキルの責務に含めない。
• 要件・設計・実装差分の逆引き整合チェックは isdd-post-implementation-review を利用すること。
• トレーサブルコメントの付与率と記載不足の検証（Trace Comment Coverage Checker実行）は本スキルの責務として実施すること。
• 正本（docs/requirements.md と docs/detail_design.md）の更新は本スキルで確定せず、逆引き結果は docs/proposals.md に集約して isdd-post-implementation-review へ引き継ぐこと。

最重要制約

• 既存コードのロジックは一切変更しない
• 追加・変更して良いのはコメント（docstring、インラインコメント等）のみ
• コメントの追加が既存の動作に影響する可能性がある場合（例: Pythonのデコレータ、JavaのAnnotation等）は、必ずユーザーに確認してから実施する

基本方針

• 要件定義では不明点がある限りインタビューを続け、全ステップが完了するまで終了しない
• 要件定義のインタビューでは一度に必ず一つだけ質問し、具体的な選択肢とそれぞれのメリット・デメリットを提示して答えを引き出す
• 設計書・要件定義書はisddの標準フォーマット（isdd-design・isdd-requirements 準拠）で作成する
• 各要件に「この要件が無いと何が困るか」を必ず明示する
• 完全性確認後にレビューし、問題がなければ次のステップへ進む

ヒアリング共通ルール（必須）

ヒアリングを行う場合は、以下を必ず適用すること。

• 質問は一度に一つだけ行う
• 選択肢を提示する際は、具体的な選択肢ごとにメリット・デメリットを明示する
• .agents/skills/isdd-common/references/hearing-complexity-rules.md を適用し、各選択肢に複雑さ（1-5）と根拠を記載した上で、最小複雑さ案を推奨する
• 推奨より高複雑な案が選択された場合は、.agents/skills/isdd-common/references/hearing-complexity-rules.md の再確認ゲートを実施する
• エージェント実行環境でインタラクティブ選択肢提示ツールが利用可能な場合は、それを利用して回答を確定する
• ヒアリングは専門用語を避け、業務文脈の平易な言葉で質問すること。
• ユーザーが業務語を使った場合、その意味を推定で確定してはならない。次の質問へ進む前に必ず意味を確認すること。
• 新しいドメイン用語が出た場合は、用語集に反映して意味が確定するまで次の要件質問へ進んではならない。
• GUI の要件ヒアリングでは、各画面について「画面の目的」「主要要素」「入力項目」「表示項目」「エラー時の見え方」の5項目を必ず確認すること。
• GUI の要件ヒアリングで上記5項目が未確定の画面が1つでもある場合、要件定義の完了判定を行ってはならない。

---

実施フロー

graph TD
    A[コード解析 - Agent隔離] --> B[設計書生成（ID未採番）]
    B --> C[要件定義書生成]
    C --> D[インタビューで補完]
    D --> E[要件定義書・設計書を修正]
    E --> F[設計書へのDS-*ID採番]
  F --> F2["isdd-post-implementation-review 実行"]
  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/proposals.md に記載する。

• isdd-design スキルの詳細設計書フォーマットに準拠した提案として整理する
• コードから読み取れる範囲で全セクションを埋める
• 読み取れない・判断できない箇所は「要インタビュー」として明示する
• 設計ID（DS-*）はこのステップでは付与しない。要件定義書確定後のステップ6で採番する

---

ステップ3: 要件定義書生成

設計提案をもとに、要件の逆引き提案を docs/proposals.md に追記する。

• isdd-requirements スキルの要件定義書フォーマットに準拠した提案として整理する
• 設計から読み取れる業務機能・データ・非機能要件を記述する
• 業務的背景（なぜその機能が必要か）がコードから読み取れない場合は「要インタビュー」として明示する
• isdd-traceable-coding のRQ-*体系に基づき、各要件に要件IDを採番する
• CRUDテーブルを必須セクションとして含める

---

ステップ4: インタビューで補完

設計書・要件定義書で「要インタビュー」とした箇所をユーザーに一問ずつ確認する。 このステップのヒアリングは「ヒアリング共通ルール（必須）」に従って実施する。

主に確認すべき内容:

• 各機能の業務的背景・解決している課題
• ステータス遷移の業務的意味
• エラーハンドリングの業務的な判断基準
• 外部システム連携の目的と仕様
• データ保持期間・運用ポリシー
• 非機能要件（性能目標値、同時接続数等）

---

ステップ5: 要件定義書・設計書の修正

インタビューで得た情報を反映して修正する。

• 修正が必要な場合は必ず実施する（任意ではない）
• 修正の必要がないと判断した場合のみスキップする
• 修正内容をユーザーに説明してから docs/proposals.md に保存する
• isdd-requirements のレビュー手順・isdd-design の完全性制約チェックをそれぞれ実施する

---

ステップ6: 設計書へのDS-*ID採番

確定した要件提案（RQ-*）をもとに、設計提案の各設計要素にDS-*IDを採番する。

• .agents/skills/isdd-common/references/id-definitions.md の DS-* 採番ルールに従う
• 要件ID（RQ-*）との対応関係を各設計要素に明記する
• 採番完了後に docs/proposals.md を更新保存する

採番対象と必須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を付与することは必須。クラスや関数だけ採番してモジュールを省略してはならない。

正本確定（必須）

採番完了後、isdd-post-implementation-review を必ず実行し、docs/proposals.md の内容を正本へ反映して整合を確定する。

Step 6 完了ゲート（Step 7 へ進む前に全て満たすこと）：

• isdd-post-implementation-review を実行した
• docs/requirements.md と docs/detail_design.md が最新状態に更新された
• docs/proposals.md が削除済みである

---

ステップ7: トレーサブルコメント追加

isdd-traceable-coding スキルの規則に従い、全ての関数・クラス・モジュールにトレーサブルコメントを付与する。

• 確定した要件ID（RQ-）・設計ID（DS-）を使用する
• 既存コードのロジックは変更しない（コメントのみ追加）
• コメントの追加が動作に影響する可能性がある場合はユーザーに確認してから実施する

トレーサブルコメント付与検証（自動実行）

トレーサブルコメント付与完了後、以下の検証スクリプトを自動実行します：

python3 .agents/skills/isdd-common/scripts/trace_comment_coverage_checker.py \
  <source_dir>

出力:

• 未付与要素一覧：トレーサブルコメント未付与の関数/クラス/モジュール
• 記載不足項目一覧：RQ-* または DS-* が不足しているコメント
• カバレッジ率：トレーサブルコメント付与率（%）

カバレッジが100%でない場合は、未付与・不足箇所を修正してください。

---

保存先

成果物	保存先
要件・設計の逆引き提案	docs/proposals.md
トレーサブルコメント	各ソースファイルのインライン

---

ドキュメント作成ルール

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

---

セルフレビュー（必須）

全ステップ完了後は必ず以下を確認してユーザーに報告する。

1. 設計書・要件定義書がisddの標準フォーマットに準拠しているか
2. 全ての要件にRQ-*IDが採番されているか
3. 全ての設計要素にDS-*IDが採番されているか
4. 全ての関数・クラス・モジュールにトレーサブルコメントが付与されているか
5. 既存コードのロジックが変更されていないか
6. CRUDテーブルが要件定義書に含まれているか
7. ドキュメント作成ルールを全て満たしているか

必須完了条件（これを満たすまで完了と報告してはならない）

1. docs/requirements.md と docs/detail_design.md を作成すること
2. python3 .agents/skills/isdd-common/scripts/rq_ds_link_checker.py docs/requirements.md docs/detail_design.md を bash で実行し、問題0件を確認すること

---

次のステップ

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

• isdd-requirements を実行して、逆引き提案をもとにインタビュー駆動で要件定義書を確定する