ドキュメントレビュー＆加筆修正スキル

指定された章のドキュメント（index.md）を包括的にレビューし、問題があれば加筆・修正を行う。

手順

Step 1: 対象ファイルの特定

•
$ARGUMENTS から章番号またはドキュメントパスを判定する
- •chapter3 や 3 → packages/@ai-suburi/docs/docs/chapter3/index.md
- •フルパスが渡された場合はそのまま使用
•対応するソースコードディレクトリを特定する（例: packages/@ai-suburi/core/chapter3/）

Step 2: ソースコードとドキュメントの読み込み

•ドキュメントファイル（index.md）を読み込む
•対応するソースコードディレクトリ内の全 .ts ファイルを Glob で列挙する
•各ソースコードファイルを読み込む

Step 3: コードブロックの差分チェック

ドキュメント内のコードブロックと実際のソースコードを行単位で比較し、以下を確認する:

•インポート文の変更
•関数名・変数名の変更
•ロジックの追加・削除・修正
•コメントの変更

差分があった場合: ドキュメント側のコードブロックを最新のソースコードで置き換える。

Step 4: ドキュメント構成の整合性チェック

以下の項目を確認し、不整合があれば修正する:

4-1. 概要テーブルの整合性

| セクション | 内容 | テーブルに、実際に存在するセクション見出しがすべて含まれているか確認する。

•不足しているセクションがあれば行を追加する
•セクション番号順に並んでいることを確認する
•内容の記述が実際のセクション見出しと対応しているか確認する

4-2.「この章で学ぶこと」の整合性

:::note この章で学ぶこと ブロック内の箇条書きが、実際のセクション内容を網羅しているか確認する。

•不足している項目があれば追加する
•既存項目の記述が実態と合っているか確認する

4-3. 前提条件の整合性

:::info 前提条件 ブロックに、ソースコードが依存する環境変数やセットアップが正しく記載されているか確認する。

•ソースコード内の process.env.* を Grep で検索し、記載漏れがないか確認する

4-4. セクション見出しの一意性

Markdown lint ルール（MD024）に違反する重複見出しがないか確認する。

4-5. 未ドキュメントのソースファイル

ソースコードディレクトリに存在するが、ドキュメントにセクションがないファイルを検出する。 → 検出した場合はユーザーに報告し、追記が必要か確認する。

Step 5: 内容の品質チェック

各セクションの説明文について以下を確認する:

•概要説明 が存在し、APIやライブラリの役割を簡潔に説明しているか
•サンプルの説明（「このサンプルでは以下を行います」）がコードの実装内容と合っているか
•実行方法 のコマンドが正しいか（ファイル名が実際のソースファイル名と一致しているか）
•tip / note / caution などのアドモニションの内容が正確か
•参考文献のリンクが有効か（URLの形式チェックのみ）

Step 6: 修正の適用

発見した問題をすべて Edit ツールで修正する。修正内容は以下のカテゴリ別にまとめて報告する:

•コード差分修正: ソースコードとドキュメントの不一致を修正
•構成修正: テーブル・箇条書き・前提条件の追加・修正
•内容修正: 説明文の加筆・修正

修正時のルール

•既存の文体・トーンを維持する（技術ドキュメントとしてのフォーマルな記述）
•セクションの構成パターン（見出し→概要→詳細→コード→実行方法）を崩さない
•コードブロックの title 属性は chapter<N>/<ファイル名>.ts の形式を維持する
•不確実な修正は行わず、ユーザーに確認を取る
•参考文献セクションの順序は、セクション番号順に並べる

出力

レビュー完了後、以下の形式でサマリーを出力する:

code

## レビュー結果サマリー

### 修正した項目
- [ 修正内容1 ]
- [ 修正内容2 ]
- ...

### 問題なしの項目
- コードブロック: ✅ / ⚠️
- 概要テーブル: ✅ / ⚠️
- 学ぶことリスト: ✅ / ⚠️
- 前提条件: ✅ / ⚠️
- 見出し一意性: ✅ / ⚠️
- セクション網羅性: ✅ / ⚠️

### ユーザーへの確認事項（ある場合）
- [ 確認事項 ]