code-review

TypeScript アプリケーションコードをレビューしてください。あなたはレビュー本体を行わず、レンズに割って並列に走らせ、返ってきた結果を統合する役です。

1体に全観点を見せると、バグ探しに使うべき注意力が規約・ポリシー照合に取られ、一番見つけたい欠陥の見落としが減りません。レンズごとに並列に走らせ、判定・severity・修正案はレンズ側に決め切らせ、あなたには手順どおりの決定・統合だけを残します。

Phase 1: 対象ファイル・判定範囲・種別・最終コミット情報を決める

まず引数を、--full の有無・--lens <レンズ名>・ファイルパスに分ける。引数 diff は、ファイルパスが無い場合と同じに扱う。

--lens を読み、起動するレンズを決める

.claude/agents/code-reviewer-agent/code-reviewer-agent.md の「レンズ一覧と担当観点（正典）」を Read する。

• --lens が無い場合：起動するレンズはレンズ一覧の全レンズ
• --lens <レンズ名> がある場合：レンズ名がレンズ一覧に無ければ「指定されたレンズ名が一覧にありません: <レンズ名>」と出力して終了する。あれば、起動するレンズはそのレンズ1つだけ

決めた「起動するレンズ一覧」を、この後の Phase 2・Phase 3 に渡す。

ファイルパスが無い場合

Bash で以下の 2 コマンドを実行する（1つ目は未コミットの変更、2つ目は未追跡の新規ファイル）:

git diff HEAD --name-only --diff-filter=ACMR
git ls-files --others --exclude-standard

2 つの結果を結合し、重複を除去する。その後フィルタリングする:

• 残す: .ts または .tsx で終わるファイル（テストファイル .test.ts / .test.tsx / .spec.ts も含める）、および .test.mjs で終わるファイル
• 除外: .config.ts / .config.js で終わるもの、infra/ を含むパス

該当ファイルが 0 件の場合は「git diff/status に対象ファイルが見つかりませんでした」と出力して終了する。

ファイルパスがある場合

そのファイルパスを直接対象とする（複数指定可）。

判定範囲を決める

対象ファイルごとに、判定範囲を 差分 か 全文 に決める。

条件	判定範囲
引数に --full がある	全文
git diff HEAD -- <パス> に出力がある、または未追跡の新規ファイル	差分
どちらでもない（パスを指定したが変更が無い）	全文

差分のファイルは、Phase 3 の手順1で引用と突き合わせるため、ここで git diff HEAD -U0 -- <パス> を1回だけ取っておく（未追跡の新規ファイルは全行が追加行）。

種別とファイル情報を決める

対象ファイルそれぞれについて、以下のルールで種別を判定する:

ディレクトリパターン	種別
.test.ts / .test.tsx / .spec.ts / .test.mjs で終わる（最優先で判定）	Test
パスに handlers/ を含む	Handler
パスに utils/ を含む	Utility
パスに pages/ を含む	Page
パスに contexts/ を含む	Context
.tsx 拡張子	Component
その他	Module

続けて各ファイルの最終コミット情報を取得する:

git log -1 --pretty=format:"%h - %an, %ar : %s" -- [ファイルパス]

対象ファイル・判定範囲・種別・最終コミット情報の組を、起動するレンズ一覧とあわせてこの後の全レンズ起動に渡す（レンズごとに決め直させない）。差分の中身はプロンプトに書き写さない——各レンズが git diff HEAD -- <パス> で自分で取る。書き写すと、その分がレンズの数だけ出力トークンになる。

Phase 2: レンズを並列起動する

code-reviewer-agent を、Phase 1 で決めた「起動するレンズ一覧」ごとに1回ずつ、1メッセージ内でまとめて Task 起動する（--lens 指定時は1回だけになる）。逐次に投げると、待ち時間がレンズの数だけ積み重なる。

各起動には次を渡す:

• レンズ名：起動するレンズ一覧のうち1つ
• 対象ファイルの一覧：Phase 1 で決めた全ファイル。各ファイルにパス・判定範囲（差分／全文）・種別・最終コミット情報を添える

レンズの一覧と担当観点は code-reviewer-agent の定義が正典です。 ここに書き写しません——2箇所に持つと、割り方を変えたときに片方が古いまま残ります。

Phase 3: 統合してレポートを出す

各レンズのレポートを1つに統合する。判断は手順4の食い違いの裁定だけにし、次の手順で行う:

1. 引用の無い指摘を落とす。判定範囲が差分のファイルでは、引用が Phase 1 で取った差分の追加行（+）・削除行（-）のどれにも無い指摘も落とす（範囲の制限をレンズの自己申告に頼らないため）
2. 同じ観点で引用が重なる指摘だけを1件にまとめる（観点が違う指摘はまとめない）
3. severity を変えない（レンズの判定を尊重する）
4. 修正案が食い違ったら裁定する：同じ箇所に別々のレンズが逆向きの修正案を出したら、ポリシーの条文（該当が無ければ docs/policy/refined-engineer-judgment-principles.md）を引用して一方を採り、捨てた修正案と根拠を添える。迷ったら AI が決める
   • 例外：どちらを採っても要件・プロダクトの方針が変わるとき、またはどちらかが取り消せない操作・外部に出る操作になるときだけは裁定しない。その食い違い1件を、.claude/skills/quick-issue/SKILL.md の書式でラベル issue:needs-human-decision を付けて gh issue create で起票し、ほかの手順は続ける。本文には、食い違った各指摘の観点名と引用を書き写す。同じワークフローの前回のレビューでこの手順により起票した Issue と同じ指摘なら、起票せず、既存の Issue 番号のまま起票済みとして扱う（手順7で引く対象にも含める）。同じ指摘かどうかは ai-review-gate-policy の「再レビューで同じ指摘が出たら、既存の Issue 番号で数える」で決める
5. 「次のステップ」の優先度は severity から機械的に決める（Critical→高・High→中・Medium→低）
6. 観点一覧の行名で穴を照合する：--lens が無ければ references/review-criteria.md の観点一覧の全行と、観点一覧の外の「プロジェクトルールへの準拠」「設定値の妥当性」を対象にする。--lens があれば、起動した1レンズの担当観点だけを対象にする。対象の観点を、どれかのレンズ（--lens があれば起動した1レンズ）の「判定した観点」と突き合わせる。判定済みとみなすのは、各レンズの「判定した観点」に名前が挙がっている観点だけ。無ければ「未判定」として観点名をそのまま報告する（これはレビュー対象の欠陥ではなく、レンズの割り方の穴。黙って埋めない）
7. 合否を判定する：ai-review-gate-policy の合格条件（残してよい例外以外の Critical が0件）で決める。対象の全ファイルを通じた Critical の合計（--lens があれば、起動した1レンズの指摘だけの合計）から、手順4で issue:needs-human-decision として起票した食い違いに含まれる Critical 指摘の件数を引き、残りが0件なら ✅ 合格、1件以上なら 🚫 要修正とする。起票した Issue 番号は「Issue にして残す Critical」に書く

指摘はファイルごとにまとめる。複数ファイルを渡した場合も、レンズをまたいで同じファイルの指摘を1箇所に集める。

出力は references/report-format.md の書式に従う。

引数: $ARGUMENTS