review

/review

ワークフロー

1. 実際の対象範囲を確認し、決して再構成しないでください。差分が提供されている場合はそれをレビューし、提供されていない場合は git diff main...HEAD、git diff --cached、git diff、git status --short を調べてください。これには、 デフォルトで追跡対象の未コミット作業が含まれます。未追跡ファイルがある場合は、含めるかどうかをユーザーに尋ね、 どの部分を確認できたかを伝えてください。
2. 実装より先に、変更されたテストと CI／設定を読みます。妥当な理由のない動作変更を伴うテストの書き換えや、 正当化できないゲートの弱体化は Blocker です。
3. リスク、影響範囲、利用可能なテスト／検証の証拠を含む、構造化されたレビューを行います。 変更されたコードに明らかな呼び出し元、依存先、公開インターフェースがある場合は、それらと関連テストの確認を推奨してください。 すべてのレビューで呼び出しグラフの徹底調査をする必要はありません。
4. 設計上の重要な判断ごとに1つ、最大5つの厳しい質問をしてください。質問するのは設計意図に限り、スタイルについては尋ねません。
5. 特定の修正について承認を得たら、修正を適用し、関連テストと lint を実行してから、そこで止めて、残る設計上または検証上の質問をユーザーに厳しく問いかけ、コミット前に明示的な承認を求めてください。

対象範囲の厳守

レビュー対象は変更箇所のみです。既存の未変更コードを指摘事項として報告してはいけません。差分が基準ですが、それだけが手掛かりではありません。変更コードの影響を把握する必要がある場合は、変更されたファイルや、明らかな呼び出し元、依存先、関連テストを確認してください。実際のリポジトリでは、これを厳守してください。

指摘事項は変更コードのみに限定してください。周辺コードは影響を把握するためにのみ使い、レビューを既存課題の一覧にしないでください。

プッシュ前のセキュリティ確認

プッシュ予定の変更については、リリース前にブランチ固有の変更を対象としたセキュリティ重視のレビューを実施してください（脆弱な依存関係については、任意で trivy fs を実行できます）。特に、ログに記録されたシークレット／トークン／PIN／PII、および信頼できない設定に対する __proto__／プロトタイプをたどる読み取りに注意してください。

エージェントが作成した差分

すべてのレビューで、テスト改ざんと CI 弱体化のチェックを実施してください。ブランチの大部分をエージェントが作成した場合、またはその疑いがある場合は、 agentic-code-review も追加で適用してください。新規または変更された AI／LLM 機能については、信頼できないプロンプト入力をすべて確認してください。特権データや操作に影響し得る場合は Blocker、それ以外は Concern です。レビューの深さは作成者ではなく影響範囲に応じて決めてください。マージをクリックする人が変更に責任を負います。

重大度の区分

ラベルではなく、実際に確認された動作に基づいて分類してください。誤った計算は Blocker です。名前の変更は、提供された差分またはコンテキストから互換性や動作が損なわれると確認できない限り、Nit です。返却値／公開インターフェースのフィールド名変更は、最大でも Concern（「旧名を使うコンシューマーを確認」）であり、呼び出し元が示されていない限り Blocker にはしないでください。実際の動作不具合より優先してはいけません。

区分	基準	必要な対応
Blocker	誤った動作、セキュリティ上の穴、データ損失、不変条件の破壊、または正当化されないゲートの弱体化	マージ前に修正
Concern	設計上の欠陥、証拠／テストの不足、またはユーザーへの実害が確認されていないパフォーマンス問題	議論し、修正を検討
Nit	スタイル、命名、軽微な重複	任意

パフォーマンスに関する指摘が可用性に影響する可能性がある一方で、その影響が不明確な場合は、区分を決める前に Blocker として扱うかどうかをユーザーに尋ねてください。

出力形式

## Review Context
- **Scope:** branch diff + staged + unstaged changes
- **Risk:** Medium
- **Blast radius:** `createInvoice()` feeds the payment record
- **Validation evidence:** no test output supplied

## Blockers
- `src/auth.ts:42` — expiry check uses `<` not `<=`; off-by-one passes expired tokens

## Concerns
- No test for error path in `processPayment()`

## Nits
- `userData` → `user` (same meaning, shorter)

## Questions
1. Why is `retryCount` hardcoded to 3 — should this be config?

ディープ・厳格レビュー・モード

ユーザーが厳格／徹底的なレビュー（例：「/review --strict」、「deep review」、「rigorous review」、「code quality audit」）を求めた場合は、上記のワークフローに code-review-and-quality の評価基準を適用し、5 つの軸（正確性、可読性、アーキテクチャ、セキュリティ、パフォーマンス）に沿って確認します。その基準で暫定的にブロッカーとされる項目は Blockers に移し、コミットにはより厳しい承認基準を適用します。エージェントが作成したブランチについては、agentic-code-review も適用します。

関連項目

• mattpocock/code-review — 2 つの軸（標準と、元の課題に照らした仕様）でレビューを行い、並列のサブエージェントとして実行します。ソース： https://github.com/mattpocock/skills/tree/main/skills/engineering/code-review
• code-review-and-quality — 上記のディープ・厳格レビュー・モードで使用する、ベンダー提供の厳格レビュー評価基準の上流版です。エージェントの差分レビューで起きる失敗パターンについては、エージェントによるコードレビュー も参照してください。

ベンチマーク

シナリオ：.benchmarks/scenarios/review-001-severity-tiers.md · 実行：2026-08-31 · ログ：.benchmarks/runs/2026-08-31/review-001-severity-tiers.json

モデル	適用なし	適用あり	差分
claude-opus-4-8	67%	83%	+16%
claude-sonnet-4-6	83%	67%	−16%
claude-haiku-4-5	83%	83%	+0%

NEG（実行 2026-08-31）。重大度の階層の境界で Sonnet は −16、opus は +16 でした。判定基準と階層テーブルのどちらが原因か曖昧なため、編集の前に診断用の c5 のみの再実行をキューに追加しました（上限に到達）。.agents/skills/skill-optimizer/rules/release-gates.md に従ってゲートを適用してください。