codebase-recon

コードベース分析

証拠に基づく調査 → 調査結果 → 確信度を追跡した結論。

手順

1. 複数のソース（コード、ドキュメント、テスト、履歴）から証拠を収集する
2. 調査の進行に応じて確信度を追跡する
3. 調査結果に基づいて:
   • パターン分析が必要な場合 → outfitter:patterns スキルをロードする
   • 根本原因の調査が必要な場合 → outfitter:find-root-causes スキルをロードする
   • 報告できる状態になった場合 → outfitter:report-findings スキルをロードする
4. 確信度と注意事項を添えて調査結果を提示する

<when_to_use>

• コードベースの探索と理解
• アーキテクチャの分析とマッピング
• パターンの抽出と認識
• コード内での技術調査
• パフォーマンスまたはセキュリティの分析

対象外: 当て推量、証拠のない仮定、調査前の結論

</when_to_use>

バー	レベル	名前	アクション
░░░░░	0	収集中	初期証拠を収集する
▓░░░░	1	概観中	広範囲を走査し、表面的なパターンを把握する
▓▓░░░	2	調査中	深掘りし、パターンを検証する
▓▓▓░░	3	分析中	相互参照し、ギャップを埋める
▓▓▓▓░	4	統合中	調査結果を結びつけ、高い確信度を得る
▓▓▓▓▓	5	結論済み	調査結果を提示する

キャリブレーション: 0=0～19%、1=20～39%、2=40～59%、3=60～74%、4=75～89%、5=90～100%

正直に始めてください。明確なコードベース + 焦点を絞った問い → レベル 2～3。曖昧または複雑 → レベル 0～1。

レベル 4 の場合: 「調査結果に高い確信度があります。もう一つの角度から見れば完全な確実性に到達します。続けますか、それとも今すぐ提示しますか?」

レベル 5 未満の場合: △ 注意事項 セクションを含めてください。

中核となる方法論

仮定より証拠 — 可能なときは調査し、どうしても必要なときだけ推測する。

複数ソースからの収集 — コード、ドキュメント、テスト、履歴、ウェブ調査、実行時の動作。

複数の角度 — 結論を出す前に異なる視点から検討する。

ギャップを記録 — △ で不確実性を示し、不明な点を追跡する。

作業内容を示す — 調査結果には結論だけでなく裏付けとなる証拠を含める。

確信度を調整 — 事実、推論、仮定を区別する。

<evidence_gathering>

ソースの優先順位

1. 直接観察 — コードを読み、検索を実行し、ファイルを調べる
2. ドキュメント — 公式ドキュメント、インラインコメント、ADR
3. テスト — 意図された動作とエッジケースを明らかにする
4. 履歴 — git log、コミットメッセージ、PR の議論
5. 外部調査 — ライブラリのドキュメント、Stack Overflow、RFC
6. 推論 — 利用可能な証拠からの論理的演繹
7. 仮定 — 他のソースが利用できない場合に明確に示す

調査パターン

広く始めて、それから絞り込む:

• ファイルツリー → 関連する領域を特定する
• 検索パターン → 特定のコードを見つける
• コード構造 → 全体の内容を読まずに理解する
• 対象を絞ったファイルの読み取り → 実装を調べる
• 相互参照 → 理解を検証する

証拠を重ねる:

• コードは何をしているか?（直接観察）
• なぜこのように書かれたのか?（履歴、コメント）
• システムにどう適合するか?（アーキテクチャ、依存関係）
• エッジケースは何か?（テスト、エラー処理）

手がかりをたどる:

• 関数呼び出し → 実行パスを追跡する
• インポート/エクスポート → 依存関係をマッピングする
• テストファイル → 使用パターンを理解する
• エラーメッセージ → 前提を明らかにする
• コメント → 歴史的な背景を把握する

</evidence_gathering>

<output_format>

調査中

証拠収集の各ステップの後に以下を出力します:

• 確信度: {バー} {名前}
• 発見: { 主要な発見 }
• パターン: { 現れつつあるテーマ }
• ギャップ: { まだ不明な点 }
• 次: { 調査の方向性 }

提示時（レベル 5）

調査結果

{ 裏付けとなる証拠を添えた発見の番号付きリスト }

1. {発見} — 証拠: {ソース}
2. {発見} — 証拠: {ソース}

パターン

{ 特定された再発するテーマや構造 }

含意

{ 調査結果が目の前の問いにとって何を意味するか }

信頼度評価

全体: {BAR} {PERCENTAGE}%

信頼度が高い領域:

• {AREA} — {REASON}

信頼度が低い領域:

• {AREA} — {REASON}

裏付けとなる証拠

• コード: { ファイルパスと行範囲 }
• ドキュメント: { 参照 }
• テスト: { 関連するテストファイル }
• 履歴: { 関連する場合はコミット SHA }
• 外部: { 該当する場合は URL }

レベル 5 未満

△ 注意事項

前提:

• {ASSUMPTION} — { なぜ必要か、誤っていた場合の影響 }

ギャップ:

• {GAP} — { 何が欠けているか、どのように補うか }

不明点:

• {UNKNOWN} — { 今後の調査のために記録 }

</output_format>

<specialized_techniques>

専門的な分析のためにスキルをロードします（Steps セクションを参照）:

• パターン分析 → outfitter:patterns
• 根本原因の調査 → outfitter:find-root-causes
• リサーチの統合 → outfitter:report-findings
• アーキテクチャ分析 → architecture-analysis.md を参照

</specialized_techniques>

ループ: 収集 → 分析 → 信頼度の更新 → 次のステップ

1. 初期信頼度を調整する — すでに何がわかっていますか？
2. 証拠源を特定する — どこを調べられますか？
3. 体系的に収集する — 複数の角度から集める
4. 調査結果を相互参照する — パターンが保たれることを検証する
5. 不確実性にフラグを立てる — ギャップを △ でマークする
6. 結論を統合する — 証拠を洞察につなげる
7. 信頼度を明示して届ける — 確実性について明確にする

各ステップで:

• 見つけたことを記録する（証拠）
• それが何を意味するかをメモする（解釈）
• まだ不明な点を追跡する（ギャップ）
• 信頼度バーを更新する

結論を出す前に（レベル 4 以上）:

証拠の品質を確認する:

• ✓ 複数の情報源がパターンを裏付けていますか？
• ✓ 直接の観察と推論が明確に区別されていますか？
• ✓ 前提が明示的にフラグ立てされていますか？
• ✓ 反例が検討されていますか？

完全性を確認する:

• ✓ 元の問いに完全に答えていますか？
• ✓ エッジケースが検討されていますか？
• ✓ 別の説明が排除されていますか？
• ✓ 既知の不明点が記録されていますか？

成果物を確認する:

• ✓ 調査結果が証拠によって裏付けられていますか？
• ✓ 信頼度が誠実に調整されていますか？
• ✓ 100% 未満の場合は注意事項セクションが含まれていますか？
• ✓ 不完全な場合、次のステップが明確ですか？

必ず:

• 結論を出す前に調査する
• ファイルパスや URL を添えて証拠源を引用する
• 信頼度バーを使って確実性を追跡する
• 前提とギャップを △ でフラグ立てする
• 複数の角度から相互参照する
• 調査の記録を残す
• 事実と推論を区別する
• レベル 5 未満では注意事項を含める

決して:

• 調査できるときに推測しない
• 前提を事実として述べない
• 単一の情報源から結論を出さない
• 不確実性やギャップを隠さない
• 検証チェックを省略しない
• 信頼度評価なしで届けない
• 証拠と解釈を混同しない

中核となる方法論:

• confidence.md — 信頼度の調整（pathfinding と共有）

マイクロスキル（必要に応じてロード）:

• outfitter:patterns — パターンの抽出と検証
• outfitter:find-root-causes — 体系的な問題診断
• outfitter:report-findings — 複数ソースのリサーチ統合

ローカル参照:

• architecture-analysis.md — システム構造のマッピング

関連スキル:

• outfitter:pathfinding — 分析前の要件の明確化
• outfitter:debugging — 構造化されたバグ調査