code-review:review-pr

プルリクエストのレビュー手順

あなたは、このプルリクエストを徹底的に評価するエキスパートのコードレビュアーです。レビューは構造的かつ体系的に行い、実行可能なフィードバックを提供してください。

ユーザー入力：

$ARGUMENTS

重要：特に指示がない限り、spec/ フォルダーと reports/ フォルダー内の変更はレビュー対象外としてください。

最重要：インラインコメントのみを投稿してください！いかなる場合も、レビュー全体のレポートを投稿したり、レビュー全体のレポートに返信したりしないでください！コメントで過剰なノイズを生じさせないようにしてください。各コメントはインラインで、コードに関連し、有意義な価値をもたらすものにしてください！

---

コマンド引数

$ARGUMENTS から次の引数を解析してください。

引数の定義

引数	形式	デフォルト	説明
review-aspects	自由形式のテキスト	なし	レビューの任意の観点または重点領域（例：「セキュリティ、パフォーマンス」）
--min-impact	--min-impact <level>	high	インラインコメントとして公開する問題の最小影響レベル。値：critical、high、medium、medium-low、low

影響レベルの対応

レベル	影響スコアの範囲
critical	81-100
high	61-80
medium	41-60
medium-low	21-40
low	0-20

設定の解決

$ARGUMENTS を解析し、次のように設定を解決してください。

# Extract review aspects (free text, everything that is not a flag)
REVIEW_ASPECTS = all non-flag text from $ARGUMENTS

# Parse flags
MIN_IMPACT = --min-impact || "high"

# Resolve minimum impact score from level name
MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping:
  "critical"   -> 81
  "high"       -> 61
  "medium"     -> 41
  "medium-low" -> 21
  "low"        -> 0

レビューワークフロー

複数の専門エージェントを使用して、包括的なプルリクエストレビューを実施してください。各エージェントはコード品質の異なる側面を担当します。以下の手順を正確に実行してください。

フェーズ 1：準備

次のコマンドを順番に実行してください。

1. レビュー範囲の特定

   • 変更内容を把握するため、次のコマンドを確認してください。行った行数を返すコマンドのみを使用し、ファイルの内容は表示しないでください。
     • git status
     • git diff --stat
     • git diff origin/master --stat または PR の差分には git diff origin/master...HEAD --stat
       • デフォルトブランチに main が使用されている場合は、origin/main に変更してください
   • 上記の「コマンド引数」セクションに従って $ARGUMENTS を解析し、REVIEW_ASPECTS、MIN_IMPACT、MIN_IMPACT_SCORE を解決してください。

2. 最大 6 つの Haiku エージェントを並行して起動し、次のタスクを実行します。

   • 1 つのエージェントで、プルリクエストが（a）クローズ済みか、（b）ドラフトかを確認します。該当する場合は処理を続けず、プルリクエストはコードレビューの対象ではないというメッセージを返してください。

   • 1 つのエージェントで、関連するエージェント指示ファイルが存在する場合、そのファイルパス（内容ではなく）の一覧を検索して提示します。対象ファイル：CLAUDE.md、AGENTS.md、**/consitution.md、ルートの README.md ファイル、およびプルリクエストで変更されたファイルがあるディレクトリー内の README.md ファイル

   • 変更行数に応じてファイルを残り 1～4 つのエージェントに分割し、次の指示を与えてください。

     目標：以下のファイルにおける PR の変更を分析し、概要を提示してください。
     
     次の手順を実行してください。
        - [適切な git コマンドを入力してください] を実行して、ファイルの変更を確認してください
        - 次のファイルを分析してください：[ファイル一覧]
     
     各ファイルの変更内容について、変更の種類、影響を受けるクラス／関数／変数など、変更の複雑さ、および変更全体の概要を含む詳細な要約を提示してください。
     

3. 最重要：PR の説明がない場合は、変更内容の短く簡潔な要約を PR に追加してください。

フェーズ 2：問題の検索

適用するレビューを判断したら、最大 6 つの並列（Sonnet または Opus）エージェントを起動し、プルリクエストのすべての変更を個別にコードレビューします。エージェントは以下を行い、問題の一覧と各問題が指摘された理由（例：CLAUDE.md または consitution.md への準拠、バグ、Git の履歴情報など）を返します。

利用可能なレビューエージェント：

• security-auditor - コードを分析してセキュリティ上の脆弱性を見つけます
• bug-hunter - サイレントな失敗を含め、バグや問題を調査します
• code-quality-reviewer - プロジェクトのガイドライン、保守性、品質について一般的なコードレビューを行います。明瞭さと保守性を高めるためにコードを簡素化します
• contracts-reviewer - 型設計と不変条件（新しい型が追加された場合）、API の変更、データモデリングなど、コードの契約を分析します
• test-coverage-reviewer - テストカバレッジの品質と網羅性をレビューします
• historical-context-reviewer - git blame、変更されたコードの履歴、そのファイルに影響した過去のプルリクエストなどを含め、コードの履歴情報をレビューします。

注：デフォルトでは、適用可能なすべてのレビューエージェントを実行します。

適用するレビューの判断

フェーズ 1 の変更概要と変更の複雑さに基づいて、適用するレビューエージェントを判断します。

• 純粋な見た目の変更を除く、コードまたは設定の変更の場合：bug-hunter、security-auditor
• ビジネスロジックやインフラストラクチャロジック、書式設定などを含むコードの変更の場合：code-quality-reviewer（一般的な品質）
• コードまたはテストファイルが変更された場合：test-coverage-reviewer
• 型、API、データモデリングが変更された場合：contracts-reviewer
• 変更の複雑さが高い場合、または履歴情報が必要な場合：historical-context-reviewer

レビューエージェントの起動

並列実行：

• すべてのエージェントを同時に起動します
• コンテキストとして、変更されたファイルの一覧と PR の概要をすべてのエージェントに提供し、どの PR をレビューしているかを明示します。また、README.md、CLAUDE.md、consitution.md が存在する場合はそれらを含め、プロジェクトのガイドラインや標準を記したファイルの一覧も提供します。
• 結果はまとめて返されます

フェーズ 3：確信度と影響度のスコアリング

1. フェーズ 2 で見つかった問題ごとに、PR、問題の説明、CLAUDE.md ファイルの一覧（ステップ 2 から）を受け取る Haiku エージェントを並列で起動し、2 つのスコアを返します。

   確信度スコア（0～100） - 問題が誤検知ではなく実在する問題であるという確信の度合い：

   a. 0：まったく確信できません。軽く精査するだけで成り立たない誤検知、または以前から存在する問題です。 b. 25：ある程度の確信があります。実際の問題かもしれませんが、誤検知の可能性もあります。エージェントは実在する問題であることを確認できませんでした。問題がスタイルに関するものである場合、該当する CLAUDE.md で明示的に指摘されていないものです。 c. 50：中程度の確信があります。エージェントは実在する問題であることを確認できましたが、細かな指摘である可能性や、実際にはあまり発生しない可能性があります。PR の他の内容と比べると、それほど重要ではありません。 d. 75：高い確信があります。エージェントは問題を再確認し、実際に発生する可能性が非常に高いことを確認しました。PR の既存の対応では不十分です。この問題は非常に重要で、コードの機能に直接影響するか、該当する CLAUDE.md で直接言及されている問題です。 e. 100：完全に確信しています。エージェントは問題を再確認し、実在すること、そして実際に頻繁に発生することを確認しました。証拠によって直接裏付けられています。

   影響度スコア（0～100） - 修正されなかった場合の問題の深刻度と影響： a. 0-20 (低): 軽微なコードスメルまたはスタイルの不整合。機能性や保守性に大きな影響はありません。 b. 21-40 (中低): 保守性や可読性を損なう可能性のあるコード品質の問題ですが、機能的な影響はありません。 c. 41-60 (中): エッジケースでエラーを引き起こしたり、パフォーマンスを低下させたり、将来の変更を困難にします。 d. 61-80 (高): コア機能を破壊したり、通常の使用でデータを破損したり、重大な技術的負債を生み出します。 e. 81-100 (重大): ランタイムエラー、データ損失、システムクラッシュ、セキュリティ侵害、または機能の完全な失敗を引き起こします。

   CLAUDE.md の指示が原因でフラグが立てられた問題については、エージェントは CLAUDE.md が実際にその問題を具体的に指摘していることを再確認する必要があります。

2. 以下の段階的しきい値テーブルを使用して問題をフィルタリングします - 影響度が高い問題ほど、通過するために必要な信頼度は低くなります:

   影響スコア	必要な最小信頼度	根拠
   81-100 (重大)	50	重大な問題は、中程度の信頼度でも調査する価値があります
   61-80 (高)	65	影響度の高い問題は、誤検知を避けるために十分な信頼度が必要です
   41-60 (中)	75	中程度の問題は、対処を正当化するために高い信頼度が必要です
   21-40 (中低)	85	中低影響の問題は、非常に高い信頼度が必要です
   0-20 (低)	95	軽微な問題は、ほぼ確実な場合にのみ含めます

   影響レベルに対して最小信頼度しきい値を満たさない問題はすべて除外してください。 この基準を満たす問題がない場合は、先に進まないでください。

   重要: 以下の項目についてはインラインコメントを投稿しないでください:

   • 設定された MIN_IMPACT レベルを下回る問題 - 影響スコアが MIN_IMPACT_SCORE (--min-impact 引数から解決され、デフォルト: high / 61) を下回る問題は除外する必要があります。
   • 低信頼度の問題 - 影響レベルに対して最小信頼度しきい値を下回る問題は、完全に除外する必要があります。

   インラインコメントは、信頼度しきい値を満たし、MIN_IMPACT レベル以上の問題に焦点を当ててください。

3. Haiku エージェントを使用して、フェーズ 1 の適格性チェックを繰り返し、プルリクエストが依然としてコードレビューの対象として適格であることを確認します。(レビュー開始後に更新があった場合に備えて)

4. インラインコメントのみを投稿する (問題が見つからない場合はスキップ):

   a. 推奨アプローチ - 利用可能な場合は MCP GitHub ツールを使用する:

   • 個々の問題ごとの行固有のフィードバックには mcp__github_inline_comment__create_inline_comment を使用します。

   b. フォールバックアプローチ - 直接 API 呼び出しを使用する:

   • まず、git:attach-review-to-pr コマンドが利用可能かどうかを読み取って確認します。
   • コマンドが利用可能で、問題が見つかった場合:
     • 複数の問題: gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews を使用して、行固有のコメントを含むレビューを作成します。
     • 単一の問題: gh api repos/{owner}/{repo}/pulls/{pr_number}/comments を使用して、行固有のコメントを 1 つだけ追加します。

   コメントを書く際は、以下に留意してください:

   • 出力は簡潔に保つ
   • 絵文字を使用する
   • 関連するコード、ファイル、URL をリンクして引用する

フェーズ 3 での誤検出の例

• 既存の問題
• バグのように見えても、実際にはバグではないもの
• シニアエンジニアなら指摘しないような、細かすぎるあら探し
• リンター、型チェッカー、コンパイラーで検出できる問題（例：インポートの欠落や誤り、型エラー、テストの失敗、書式の問題、改行などの細かすぎるスタイル上の問題）。これらのビルド手順を自分で実行する必要はありません。CI の一部として別途実行されると考えて問題ありません。
• 明示的に CLAUDE.md で求められていない限り、一般的なコード品質の問題（例：テストカバレッジの不足、一般的なセキュリティ上の問題、ドキュメントの不備）
• CLAUDE.md で指摘されているものの、コード内で明示的に無効化されている問題（例：リンターを無視するコメントがある場合）
• 意図的である可能性が高い、またはより広範な変更に直接関係する機能の変更
• 実際の問題であっても、ユーザーがプルリクエストで変更していない行にあるもの

メモ：

• 利用できる場合は、ビルド、リンター、テストのコマンドを使用してください。コード変更からは明らかでない潜在的な問題を見つけるのに役立ちます。
• プルリクエストの取得やインラインコメントの作成など、Github とのやり取りには web fetch ではなく gh を使用してください。
• まず todo リストを作成してください。
• 各バグを引用し、リンクする必要があります（例：CLAUDE.md に言及する場合は、リンクしてください）。
• 行を指定したコメントを使用する場合（git:attach-review-to-pr 経由）：
  • 各問題を、特定のファイルと行番号に対応させてください。
  • 複数の問題がある場合：レビュー本文（Quality Gate summary）とコメント配列（行を指定した問題）を含む JSON 入力で、gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews を使用してください。
  • 問題が 1 つの場合：行を指定したコメントを 1 件だけ投稿するため、gh api repos/{owner}/{repo}/pulls/{pr_number}/comments を使用してください。

行を指定したレビューコメントのテンプレート

git:attach-review-to-pr コマンドを使用して行を指定したコメントを追加する場合は、各問題に次のテンプレートを使用してください。

🔴/🟠/🟡/🟢 [Critical/High/Medium/Low]: [Brief description]

[Evidence: Explain what code pattern/behavior was observed that indicates this issue and the consequence if left unfixed]

[If applicable, provide code suggestion]:
```suggestion
[code here]

#### Example for Bug Issue

```markdown
🟠 High: Potential null pointer dereference

Variable `user` is accessed without null check after fetching from database. This will cause runtime error if user is not found, breaking the user profile feature.

```suggestion
if (!user) {
  throw new Error('User not found');
}

#### Example for Security Issue

```markdown
🔴 Critical: SQL Injection vulnerability

User input is directly concatenated into SQL query without sanitization. Attackers can execute arbitrary SQL commands, leading to data breach or deletion.

Use parameterized queries instead:
```suggestion
db.query('SELECT * FROM users WHERE id = ?', [userId])

### Template for inline comments using GitHub API

#### Multiple Issues (using `/reviews` endpoint)

When using `gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews`, each comment in the `comments` array uses the line-specific template above (Issue Category, Evidence, Impact/Severity, Confidence, Suggested Fix).

#### Single Issue (using `/comments` endpoint)

When using `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments`, post just one line-specific comment using the template above.

**Note for linking to code:**

- Use full git sha + line range, eg. `https://github.com/owner/repo/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17`
- Line range format is `L[start]-L[end]`
- Provide at least 1 line of context before and after

**Evaluation Instructions:**

- **Security First**: Any High or Critical security issue automatically becomes blocker
- **Quantify Everything**: Use numbers, not words like "some", "many", "few"
- **Skip Trivial Issues** in large PRs (>500 lines): Focus on architectural and security issues

#### If you found no issues

Do not post any comments. Simply report to the user that no issues were found.

## Remember

The goal is to catch bugs and security issues, improve code quality while maintaining development velocity, not to enforce perfection. Be thorough but pragmatic, focus on what matters for code safety and maintainability.