SKILL.md の日本語翻訳

---
name: code-review
description: Structured, taxonomy-guided code review with selective category focus. Performs two-pass review (detect then verify) across 16 error categories with independent severity, confidence, and qualifier axes. Use when reviewing a PR, reviewing staged changes, performing a pre-merge quality gate, or when asked to review specific files or a diff.
license: MIT
version: 1.0.0
metadata:
  author: itzcull
---

## 目的

形式的なエラー分類体系に基づく構造化されたコードレビューを実施します。「このコードをレビューしてください」といった開放的な分析ではなく、このスキルは具体的なレビュー規則、例、および重大度ガイダンスを備えた特定のエラーカテゴリを読み込みます。レビュアーは選択したカテゴリに選別的に焦点を当てることで、「集中的態度仮説」に従って検索空間を絞り込み、検出精度を向上させます（集中したレビュアーは焦点分野で 8 倍多くの問題を検出します）。

## 使用時期

- プルリクエストやブランチの差分をレビューする場合
- コミット前にステージ済みの変更をレビューする場合
- フィーチャーブランチのマージ前品質ゲート
- 特定のファイルを対象の懸念事項についてレビューする場合（例：「セキュリティについてレビューしてください」）
- コード変更を「レビュー」「チェック」「監査」「批評」するよう依頼された場合

## 予想されるインプット

- **差分ソース**：ブランチ（トランク比較）、ステージ済み変更、特定のファイルパス、または提供された差分のいずれか
- **カテゴリ選択**：名前による特定のカテゴリ、レビュープロファイル、または「すべて」（指定されない場合は `quick` にデフォルト設定）
- **重大度の閾値**：報告する最小重大度（デフォルトは Minor — リクエストされない限り Nitpick を除外）
- **プロジェクト規約**：既知の場合、プロジェクト固有のスタイルガイド、lint 設定、またはアーキテクチャ制約

## レビュープロファイル

プロファイルは事前定義されたカテゴリのバンドルです。プロファイル名を略記として使用するか、個別のカテゴリを名前で指定してください。

| プロファイル | カテゴリ | 使用場面 |
|---|---|---|
| `quick` | Logic & Correctness、Error Handling、Security、Performance | 最高信号の欠陥カテゴリに焦点を当てた高速レビュー |
| `correctness` | Logic & Correctness、Data Handling、Error Handling、Concurrency & Timing | 機能的振る舞いが正しいことを検証 |
| `security` | Security、Concurrency & Timing、Resource Management、API & Interface | セキュリティ重視の監査 |
| `maintainability` | Naming & Readability、Code Structure & Organisation、Style & Formatting、Documentation、Design & Architecture | コード品質と長期的な健全性 |
| `testing` | Testing、Logic & Correctness、Error Handling | テストの適切性と品質を検証 |
| `full` | 全 16 カテゴリ | 包括的なレビュー — 重大な変更に使用 |

## プロセス

### ステップ 1：差分を取得

ユーザー入力から差分ソースを決定します：

- **ブランチレビュー**：トランク（`main` または `master`）を検出し、マージベースを探して `git diff <merge-base>..HEAD` を実行
- **ステージ済み変更**：`git diff --cached` を実行
- **特定のファイル**：名前付きファイルで `git diff` を実行するか、直接読み込む
- **提供された差分**：与えられた差分テキストをそのまま使用

また、ブランチをレビューする場合の概要として `git diff --stat` とコンテキストとして `git log --oneline` を取得します。

### ステップ 2：レビュースコープを決定

アクティブなカテゴリを解決します：

1. ユーザーがプロファイルを指定した場合、それをカテゴリリストに展開
2. ユーザーが特定のカテゴリを指定した場合、それらを使用
3. 選択が指定されなかった場合、`quick` プロファイルにデフォルト設定
4. `references/<category>.md` から対応する参照ファイルを読み込む

すべての検出結果に適用される重大度、信頼度、および修飾子の定義について `references/categories.md` を読み込みます。

### ステップ 3：第 1 パス — 候補を検出

読み込まれたカテゴリルールをアクティブにして差分を読み進めます。潜在的な検出結果ごとに：

- **位置**（ファイルと行番号）を特定
- **カテゴリ**と**サブカテゴリ**を割り当て
- 初期**重大度**（Critical / Major / Minor / Nitpick）を割り当て
- 初期**信頼度**（High / Medium / Low）を割り当て
- **修飾子**（Missing / Incorrect / Extraneous）をタグ付け
- 簡潔な**説明**を起案

このパスでは広く網を張ります。問題の可能性があるものはすべて含めます。

### ステップ 4：第 2 パス — 検証とフィルタリング

各候補検出結果を完全なコンテキストに対して再検討します：

- 周囲のコードが問題を確認する検出結果を**昇格**
- 偽陽性の可能性が高い検出結果を**降格**（各カテゴリ参照の「一般的な偽陽性」セクションを確認）
- 再検討後に支援証拠がない低信頼度の検出結果を**削除**
- 異なる位置で同じ根本原因を説明する重複検出結果を**マージ**
- 特定のコンテキストに基づいて**重大度を調整**（ホットパス内の null 逆参照は Critical、デッドコード内では Minor の場合があります）

この 2 段階パイプラインは偽陽性を削減します — 生の単一パス LLM 出力は本番環境での使用に多すぎます。

### ステップ 5：報告書を提示

以下で定義された構造化出力を作成します。検出結果を重大度別にグループ化し（Critical が最初）、各重大度レベル内でカテゴリ別にグループ化します。本物の正の観察を含めます。

## 出力形式

Code Review: [ブランチ名、ファイル名、または「ステージ済み変更」]

Scope: [何をレビューしたか — diff stat からのファイル数、行数] Categories: [どのカテゴリがアクティブだったか] Profile: [使用されたプロファイル名、またはカスタム「custom」] Severity threshold: [報告される最小重大度]

Summary: [件数] 件の検出結果（[件数] critical、[件数] major、[件数] minor、[件数] nitpick）

---

Critical

[検出結果のタイトル]

• Location: file:line
• Category: [カテゴリ] > [サブカテゴリ]
• Confidence: [High | Medium | Low]
• Qualifier: [Missing | Incorrect | Extraneous]
• Description: [問題が何であり、なぜ重要なのか]
• Suggestion: [具体的な修正または方向性]

[...各 critical 検出結果について繰り返し...]

Major

[...同じ形式...]

Minor

[...同じ形式...]

Nitpick

[...重大度の閾値が許可する場合のみ含まれる、同じ形式...]

---

観察事項

• [注目する価値のある肯定的なパターン]
• [検出結果ではないが議論する価値があるアーキテクチャに関する注記]
• [レビューされ、クリーンであることが判明した領域]

検出結果が生成されない場合、これを明示的に述べ、チェックされた内容についての簡潔な注記を含めます。

## エスカレーション条件

以下の場合は停止して質問します：

- 差分が大きすぎて 1 つのパスで意味を持つようにレビューできない（500+ 個の変更されたファイル） — モジュールまたは領域別に分割することを提案
- カテゴリ選択が変更の性質と一致しない場合（例：CSS のみの変更に対するセキュリティプロファイル）
- 検出結果が高い重大度だが低い信頼度であり、マージを誤って確認できる可能性がある
- 検出結果を判定するためにプロジェクト規約が必要だが、利用できない
- 差分コンテキストが正確性を判定するのに不十分（例：呼び出し元が表示されない削除されたコード）

## 制約

- **読み取り専用分析** — ファイルを変更したり、コミットを作成したり、明示的に依頼されない限り修正を適用しない
- **正直な評価** — 本当のリスクをフラグ化、丁寧にするために検出結果を柔らかくしない、徹底的に見えるようにするために検出結果を誇張しない
- **比例的な深さ** — 複雑またはリスクのある変更により多くの分析を費やし、些細なフォーマットにはより少なく
- **偽りの権限なし** — 本当に不確実な場合は Medium または Low 信頼度を使用、推測を事実として提示しない
- **スコープを尊重** — 提供された差分のみをレビュー、特に依頼されない限りコードベース全体を監査しない
- **カテゴリの規律** — アクティブなカテゴリ内の検出結果のみを報告、スコープを黙って拡大しない
- **重大度の誠実さ** — あらゆるレビューのほとんどの検出結果は Minor または Nitpick です。多くの Critical 検出結果を含むレビューは自己検証を促す必要があります

## 参照ドキュメント

- `references/categories.md` — マスターカテゴリインデックス、スケール、および検出結果テンプレート
- `references/<category-name>.md` — 例を含む個別カテゴリレビュー規則
- `~/.claude/docs/testing.md` — Testing カテゴリコンテキスト
- `~/.claude/docs/code-style.md` — Style および Naming カテゴリコンテキスト
- `~/.claude/docs/typescript.md` — TypeScript 固有のレビュー規則
- `~/.claude/docs/workflow.md` — TDD とコミット予期を理解するため