<!-- syncToGlobal: true --> <!-- author: aktsmm --> <!-- repository: https://github.com/aktsmm/Agent-Customization --> <!-- license: CC BY-NC-SA 4.0 --> <!-- copyright: Copyright (c) 2025 aktsmm -->

code review multi angle

指定された差分、PR、選択範囲、ファイル、または現在の Git 変更を read-only でレビューする。

When to Use

• 使う: コード変更をマージ前・コミット前・PR 前にレビューしたいとき
• 使う: /review 的な不具合レビューと /security-review 的なセキュリティレビューを一度に見たいとき
• 使う: 「多角的にレビュー」「厳しめにレビュー」「重大な見落としがないか見て」と依頼されたとき
• 使う: 「レビューして修正」「fix」「直して」など、レビュー後の修正まで明示されたとき
• 使わない: 文体、ドキュメント、記事、workflow customization の構造レビュー。その場合は専用 prompt / agent / skill を使う
• 使わない: リリース前の本格 QA、プロダクト全体の反復改善、release / publish / version sync。それらは refine-product-100 を使う

Mode

• 既定は review-only: コードを編集せず、finding と修正方針だけを出す
• fix / 修正して / 直して が明示された場合だけ review-and-fix: レビュー、critic review、修正、focused validation まで行う
• destructive operation、外部反映、履歴改変、push、広範囲 refactor は fix mode でも実行前に確認する

Fix mode の分類と範囲

fix mode では、見つけた問題を 1 回のレビューで次に分類する。

• Fix now: 依頼範囲内・非破壊・ローカル検証可能・正しさを説明できるものだけ。最小差分で修正する
• Guard now: 本修正は難しいが、テスト、静的チェック、docs、確認手順のいずれか 1 つ以上でリスクを下げられるもの。その成果物を作る
• Block: 破壊的操作、外部公開、仕様判断、secret、本番データ、権限不足が絡むもの。実行せず報告する
• 安全に編集できない Fix now はレビューだけで残さず、Guard now または Block にする
• Sweep は、修正した観点と同じ原因の問題だけに横展開する（文字列・関数名・型・エラー文・設定キーで検索）。概念的に近いだけの改善や別軸の品質改善は Next Steps に回す
• 検証に失敗したら原因を読み、同一原因につき最大 2 サイクルまで修正と再検証を行う。それ以上は Block として残す
• 学びは Learnings Candidate として候補を提示するだけにする。instruction や review-learnings ファイルへの反映は、ユーザーが明示した場合だけ行う

Scope Detection

優先順でレビュー対象を決める。

1. ユーザーが指定した PR URL、比較ブランチ、ファイル、選択範囲、貼り付け diff
2. staged changes: git --no-pager diff --staged
3. unstaged changes: git --no-pager diff
4. working tree が clean の場合: git --no-pager diff main...HEAD

main 以外の base branch が自然なリポジトリでは、branch 名や upstream を確認してから使う。

Review Lanes

同じ対象を少なくとも 3 つの独立した観点で見る。

1. Correctness and Regression

• 仕様・既存挙動・境界条件を壊していないか
• null / empty / missing / duplicate / out-of-order / concurrent input で破綻しないか
• public API、schema、CLI contract、output format の互換性を壊していないか
• エラー処理不足で crash、data loss、partial update が起きないか

2. Security and Trust Boundary

• injection、path traversal、SSRF、unsafe deserialization、prototype pollution がないか
• 認証・認可・権限境界・tenant / repo / workspace boundary を越えていないか
• secret、token、PII、内部 URL、stack trace をログや出力へ漏らしていないか
• untrusted input が LLM prompt、tool routing、shell command、URL、file path に混ざっていないか

3. Reliability, Operations, and Maintainability

• retry、timeout、idempotency、cleanup、rollback、resume が必要な箇所で抜けていないか
• performance impact が測定可能に悪化していないか
• build artifact、generated file、大量 diff による誤検出を避けているか
• 既存パターン・近傍実装・テスト方針から外れていないか

Noise Filter

報告してよいのは、読者が実際に直す価値のある finding だけ。Critical / High / Medium / Low に分類し、Low も根拠と修正価値があるなら出す。

報告しないもの。

• style、format、命名、好みの設計
• grammar、spelling、コメント文の軽微な改善
• 「できれば」「一般的には」レベルの best practice
• 修正しても要求成果に影響しない refactor

迷った finding は報告しない。代わりに Assumptions / Not Reviewed に短く残す。

Critic Review

非自明な変更、security finding、複数ファイル変更、または fix mode では、利用可能な rubber duck / critic 経路でレビュー結果をもう一度確認する。

• 利用可能なら native Rubber Duck、duck-critic skill、read-only subagent、別モデル critic のいずれかを使う
• critic は read-only とし、修正や状態変更を任せない
• critic の指摘は重複排除し、実際に採用したものだけ findings または fixes に反映する
• critic 経路が使えない場合は、自分で second-pass review を行い、使えなかった理由を Verification に書く

Verification

可能な範囲で、finding を出す前に read-only または低リスクの確認を行う。

• 周辺コード、既存テスト、call site、schema、README、設定を確認する
• 必要なら compile / typecheck / lint / focused test を実行する
• 実行できない場合は、理由と代替確認を明記する
• review-only ではコードを編集しない。ファイル作成・修正・削除も行わない
• fix mode では、critic review 後に最小修正を行い、focused validation を実行する

Output Format

重大度順に findings を先に出す。

## Review Findings

### 1. {短いタイトル}
- Severity: Critical | High | Medium | Low
- Lane: Correctness | Security | Reliability
- File: {path}:{line}
- Problem: {実際に起きる問題}
- Evidence: {差分、周辺コード、テスト、仕様から確認した根拠}
- Suggested Fix: {実装方針。コードは変更しない}

## No Significant Issues

{finding がない場合だけ、重大な問題が見つからなかった理由を 1 行で書く}

## Assumptions / Not Reviewed

- {未確認範囲、実行できなかった検証、前提。なければ None}

## Fixes Applied

- {fix mode の場合だけ、変更したファイルと理由。分類（Fix now / Guard now / Block）と Sweep の結果を含める。review-only では None}

## Learnings Candidate

- {永続化したい学び候補。なければ None}

## Verification

- {実行した確認、または未実行理由}

褒め、長い作業ログ、見たファイルの網羅列挙は出さない。

Completion Criteria

• 対象差分または指定範囲を特定した
• 3 つ以上の観点で確認した
• finding は actionable なものだけに絞り、Critical / High / Medium / Low に分類した
• 非自明なレビューまたは fix mode では critic review を行った、または代替 second-pass を明記した
• 可能な範囲で根拠確認または focused validation を行った
• review-only ではコードを変更していない
• fix mode では最小修正後に focused validation を行った