| name | code-reading |
| description | コードリーディングを3層フレームワーク（取得・処理・管理）で効率的に実行する。
コードの理解、調査、学習を求められた時に使用。複雑なケースではサブエージェント起動を推奨。
|
Code Reading Expert
核心原則: 実装をむやみに精読しない。インターフェイスと役割の理解に集中し、読む箇所を極小化する。
判断基準: スキル vs サブエージェント
IF 単純なケース（以下すべて該当）:
├─ 対象ファイル: 1-3個
├─ ゴール: 明確（特定の関数の動作確認など）
├─ 依存関係: 浅い
└─ → スキル内で完結（下記フローに従う）
IF 複雑なケース（以下いずれか該当）:
├─ 対象: 複数モジュール跨ぎ
├─ ゴール: 探索的（「どう動いているか全体像を把握」など）
├─ 依存関係: 深い・不明
└─ → サブエージェント（explore）を起動
3層フレームワーク
┌─────────────────────────────────────────────────────────┐
│ Layer 1: 取得 (Acquisition) │
│ → どの情報を、どの順序で読むか │
├─────────────────────────────────────────────────────────┤
│ Layer 2: 処理 (Processing) │
│ → 読んだ情報をどう解釈・判断するか │
├─────────────────────────────────────────────────────────┤
│ Layer 3: 管理 (Management) │
│ → 理解した情報をどう記録・参照可能にするか │
└─────────────────────────────────────────────────────────┘
クイックフロー（単純なケース）
Step 1: ゴール定義
Q: 何を達成したいか？
├─ バグ修正 → 問題箇所の特定と原因理解
├─ 機能追加 → 拡張ポイントと依存関係の把握
├─ レビュー → 設計意図と実装品質の評価
├─ 学習 → パターンと設計思想の吸収
└─ 調査 → 特定の振る舞いの確認
出力: 1文でゴールを明文化（例: 「認証フローでトークン検証がどこで行われるかを特定する」）
Step 2: 境界設定
- エントリーポイントを1つ特定
- 直接依存のみを対象範囲に含める
- 必要になったら拡張（前倒しで広げない）
Step 3: 情報取得（優先順位順）
| 優先度 | 対象 | 目的 |
|---|
| 1 | ファイル名・ディレクトリ構造 | 責務の推測 |
| 2 | 型定義・インターフェース | 契約の把握 |
| 3 | 公開API（export）の関数シグネチャ | 入出力の確認 |
| 4 | ドキュメント・コメント | 意図の理解 |
| 5 | テストコード | 期待される振る舞いの確認 |
| 6 | 実装の詳細 | 最後に、必要な箇所のみ |
Step 4: 理解の記録
understanding-record.md のテンプレートを使用
サブエージェント起動テンプレート
複雑なケースでは以下のプロンプトで explore サブエージェントを起動:
【ゴール】
{1文で明文化したゴール}
【対象範囲】
{ディレクトリパスまたはファイルパターン}
【探索の深さ】
{quick / medium / very thorough}
【期待する出力】
- 理解記録テンプレート形式で各モジュールを要約
- 依存関係図（テキストまたはMermaid）
- 発見した重要なパターンやハマりポイント
詳細参照
アンチパターン（避けるべき）
| パターン | 問題 | 対策 |
|---|
| 端から端まで精読 | 目的喪失、時間切れ | ゴール定義を最初に |
| 実装から設計を逆推理 | 非効率、誤解リスク | インターフェイスから入る |
| 図を描かず記憶で管理 | 認知負荷の肥大化 | 必ず可視化する |
