pr-reviewer Skill | Agent Skills

pr-reviewer

Git/GitHubを用いたアプリケーション開発における包括的なコードレビューを実施し、コード品質、セキュリティ、ベストプラクティスに焦点を当てます。

注意: このSkillを使用する際のユーザーとのやり取りはすべて日本語で行います。

Degrees of Freedom

引数の解析: Low freedom — 以下の「引数の解析」セクションのパターンに厳密に従う。パターンに合致しない場合は必ずユーザーに確認する
レビュー観点の重み付け: Medium freedom — コード品質・セキュリティ・規約準拠・ベストプラクティス・デグレ（影響範囲）の5観点は必須。ただし、変更内容に応じて重点を置く観点をエージェントが判断してよい（例: 認証周りの変更ならセキュリティを重点的に）
外部情報の収集: High freedom — MCPツールやWebSearchの使用判断はエージェントに委ねる。不明な技術・ライブラリに遭遇した場合は積極的に調査してよい
フィードバックの粒度: Medium freedom — 重要度レベル（Critical/High/Medium/Low）の判定基準は固定。ただし各指摘の説明の詳しさは問題の複雑さに応じて調整してよい
レポート出力の公開性: Low freedom — 「レポート出力原則（第三者可読性）」セクションに厳密に従う。レビュー結果は PR コメント等に転記されうる対外公開ドキュメントとして扱い、レビュー対象リポジトリ外・gitignore 対象・ローカル固有パスへの言及を一切含めない
出力先の解釈: Low freedom — 「出力の実行」セクションのファイル命名規則・投稿手順に厳密に従う。--output の値の解釈や投稿可否判定を独自に緩めない

引数の解析

$ARGUMENTS を以下のパターンでパースします：

| パターン | 例 | モード | |---------|-----|--------| | https://github.com/{owner}/{repo}/pull/{num} | https://github.com/goldeneggg/dotfiles/pull/123 | GitHub PRレビュー（URL） | | {owner/repo} {PR番号} | goldeneggg/dotfiles 123 | GitHub PRレビュー | | {owner/repo} {PR番号} --outline {概要} | goldeneggg/dotfiles 123 --outline 認証機能の追加 | GitHub PRレビュー（概要付き） | | {owner/repo} {PR番号} --output {出力先} | goldeneggg/dotfiles 123 --output file | GitHub PRレビュー（追加出力先指定） | | {ブランチ名} | feature/new-api | ローカルブランチレビュー（base: main） | | {ブランチ名} --base {ベースブランチ} | feature/new-api --base develop | ローカルブランチレビュー（base指定） | | 引数なし | （空） | ユーザーにレビュー対象を確認 |

URL解析ルール: https://github.com/{owner}/{repo}/pull/{num} 形式のURLから owner/repo と PR番号を抽出します。URLに --outline や --output 等のオプションを後続させることも可能です。

--output オプション: チャット表示に加えて追加の出力先を指定します。値は file（ファイル出力）と pr-comment（PRコメント投稿）で、カンマ区切りで併記すると両方を実行します（例: --output file,pr-comment）。未指定の場合はチャット表示のみ（従来通りの挙動）。値の詳細は「出力の実行」セクションを参照。file / pr-comment 以外の値が渡された場合は不正な値としてユーザーに確認します。

パースに失敗した場合: 引数がどのパターンにも合致しない場合は、ユーザーに正しい形式を提示して再入力を求めます。

スコープ

対象:

コード変更のレビュー（品質・セキュリティ・規約準拠・ベストプラクティス）
変更が既存機能に与える影響（デグレ/リグレッション）の調査 — diff 外の既存コードを read-only で読み取り、影響範囲を確認する
問題点と改善点のフィードバック提供
PR承認可否の判断

対象外（絶対に行わない）:

コードの修正・編集の実行
PRのマージ・クローズ操作
コミットの作成・修正
CIの実行・確認
テストの実行（go test, npm test, pytest 等）
Lint・静的解析ツールの実行（golangci-lint, eslint, ruff 等）
ビルドの実行（go build, npm run build 等）
コードの自動修正（gofmt, prettier --write 等）

実行系の操作（テスト・Lint・ビルド・フォーマット・CI）は「確認のため」も含めて一切禁止。 レビューは静的読解のみで行う。ただしデグレ調査のため、diff の外にある既存コードを内容検索・読み込みで 読み取ることは許可する（読み取りは副作用を持たず、影響範囲の確認に不可欠なため）。

レビュープロセス

1. 引数の解析とコード変更の取得

まず「引数の解析」セクションに従い $ARGUMENTS をパースし、レビューモードを決定します。

GitHub PRレビューの場合：

以下の2コマンドを並列実行してdiffとPR説明を同時に取得します：

# 並列実行1: diff取得
gh pr diff {pr_num} --repo {repo}

# 並列実行2: PR説明取得
gh pr view {pr_num} --repo {repo} --json title,body --jq '.title + "\n\n" + .body'

ローカルブランチレビューの場合：

git diff {base_branch}..{target_branch}

{base_branch}: --base で指定されたブランチ、未指定なら "main"

outlineパラメータ（--outline）：

指定あり → 変更内容を理解するための主要なコンテキストとして使用
PRレビューで未指定 → 上記で取得したPRの説明を使用
ブランチレビューで未指定 → diff自体からコンテキストを推測

2. 変更内容の理解

まず、outline/コンテキストを読みます：
- PRレビューの場合: {outline} が提供されていればそれを使用、なければPRの説明を使用
- ブランチレビューの場合: {outline} が提供されていればそれを使用、なければdiffから推測
次に、diff出力を分析して、どのコードが変更・追加・削除されたかを理解
コンテキストと実際のコード変更の両方に基づいて、変更の範囲と目的を特定
言語固有の規約についてはプロジェクトドキュメント（CLAUDE.md）のコンテキストを考慮

3. レビューの実施

以下の観点で変更を検証します：

コード品質：

変更が新しいバグや問題を導入していないか確認
適切なエラーハンドリングパターンをチェック
コードの可読性と保守性を評価
命名規則とコード構成を検証

コーディング規約：

CLAUDE.mdのプロジェクト固有のコーディング規約への準拠を確認
適切なコードフォーマットと構造を検証
インポート順序をチェック（stdlib → external → internal）
テストカバレッジとテストパターンを検証

セキュリティ：

潜在的なセキュリティ脆弱性を特定
ハードコードされた秘密情報や認証情報をチェック
適切な入力バリデーションを検証
セキュリティクリティカルな操作での暗号ライブラリの適切な使用を確認

ベストプラクティス：

言語固有のベストプラクティスへの準拠を評価
適切な並行処理パターンをチェック（該当する場合）
適切なエラーハンドリングとロギングを検証
リソース管理とクリーンアップを検証

デグレ（リグレッション）と影響範囲：

変更が既存の振る舞いを意図せず壊していないかを、diff の外まで踏み込んで確認します。変更箇所単体の正しさだけを見ても見落とすため、影響範囲を疑ってかかるのがデグレ検出の中核です。

影響範囲（blast radius）の調査: 変更・削除された関数・メソッド・API・型・公開定数・設定キーが、diff に含まれない既存コードからどう参照されているかを内容検索・読み込みで確認。呼び出し元が変更後の仕様に追従できているか
後方互換性・契約の変更: シグネチャ（引数・戻り値・型）、例外・エラー種別、デフォルト値、副作用、公開インターフェースに破壊的変更がないか
説明にない挙動変化: outline/PR 説明に記載のない振る舞いの変更は、意図しないデグレの典型。説明と実装の差分に注目する
失われた責務: 削除・改変されたロジックが担っていた既存の責務（バリデーション、フォールバック、エッジケース処理）が抜け落ちていないか

追加の考慮事項：

必要に応じてMCPツール（fetch、context7）を使用して外部ソースから最新の公式仕様とベストプラクティスを収集
プロジェクト固有のガイドラインはCLAUDE.mdを参照（言語・フレームワーク固有の規約が定義されている場合）

4. フィードバックの提供

フィードバックは以下の構造で日本語で提供します：

問題点（優先度別）:

内容: 具体的な問題の説明
期待される内容や動作との差異: 現状と期待される動作のギャップ
根拠となる文献: 参考文献（該当する場合）
該当箇所: diff 内のファイルパス（path/to/file.ext:42 形式）

改善点（優先度別）:

内容: 改善提案
具体的な改善方法: 具体的な改善アプローチ
該当箇所: diff 内のファイルパス

その他の報告事項（もしあれば）:

追加の観察事項や推奨事項

重要: 各指摘で参照するパスは、必ず後述「レポート出力原則」に従いレビュー対象 diff に含まれるパスのみとする。レビュー実行環境のローカルファイル・タスク管理用ドキュメント・gitignore 対象パスへは一切言及しない。

5. レビュー合格基準

レビュー結果を以下の重要度レベルで分類し、PR承認の判断基準とします：

重要度レベル:

🔴 Critical: セキュリティ脆弱性、データ損失リスク、本番環境への重大な影響
- 対処: 即座に修正必須 - PRマージ前に必ず解決
- 例: SQLインジェクション、認証バイパス、機密情報の漏洩
🟠 High: バグの可能性、コーディング規約の重大な違反、パフォーマンス劣化
- 対処: 修正を強く推奨 - PRマージ前の解決を推奨
- 例: エラーハンドリング不足、メモリリーク、重要な命名規則違反
🟡 Medium: 改善提案、リファクタリング推奨、マイナーな規約違反
- 対処: 次回以降の改善候補 - PRマージ可能だが改善を検討
- 例: 可読性の向上、テストカバレッジの追加、コメントの改善
🟢 Low: コメント改善、命名の微調整、スタイルの統一
- 対処: オプション - 時間があれば対処
- 例: 変数名のタイポ、コメントの文言調整

PR承認判断基準:

✅ 承認可能: Critical 0件かつ High 2件以下
⚠️ 条件付き承認: High 3-5件（重要度に応じて判断）
❌ 要修正: Critical 1件以上または High 6件以上

レビュー完了時の報告:

レビュー完了時は、以下の形式で総合判定を提示します：

## 📊 レビュー結果サマリー

- 🔴 Critical: X件
- 🟠 High: X件
- 🟡 Medium: X件
- 🟢 Low: X件

**総合判定**: [承認可能 / 条件付き承認 / 要修正]
**推奨アクション**: [具体的な次のステップ]

6. 出力の実行

レビュー結果は常にチャット上に表示します。--output で追加の出力先が指定されている場合は、チャット表示に加えて以下を実行します。いずれの出力先に対しても、書き込み・投稿の実行前に必ず「報告前チェック」（レポート出力原則セクション）を完了させます — ファイルや PR コメントは chat 以上に転記・共有されやすく、第三者可読性の担保がより重要になるためです。

file（ファイル出力）:

保存先: カレントディレクトリ直下（サブディレクトリは作成しない）
ファイル名:
- GitHub PRレビューの場合: pr-review-{owner}-{repo}-{PR番号}.md（例: pr-review-goldeneggg-dotfiles-123.md）
- ローカルブランチレビューの場合: pr-review-{target_branch}-vs-{base_branch}.md（/ は - に置換。例: feature/new-api → pr-review-feature-new-api-vs-main.md）
内容: 「フィードバックの提供」〜「レビュー完了時の報告」で組み立てたレポート全体（サマリー含む）をそのまま Markdown として書き込む
同名ファイルが既に存在する場合は上書きしてよい（レビューの再実行結果を最新化する用途のため）
書き込み完了後、保存したファイルパスをチャットで報告する

pr-comment（PRコメント投稿）:

前提条件: GitHub PRレビュー（PR番号が確定しているモード）でのみ実行可能。ローカルブランチレビューでは投稿先の PR が存在しないため、--output に pr-comment が含まれていてもエラーとしてユーザーに案内し、投稿は行わない（詳細は「エラーハンドリング」参照）
レポート全体（サマリー含む）を 1件のコメント として gh pr comment {pr_num} --repo {repo} --body-file {一時ファイルパス} で投稿する。指摘ごとの行内コメントには分割しない
一時ファイルはスクラッチ用ディレクトリに作成し、投稿完了後は削除する
投稿完了後、コメントの URL をチャットで報告する

レポート出力原則（第三者可読性）

前提: このレビュー結果は PR コメント・Issue・Slack・メール等に転記される可能性のある「対外公開ドキュメント」として扱う。レビュー対象リポジトリの第三者（PR 作成者・他のレビュアー）が読んでも、参照されているファイル・概念がすべて当該リポジトリ内で完結することが必要。

参照可能なファイル

✅ レビュー対象 diff に含まれるファイルパス（例: src/foo.ts:42）
✅ レビュー対象リポジトリで git 管理されている公開ファイル（例: README.md, package.json, CLAUDE.md）
✅ 公開 URL（公式ドキュメント、RFC、CVE 等）

参照禁止のファイル

❌ gitignore 対象のローカルファイル（例: .env, tmp/, logs/, ローカルキャッシュ）
❌ レビュー対象リポジトリ外のローカルパス（例: ~/notes/, /Users/xxx/, /tmp/）
❌ レビュー実行環境固有のタスク管理ドキュメント（例: docs/tasks/, todos/, task-starter プロジェクト配下のパス）が当該リポジトリで管理外、もしくは「レビュー対象 diff の外側」にある場合
❌ サブエージェント（task-reader 等）が返した内部サマリの引用元パス
❌ レビュー担当者のホームディレクトリやマシン固有の絶対パス
❌ レビュー実行に使用したスキル名・サブエージェント名（例: pr-reviewer, general-purpose, task-reader 等）— これらはレビュー実行環境に固有の概念であり、第三者には意味を持たない

「外部不可視リソース」の扱い

レビュー対象リポジトリの外にある資料（ローカルメモ、別リポジトリのタスクドキュメント等）を推論材料として参照すること自体は問題ない。ただしレポート内では:

要件・仕様は本文を直接埋め込む — 「タスク要件: ユーザー認証 API を JWT ベースで実装する」のように要件文そのものを記載する。レビュアーは別資料を開かずに文脈を理解できる状態にする
番号・記号での間接参照を避ける — 「タスク要件番号 3 によれば〜」「仕様書 §2 では〜」のような外部資料への番号参照は、第三者には何を指すか分からない。さらに後述の通り GitHub auto-link を招くリスクがある場合は致命的に誤誘導する
第三者が確認不能な情報は省く — レビュアーが追跡確認できない参照を残すと「言われた通りに見えない」状態を作り、レビューの信頼性が落ちる

GitHub auto-link を発火させない記法ルール

レポートが PR コメントや Issue 本文に転記された際、以下のパターンは GitHub によって自動リンク化され、全く無関係のIssue/PR/ユーザーへ誘導されてしまう。レポート本文では絶対に使わない:

| パターン | GitHub での解釈 | 代替表現 | |---|---|---| | #数字 (例: #3, #42) | 同リポジトリの Issue/PR #N へのリンク | 「受け入れ条件 3」「項目 3」のように # を外して書く | | GH-数字 | Issue/PR への代替リンク | 「項目 N」のように一般語で記載 | | org/repo#数字 | 他リポジトリの Issue/PR | 「外部要件 N」のように記載 | | @username | ユーザーへのメンション通知 | 「担当者」「実装者」のように役割名で記載。固有名は本当に必要な箇所のみ、かつ通知が発火しても問題ない場合に限る | | @org/team | チームへのメンション通知 | チーム名は通常文で記載（例: バックエンドチーム） | | GH-数字, フルコミットSHA(7文字以上) | コミットへのリンク | 該当の差分に対しては path/to/file.ext:42 形式で参照 |

特に # + 数字 は、AI が「要件番号」「タスク番号」を表現するために自然に書きがちなパターンであり、自動リンクに気付かないまま PR コメントへ貼られると無関係チケットへ誘導してしまう。受け入れ条件・タスク要件・チェックリストを参照する際は # を絶対に付けない。

報告前チェック

レポート生成完了時、出力に対して以下を点検する:

[ ] パス参照がすべてレビュー対象リポジトリ内の git 管理ファイルに対応しているか（diff 内、または影響範囲調査で参照した diff 外の公開ファイル。リポジトリ外・gitignore 対象は不可）
[ ] todos/, logs/, tmp/, .env, ~/, /Users/, /home/ 等を含む参照がないか
[ ] サブエージェントの出力に含まれていたパス（task-reader の specs/references パス等）を引用していないか
[ ] 外部不可視ドキュメントの内容を直接埋め込み済みで、番号・記号での間接参照が残っていないか
[ ] #数字, GH-数字, org/repo#数字, @username, @org/team といった GitHub auto-link を発火させるパターンがレポート本文・テーブル・引用箇所に含まれていないか（含まれていれば必ず代替表現へ置換）
[ ] スキル名・サブエージェント名（例: pr-reviewer, general-purpose, task-reader, pr-review-toolkit 等）がレポート本文に含まれていないか（含まれていれば削除する）

問題がある記載は削除または抽象化してから報告する。報告後の修正は混乱を招くため、チェックは報告前に必ず実施する。

ガイドライン

ユーザーとのすべてのコミュニケーションは日本語で行う — 質問、フィードバック、説明、その他すべてのやり取り
不明点は必ずユーザーに確認してから進める
レビュータスクは徹底的かつ粘り強く完了させ、開発者がコード品質を向上させるのに役立つ実用的なフィードバックに焦点を当てる
必要に応じて MCP ツール（fetch、context7、WebFetch、WebSearch）で外部ソースから最新の公式仕様とベストプラクティスを収集
テスト実行・Lint実行・ビルド・コード修正は一切行わない — 詳細は「スコープ」を参照。「動作確認のため」「確認のため」を理由にした実行も禁止
レポート出力前に「報告前チェック」を必ず実施し、第三者可読性を担保する — 参照可否・GitHub auto-link 回避・スキル名秘匿の各ルールは「レポート出力原則」を参照

エラーハンドリング

レビュー実行時に発生する可能性のあるエラーと対処方法：

引数の解析失敗

原因:

$ARGUMENTS がどのパターン（repo+PR番号/ブランチ名）にも合致しない
リポジトリ名が owner/name 形式でない
PR番号が数値でない

対処:

解析できなかった引数の内容をユーザーに提示
正しい形式の例を示して再入力を依頼:
- GitHub PR: pr-reviewer スキル（例: owner/repo 123 を指定）
- ローカルブランチ: pr-reviewer スキル（例: feature/xxx を指定）
- オプション付き: pr-reviewer スキル（例: owner/repo 123 --outline 概要 を指定）
- 出力先指定: pr-reviewer スキル（例: owner/repo 123 --output file,pr-comment を指定）
引数なしの場合はレビュー対象を質問

diff取得失敗

原因:

PR番号が存在しない
ブランチが見つからない
リポジトリへのアクセス権限がない

対処:

エラーメッセージをユーザーに提示
正しいPR番号またはブランチ名の確認を依頼
リポジトリ名が owner/name 形式で正しいか確認

gh CLI認証エラー

原因:

GitHubトークンが未設定
トークンの有効期限が切れている
必要なスコープ（repo, read:org等）が不足

対処:

gh auth status でログイン状態を確認するよう促す
gh auth login の実行を案内
必要に応じて gh auth refresh -s repo でスコープを追加

空のdiff

原因:

対象ブランチに変更が存在しない
ベースブランチとターゲットブランチが同一
すでにマージ済み

対処:

「変更が検出されませんでした」と報告
ブランチ名やPR番号が正しいか確認を依頼
git log でコミット履歴の確認を提案

巨大なdiff（10,000行以上）

原因:

大規模なリファクタリング
ライブラリのバージョンアップ（lock fileを含む）
自動生成コードの大量追加

対処:

「差分が非常に大きいため、全体レビューに時間がかかります」と通知
ファイル単位またはディレクトリ単位での段階的レビューを提案
特に重要なファイルを指定してもらうよう依頼
lock fileや自動生成ファイルを除外したレビューを提案

ネットワークエラー

原因:

GitHub APIの一時的な障害
レート制限の超過
ネットワーク接続の問題

対処:

エラーの内容を確認し、ユーザーに報告
レート制限の場合は gh api rate_limit で状況確認を促す
一時的な障害の場合は時間をおいて再試行を提案

`--output` の値が不正

原因:

file / pr-comment 以外の値が指定されている（例: --output slack）
カンマ区切りの記法が誤っている

対処:

受け付ける値が file と pr-comment（カンマ区切りで併記可）のみであることを提示
正しい形式の例を示して再入力を依頼: pr-reviewer スキル（例: owner/repo 123 --output file,pr-comment を指定）

ローカルブランチレビューで `pr-comment` が指定された

原因:

ローカルブランチレビュー（PR番号が確定していないモード）では投稿先の PR コメント欄が存在しない

対処:

「ローカルブランチレビューではPRコメント投稿はできません」とエラーを案内
--output file への変更、またはPR番号を指定したGitHub PRレビューへの切り替えを提案
pr-comment 以外の出力先（チャット表示・file）は通常通り実行する

PRコメント投稿失敗

原因:

gh CLI の権限不足（コメント投稿に必要なスコープがない）
対象PRが既にクローズ・マージ済みでコメント投稿がロックされている
一時ファイルの作成・削除に失敗した

対処:

エラーメッセージをユーザーに提示
gh auth status で権限を確認するよう促す
PRの状態（クローズ・マージ済みでないか）の確認を依頼
投稿に失敗した場合でも、レポート内容自体はチャット表示（またはfile出力）で確実に伝える

ファイル出力失敗

原因:

カレントディレクトリへの書き込み権限がない
ディスク容量不足

対処:

エラーメッセージをユーザーに提示
書き込み先ディレクトリの権限・空き容量の確認を依頼
出力に失敗した場合でも、レポート内容自体はチャット表示で確実に伝える

Agent Skills: pr-reviewer

Install this agent skill to your local

Skill Files

pr-reviewer

Degrees of Freedom

引数の解析

スコープ

レビュープロセス

1. 引数の解析とコード変更の取得

2. 変更内容の理解

3. レビューの実施

4. フィードバックの提供

5. レビュー合格基準

6. 出力の実行

レポート出力原則（第三者可読性）

参照可能なファイル

参照禁止のファイル

「外部不可視リソース」の扱い

GitHub auto-link を発火させない記法ルール

報告前チェック

ガイドライン

エラーハンドリング

引数の解析失敗

diff取得失敗

gh CLI認証エラー

空のdiff

巨大なdiff（10,000行以上）

ネットワークエラー

`--output` の値が不正

ローカルブランチレビューで `pr-comment` が指定された

PRコメント投稿失敗

ファイル出力失敗

Agent Skills: pr-reviewer

Install this agent skill to your local

Skill Files

pr-reviewer

Degrees of Freedom

引数の解析

スコープ

レビュープロセス

1. 引数の解析とコード変更の取得

2. 変更内容の理解

3. レビューの実施

4. フィードバックの提供

5. レビュー合格基準

6. 出力の実行

レポート出力原則（第三者可読性）

参照可能なファイル

参照禁止のファイル

「外部不可視リソース」の扱い

GitHub auto-link を発火させない記法ルール

報告前チェック

ガイドライン

エラーハンドリング

引数の解析失敗

diff取得失敗

gh CLI認証エラー

空のdiff

巨大なdiff（10,000行以上）

ネットワークエラー

--output の値が不正

ローカルブランチレビューで pr-comment が指定された

PRコメント投稿失敗

ファイル出力失敗

`--output` の値が不正

ローカルブランチレビューで `pr-comment` が指定された