---
description: 明示的に呼び出されたときのみ使用します。自律的にエージェントが使用する必要はありません。
---

## 実行内容

### 1. 要件の分析

- 要件定義書 `docs/spec/{要件名}-*.md` を読み込む
- 今回の機能が「何を解決するものか」を簡潔に整理する。

### 2. 設計文書の確認

次の設計資料を確認し、コードの背景を把握する:

- `docs/design/{要件名}/architecture.md`
- `docs/design/{要件名}/database-schema.sql`
- `docs/design/{要件名}/api-endpoints.md`
- `docs/design/{要件名}/interfaces.ts`
- `docs/design/{要件名}/dataflow.md`

### 3. 実装コードの把握

- `docs/tasks/{要件名}-*.md` を確認し、対象 TASK を特定する。
- `{TASK-ID}` に紐づく実装ファイルを追跡し、コード全体の構造を理解する。

### 4. 解説文書の作成

出力ファイル:

- `docs/explan/{要件名}/{TASK-ID}-code-explan.md`
- フォルダがなければ新規作成する。

解説文書の要件:

- **必須**: クラスや関数の呼び出し関係を **mermaid 記法** で図示する。
- **必須**: 「どのファイルがどの役割を果たしているか」を明確に説明する。
- **必須**: コードを引用するまたは強く関連する解説をするとき、ディレクトリパスとファイル名を添える。
- **推奨**: コードを読めば理解できる自明なコメントもこの解説文書では付与する
- **推奨**: 指定された TASK-ID 以外で実装されたファイルや、要件定義・技術設計の解説は最低限に留める。
- **推奨**: 初学者がつまずきやすい誤解やミスを都度指摘する。
- **推奨**: 専門用語は最初に出てきた際に一度だけ簡単に説明する。
- **任意**: 比喩や実生活の例を交えてわかりやすくする。
- **禁止**: メソッド内部の処理を逐一書き出し、必要以上に詳細化。

## 文体・出力品質の指針

- 難しい言葉は避け、できるだけ「会話調に近い説明文」で書く。
- 読み手が「自分でも説明できそう」と感じる文章を目指す。
- 各セクションごとに見出しをつけて構造化する。
- 長文よりも段階的で理解の流れが追いやすい形にする。
- 「なぜこの設計や実装になっているか」という背景も補足する。
- 要件定義や技術設計ではなく、コードの説明であることを重視する。

## 出力フォーマット例
以下を参考にして作成する。

- [コード解説テンプレート](./references/EXPLAN_TEMPLATE.md)

## 参照情報
以下を読み込んでから作業する。

- [ドキュメント作成ガイドライン](../common/references/documents.md)