コードベース包括的レビュー

概要

コードベース全体を6つの観点から並列でレビューし、発見した問題点を優先度付きのissueファイルとして記録する。

本スキルの起動は、それ自体が「6観点の並列委譲によるレビュー」の実行依頼である。

トリガー条件

• ユーザーが /codebase-review を実行した場合
• コードベース全体のチェック・監査を依頼された場合
• リリース前の品質確認を依頼された場合

レビュー観点

観点	略語	説明
Performance	perf	N+1、不要な再レンダリング、重い処理等
Security	sec	脆弱性、認証・認可、入力検証等
Test	test	テストカバレッジ、テストケース不足
Architecture	arch	責務分割、依存関係、設計パターン
Code Quality	cq	命名、一貫性、可読性、不要コード
Documentation	docs	ドキュメント不足、内容の陳腐化

優先度定義

優先度	略称	説明	対応期限
critical	crit	即座に対応必須（本番障害、重大脆弱性）	即時
major	maj	早期対応推奨（バグ、セキュリティリスク）	次リリースまで
minor	min	改善推奨（設計改善、技術的負債）	計画的に対応
trivial	triv	余裕があれば対応（軽微な改善）	任意

※ アルファベット順でソートすると正しい優先度順になる

実行手順

Phase 0: 準備

1. ディレクトリの確認・作成

# PJ CLAUDE.mdのMEMORY_DIRを確認（未定義なら.local/）
# システムプロンプトのToday's dateから日付を取得（例示をコピーしない）
mkdir -p ${MEMORY_DIR}/memory/YYMMDD_codebase-review
mkdir -p ${MEMORY_DIR}/issues

2. 05_log.mdを初期化

3. PJのCLAUDE.mdとcontext/を確認し、アーキテクチャルールを把握

4. コードベース構造の把握

# ディレクトリ構造を取得
find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' | head -100

# 主要ファイルタイプの分布を確認
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.md" \) \
  -not -path '*/node_modules/*' | wc -l

Phase 1: 6観点の並列委譲

各観点の担当はissueファイルと観点サマリを自分で書くため、herdr paneへ委譲する。経路の選択・モデルの選択・起動と結果の回収・失敗時の調査は @context/herdr-delegation.mdが真実源（本スキルには複写しない）。Herdr外の環境では同ファイルのフォールバック規定に従い、Claude Codeでは subagent_type=general-purpose で代替する（Exploreはファイル書き込み不可でissueファイルを作成できないため）。並列機構が無い環境（Codex等）では、6観点を同一テンプレートで逐次実行して代替する。

指示書の組み立て（観点ごとに1ファイル）:

1. references/subagent-prompts.md をReadし、指示書テンプレート（タスク1〜5）を取得する
2. references/review-aspects.md をReadし、各観点の詳細指示・優先度基準を取得する
3. テンプレートの ## あなたの担当観点 に該当観点の内容を挿入し、{...} を実値で埋めて、6観点分の指示書を <メモリディレクトリ>/task-<観点略語>.md に書き出す
4. 指示書に埋める情報: メモリディレクトリの絶対パス / PJ CLAUDE.mdの内容 / 対象リポジトリの絶対パス / 担当観点とレビュー基準 / Phase 0で取得したコードベース構造 / references/subagent-prompts.md の絶対パス（成果物の形式を委譲先に読ませるため）
5. パスはすべて絶対パスで埋める（委譲先はleadの会話履歴を共有しないため、相対パスの起点が伝わらない）

起動（6並列）:

• --kind claude を全観点に使う（外部CLIレビューは担当の内部でタスク3として呼ばれるため、pane側でkindを分けない）
• --out には観点サマリ <メモリディレクトリ>/aspect-<観点略語>.md を指定する（issueは0件になり得るので、完了判定に使えるのは観点サマリだけ）
• 指示書・観点サマリ・state・結果JSON・ログの保存先は観点ごとに分ける

タスク1〜5はすべて必須。--skip-multimodel が明示指定されない限りタスク3（agent cli並行レビュー）を省略しない（マルチモデル検証を欠くと検出の信頼度が下がるため）。観点別の詳細指示のみを渡すのは不十分で、テンプレート全体を渡すこと。

Phase 2: 結果の集約

委譲先の完了後:

1. 6観点の観点サマリを読み、担当観点・確認した範囲・issue件数を把握する

ls -la ${MEMORY_DIR}/memory/YYMMDD_codebase-review/aspect-*.md

観点サマリが無い観点は未完了として扱う（結果JSONの status とpaneを確認する。失敗時の調査手順は @context/herdr-delegation.md）。

2. issuesディレクトリのファイルを集計

ls -la ${MEMORY_DIR}/issues/

3. 観点サマリの件数と実際のissueファイル数を突き合わせる（食い違いは書き漏れか、観点間の重複を統合した痕跡のどちらか。どちらかを確認してからサマリーに反映する）

4. マルチモデル検証の統計を集計（各issueファイルから）

5. サマリーファイルを作成

Phase 3: サマリー作成

# コードベースレビュー サマリー

## 実行日時
YYYY-MM-DD HH:MM

## 統計

| 優先度 | 件数 |
|--------|------|
| critical | X    |
| major    | X    |
| minor    | X    |
| trivial  | X    |
| **合計** | **X** |

| 観点 | crit | maj | min | triv | 計 |
|------|------|-----|-----|------|-----|
| perf | X | X | X | X | X |
| sec  | X | X | X | X | X |
| test | X | X | X | X | X |
| arch | X | X | X | X | X |
| cq   | X | X | X | X | X |
| docs | X | X | X | X | X |

## マルチモデル検証結果
- 両者一致（高信頼度）: X件
- Claude Codeのみ検出: X件
- agent cliのみ検出 → 採用: X件
- 優先度差異あり: X件

## Critical Issues（要即時対応）
...

## Major Issues（要早期対応）
...

## 推奨対応順序
...

Phase 4: ユーザーへの報告

サマリーを提示し、以下を確認:

• 優先度の妥当性
• 対応の優先順位
• GitHub issueへの登録要否

ファイル構成

${MEMORY_DIR}/
├── memory/
│   └── YYMMDD_codebase-review/
│       ├── 05_log.md              # 作業ログ
│       ├── task-<観点略語>.md      # 観点ごとの指示書（leadが生成）
│       ├── aspect-<観点略語>.md    # 観点サマリ（委譲先が生成。issue 0件でも必ず1つ）
│       └── summary.md             # レビューサマリー
└── issues/                    # issueファイル（マルチモデル検証済み）
    ├── critical-*.md          # 各issueにマルチモデル検証結果を含む
    ├── major-*.md             # アルファベット順で優先度順にソート
    ├── minor-*.md
    └── trivial-*.md

オプション引数

/codebase-review [options]

--scope <path>      対象ディレクトリを限定（例: src/server）
--focus <観点>      特定の観点のみ実行（例: sec,perf）
--priority <level>  指定優先度以上のみ報告（例: major）
--github            issueをGitHubに登録
--skip-multimodel   agent cli並行レビューをスキップ（Claude Codeのみ）

進捗の追い方

6観点の進捗は、委譲の結果ファイルと05_log.mdの委譲記録で追う（起動時刻・成果物パス・完了の有無を観点ごとに1行）。

注意事項

• 委譲先は並列で起動し、各々は独立して動作する（他観点の結果を待たない）
• 問題が0件の観点でも観点サマリを必ず1つ書かせる（成果物が無いと完了判定ができないため）
• issueファイルのタイトルは日本語で具体的に記述する
• 同じ問題が複数観点に該当する場合、最も重要な観点で1つだけ作成する
• 優先度critは本当に即時対応が必要な場合のみ使用する
• コードベース全体を網羅的に確認する（一部だけ見て終わらせると担当観点の問題を見落とすため）
• 問題発見時はcontext7/WebSearchでベストプラクティスを調査する（推測での改善案を避けるため）
• agent cli呼び出しは --skip-multimodel が明示指定されない限り実行する（マルチモデル検証を欠くと検出の信頼度が下がるため）
• 指示書にはタスク1〜5すべてを含むテンプレート全体を渡す（観点別の詳細指示のみでは網羅性・検証が不足するため）