Agent Skills: pr-reviewer

|

UncategorizedID: goldeneggg/dotfiles/pr-reviewer

Install this agent skill to your local

pnpm dlx add-skill https://github.com/goldeneggg/dotfiles/tree/HEAD/ai-linux/.claude/skills/pr-reviewer

Skill Files

Browse the full folder contents for pr-reviewer.

Download Skill

Loading file tree…

ai-linux/.claude/skills/pr-reviewer/SKILL.md

Skill Metadata

Name
pr-reviewer
Description
|

pr-reviewer

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

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

Degrees of Freedom

  • 引数の解析: Low freedom — 以下の「引数の解析」セクションのパターンに厳密に従う。パターンに合致しない場合は必ずユーザーに確認する
  • blind モードの情報境界: Low freedom--blind では変更目的を示す情報を取得・推測しない。「--blind オプション」とレビュープロセスのモード別手順に厳密に従う
  • レビュー観点の重み付け: Medium freedomレビュー評価基準 の5観点は必須。ただし、変更内容に応じて重点を置く観点をエージェントが判断してよい
  • 外部情報の収集: High freedom — MCPツールやWebSearchの使用判断はエージェントに委ねる。不明な技術・ライブラリに遭遇した場合は積極的に調査してよい
  • フィードバックの粒度: Medium freedomレビュー評価基準 の重要度判定は固定。ただし各指摘の説明の詳しさは問題の複雑さに応じて調整してよい
  • フィードバックの文章品質: Low freedom指摘の記述指針 に厳密に従う
  • レポート出力の公開性: Low freedomレポート公開指針 に厳密に従う
  • 出力先の解釈: Low freedom — 「出力の実行」セクションのファイル命名規則・投稿手順に厳密に従う。--output の値の解釈や投稿可否判定を独自に緩めない

引数の解析

$ARGUMENTS の形式: {owner/repo} {PR番号} or {PR URL} or {ブランチ名} [--base ベースブランチ] [--outline 概要 | --blind] [--output file,pr-comment,pr-comment-with-approve,pr-thread] [--rule ルールファイル,...]

$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番号} --blind | goldeneggg/dotfiles 123 --blind | GitHub PRのblindレビュー | | {owner/repo} {PR番号} --output {出力先} | goldeneggg/dotfiles 123 --output file | GitHub PRレビュー(追加出力先指定) | | {ブランチ名} | feature/new-api | ローカルブランチレビュー(base: main) | | {ブランチ名} --base {ベースブランチ} | feature/new-api --base develop | ローカルブランチレビュー(base指定) | | {ブランチ名} --blind | feature/new-api --blind | ローカルブランチのblindレビュー | | 引数なし | (空) | ユーザーにレビュー対象を確認 |

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

--output オプション: チャット表示に加えて追加の出力先を指定します。値は file(ファイル出力)、pr-comment(PRコメント投稿)、pr-comment-with-approve(PRコメント投稿と条件付き承認)、pr-thread(指摘ごとのレビュー・スレッド投稿)です。カンマ区切りで併記すると複数の出力を実行します(例: --output file,pr-comment-with-approve)。pr-comment-with-approvepr-comment を内包するため、両方が指定されてもコメントは1件だけ投稿します。pr-threadfile とのみ併用可能で、pr-comment または pr-comment-with-approve と併記された場合は、同じ指摘の二重投稿を避けるためユーザーにどちらを使うか確認します。未指定の場合はチャット表示のみ(従来通りの挙動)。値の詳細は「出力の実行」セクションを参照。file / pr-comment / pr-comment-with-approve / pr-thread 以外の値が渡された場合は不正な値としてユーザーに確認します。

--rule オプション: レビュー時に追加で適用するルール・観点を記載したファイルを指定します。カンマ区切りで複数指定可能(例: --rule rules/security.md,rules/api-design.md)。指定されたファイルをレビュー開始前に読み込み、「レビューの実施」(ステップ3)で通常の5観点に加えてルールファイルの内容を追加の評価軸として適用します。ファイルが見つからない場合はエラーとしてユーザーに報告します。

--blind オプション: 変更目的や実装者の主張によるアンカリングを避け、diff と既存コードから欠陥・退行を探索するフラグです。値は取りません。

  • GitHub PRではPRタイトル・本文・コミットメッセージ・関連Issue・ラベル・作成者・レビューコメントを取得しない
  • ローカルブランチではコミット履歴・コミットメッセージを取得せず、ブランチ名から変更目的を推測しない
  • diff、diff外の既存コード、プロジェクトの公開規約、--rule の明示ルール、必要な公式仕様は使用してよい
  • --outline と同時指定された場合は、どちらか一方を選ぶようユーザーに確認し、レビューを開始しない
  • --outputfilepr-comment は併用できる。変更目的への適合を確認できないため、pr-comment-with-approve とは併用せず、どちらかの変更をユーザーに確認する

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

スコープ

対象:

  • コード変更のレビュー(品質・セキュリティ・規約準拠・ベストプラクティス)
  • 変更が既存機能に与える影響(デグレ/リグレッション)の調査 — 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'

--blind ではPR説明やその他のメタデータを取得せず、次のコマンドだけを実行します:

gh pr diff {pr_num} --repo {repo}

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

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

outlineパラメータ(--outline):

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

2. 変更内容の理解

通常モードでは、まず outline/コンテキストを読みます:

  • PRレビューの場合: {outline} が提供されていればそれを使用、なければPRの説明を使用
  • ブランチレビューの場合: {outline} が提供されていればそれを使用、なければdiffから推測

--blind では、diff出力を最初に分析し、どのコードが変更・追加・削除されたか、既存の振る舞いがどう変わるかを特定します。変更の目的や正当性は推測せず、観測できる挙動と影響範囲だけを扱います。

  • 通常モードでは、コンテキストと実際のコード変更の両方に基づいて変更の範囲と目的を特定
  • --blind を含む全モードで、diff外の既存コードを読み、呼び出し元・公開契約・周辺実装との整合性を確認
  • 言語固有の規約についてはプロジェクトドキュメント(CLAUDE.md)のコンテキストを考慮

3. ルールファイルの読み込み(--rule 指定時のみ)

--rule が指定されている場合、カンマ区切りの各ファイルパスを順に読み込む。読み込んだ内容はステップ4のレビュー実施時に追加の評価軸として使用する。

  • 各ファイルを Read ツールで読み込む
  • ファイルが存在しない場合はエラーとしてユーザーに報告し、該当ファイルをスキップして続行する
  • 読み込んだルール・観点は「追加レビュー観点(--rule 指定)」としてステップ4で適用する

4. レビューの実施

レビュー開始前に レビュー評価基準 を全文読み、必須5観点を変更内容へ適用する。

--blind では5観点を維持するが、PR説明やoutlineとの一致は判定しない。観測できる挙動変化と影響範囲を列挙し、それが意図された変更かどうかは結論づけない。詳細はレビュー評価基準の「デグレ(リグレッション)と影響範囲」に従う。

追加レビュー観点(--rule 指定時):

ステップ3で読み込んだルールファイルの内容を追加の評価軸として適用する。ルールファイルに記載された観点・基準・チェック項目に基づき、上記5観点と同等の厳密さで検証する。ルールファイルごとにフィードバックを整理し、どのルールに基づく指摘かを明示する。

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

指摘を作成する前に 指摘の記述指針 を全文読み、必須項目と文章規則を適用する。

その他の報告事項(もしあれば):

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

重要: 各指摘で参照するパスは、必ず レポート公開指針 に従う。

6. レビュー合格基準

レビュー結果を レビュー評価基準 の重要度とPR承認判断に従って分類する。

レビュー完了時の報告:

--blind の場合は、サマリー見出しの直後に **レビュー前提**: PR説明・outline・コミットメッセージを参照せず、diffと既存コードをレビュー と記載する。

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

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

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

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

7. 出力の実行

レビュー結果は常にチャット上に表示します。--output で追加の出力先が指定されている場合は、チャット表示に加えて以下を実行します。いずれの出力先に対しても、表示・書き込み・投稿の直前に レポート公開指針 を全文読み、「報告前チェック」を完了させます。

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-apipr-review-feature-new-api-vs-main.md
  • 内容: 「フィードバックの提供」〜「レビュー完了時の報告」で組み立てたレポート全体(サマリー含む)をそのまま Markdown として書き込む
  • 同名ファイルが既に存在する場合は上書きしてよい(レビューの再実行結果を最新化する用途のため)
  • 書き込み完了後、保存したファイルパスをチャットで報告する

pr-comment(PRコメント投稿):

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

pr-comment-with-approve(PRコメント投稿と条件付き承認):

  • 前提条件: GitHub PRレビュー(PR番号が確定しているモード)でのみ実行可能。ローカルブランチレビューでは、pr-comment と同様に投稿・承認は行わない
  • まず pr-comment と同じ手順で、レポート全体(サマリー含む)を1件のコメントとして投稿する。pr-comment も併記されている場合でも、同じレポートを重複投稿しない
  • コメント投稿後、次の条件をすべて満たす場合にのみ gh pr review {pr_num} --repo {repo} --approve を実行する
    • 🔴 Critical が0件かつ 🟠 High が0件である(High以上の指摘がない)
    • 最終結論(総合判定)が「承認可能」または「条件付きで承認可能」である
  • 条件を満たさない場合は、コメント投稿のみで完了し、承認操作は行わない。その理由(重要度件数または最終結論)をチャットで報告する
  • 承認の実行後、成功時は承認したことをチャットで報告する。失敗時はエラーメッセージを報告するが、投稿済みコメントを取り消さない

pr-thread(レビュー・スレッド投稿):

  • 前提条件: GitHub PRレビュー(PR番号が確定しているモード)でのみ実行可能。ローカルブランチレビューでは投稿先の PR が存在しないため、投稿は行わない(詳細は「エラーハンドリング」参照)
  • 各指摘について、PR の diff 内の1行に対応する path、行番号、LEFT または RIGHT の side を、diff とレビュー根拠から確定する。対応先を確定できない指摘、または diff 外の行しか根拠にできない指摘を、近い行へ推測して投稿してはならない
  • 対応先を確定できた指摘だけを、1指摘につき1スレッドとして投稿する。投稿本文は 指摘の記述指針 を満たす内容とし、GitHub 側で既に表示されるパス・行番号を重複記載しない
  • 対応可能な指摘が0件の場合は GitHub API を呼び出さず、投稿しなかった理由と対象外の指摘をチャットで報告する
  • 投稿には GitHub GraphQL API を使用する。具体的な手順、入力検証、失敗時の停止条件は PRスレッド投稿手順 を読み、厳密に従う
  • 成功時は作成されたレビューの URL と投稿スレッド数をチャットで報告する。pr-thread 自体は承認操作を行わない

ガイドライン

  • ユーザーとのすべてのコミュニケーションは日本語で行う — 質問、フィードバック、説明、その他すべてのやり取り
  • 不明点は必ずユーザーに確認してから進める
  • レビュータスクは徹底的かつ粘り強く完了させ、開発者がコード品質を向上させるのに役立つ実用的なフィードバックに焦点を当てる
  • 必要に応じて MCP ツール(fetch、context7、WebFetch、WebSearch)で外部ソースから最新の公式仕様とベストプラクティスを収集
  • --blind では変更目的を示す情報を後から補完しない — PR説明・コミットメッセージ・関連Issue・レビューコメントを、確認や指摘の棄却を目的として途中取得しない
  • テスト実行・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 概要 を指定)
    • blindレビュー: pr-reviewer スキル(例: owner/repo 123 --blind を指定)
    • 出力先指定: pr-reviewer スキル(例: owner/repo 123 --output file,pr-thread を指定)
  • 引数なしの場合はレビュー対象を質問

--blind と非互換オプションの同時指定

原因:

  • --blind--outline が同時指定されている
  • --blind と、pr-comment-with-approve を含む --output が同時指定されている

対処:

  • レビューを開始せず、--blind--outline のどちらを使用するかユーザーに確認
  • 出力先は pr-comment-with-approve から pr-comment へ変更するか、--blind を外すかユーザーに確認
  • 指定を黙って無視したり、自動的に通常モードへ切り替えたりしない

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 でコミット履歴の確認を提案。--blind ではコミット履歴を取得せず、対象指定の再確認だけを依頼

巨大なdiff(10,000行以上)

原因:

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

対処:

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

ネットワークエラー

原因:

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

対処:

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

--output の値が不正または併用不可

原因:

  • file / pr-comment / pr-comment-with-approve / pr-thread 以外の値が指定されている(例: --output slack
  • カンマ区切りの記法が誤っている
  • pr-threadpr-comment または pr-comment-with-approve が併記されている

対処:

  • 受け付ける値が filepr-commentpr-comment-with-approvepr-thread であることを提示
  • pr-threadfile とのみ併記できることを説明し、いずれかの投稿方式を選ぶよう依頼する
  • 正しい形式の例を示して再入力を依頼: pr-reviewer スキル(例: owner/repo 123 --output file,pr-thread を指定)

--rule で指定されたファイルが見つからない

原因:

  • ファイルパスの誤り(タイポ、相対パスの解決失敗)
  • 指定ファイルが存在しない

対処:

  • 見つからなかったファイルパスをユーザーに提示
  • 該当ファイルをスキップし、他のルールファイル(存在するもの)と通常の5観点でレビューを続行
  • すべてのルールファイルが見つからない場合は --rule なしと同等の通常レビューを実行し、その旨を報告

ローカルブランチレビューで PR 投稿出力が指定された

原因:

  • ローカルブランチレビュー(PR番号が確定していないモード)では投稿先の PR コメント欄、レビュー・スレッドおよび承認対象が存在しない

対処:

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

PRコメント投稿失敗

原因:

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

対処:

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

PRスレッド投稿失敗

原因:

  • GitHub GraphQL API の権限不足、対象 PR の状態変更、または行位置の検証失敗
  • API 呼び出し後にネットワークが切断され、投稿成否を確定できない

対処:

  • API が返した明確なエラーメッセージはそのまま報告し、投稿済みとみなさない
  • 成否が不明な通信エラーでは再試行しない。重複スレッドを避けるため、ユーザーに PR 上の投稿状況の確認を依頼する
  • 投稿に失敗した場合でも、レポート内容自体はチャット表示(またはfile出力)で確実に伝える

PR承認失敗

原因:

  • gh CLI の権限不足(PRレビュー承認に必要な権限がない)
  • 自分が作成したPRなど、GitHubのルールにより承認できない
  • 対象PRがクローズ・マージ済み、またはすでにレビュー済み

対処:

  • エラーメッセージをユーザーに提示
  • gh auth status で権限を確認するよう促す
  • コメント投稿済みであることを明示し、承認失敗でもレポート内容は有効であることを伝える

ファイル出力失敗

原因:

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

対処:

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