jpskill.com
🛠️ 開発・MCP コミュニティ

gitnexus-pr-review

プルリクエストの内容を把握し、変更点やマージのリスクを評価したり、テストが不足していないかを確認したりするなど、プルリクエストのレビューを効率的に行うのを支援するSkill。

📜 元の英語説明(参考)

Use when the user wants to review a pull request, understand what a PR changes, assess risk of merging, or check for missing test coverage. Examples: "Review this PR", "What does PR #42 change?", "Is this PR safe to merge?"

🇯🇵 日本人クリエイター向け解説

一言でいうと

プルリクエストの内容を把握し、変更点やマージのリスクを評価したり、テストが不足していないかを確認したりするなど、プルリクエストのレビューを効率的に行うのを支援するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o gitnexus-pr-review.zip https://jpskill.com/download/8841.zip && unzip -o gitnexus-pr-review.zip && rm gitnexus-pr-review.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8841.zip -OutFile "$d\gitnexus-pr-review.zip"; Expand-Archive "$d\gitnexus-pr-review.zip" -DestinationPath $d -Force; ri "$d\gitnexus-pr-review.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して gitnexus-pr-review.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → gitnexus-pr-review フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

GitNexus を用いた PR レビュー

どのような時に使うか

  • 「この PR をレビューする」
  • 「PR #42 は何を修正しているか?」
  • 「これは安全にマージできるか?」
  • 「この PR の影響範囲は?」
  • 「この PR に不足しているテストはないか?」
  • マージ前に他の人のコード変更をレビューする

ワークフロー

1. gh pr diff <number>                                    → 生の diff を取得
2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})  → diff を影響を受けるフローにマッピング
3. 変更された各シンボルに対して:
   gitnexus_impact({target: "<symbol>", direction: "upstream"})    → 変更ごとの影響範囲
4. gitnexus_context({name: "<key symbol>"})               → 呼び出し元/呼び出し先を理解
5. READ gitnexus://repo/{name}/processes                   → 影響を受ける実行フローを確認
6. リスク評価とともに調査結果をまとめる

「Index is stale」と表示された場合 → レビュー前にターミナルで npx gitnexus analyze を実行してください。

チェックリスト

- [ ] PR の diff を取得 (gh pr diff または git diff base...head)
- [ ] gitnexus_detect_changes を実行して、変更を影響を受ける実行フローにマッピング
- [ ] 重要でない変更シンボル以外の各シンボルに対して gitnexus_impact を実行
- [ ] d=1 の項目 (WILL BREAK) をレビュー — 呼び出し元は更新されているか?
- [ ] 主要な変更シンボルに対して gitnexus_context を実行して全体像を把握
- [ ] 影響を受けるプロセスにテストカバレッジがあるか確認
- [ ] 全体的なリスクレベルを評価
- [ ] 調査結果とともにレビューの概要を作成

レビューの観点

観点 GitNexus の活用方法
正確性 context は呼び出し元を表示 — それらはすべて変更と互換性があるか?
影響範囲 impact は d=1/d=2/d=3 の依存関係を表示 — 何か見落としはないか?
網羅性 detect_changes は影響を受けるすべてのフローを表示 — それらはすべて処理されているか?
テストカバレッジ impact({includeTests: true}) は変更されたコードに触れるテストを表示
破壊的変更 PR の diff で更新されていない d=1 のアップストリーム項目 = 潜在的な破損

リスク評価

シグナル リスク
変更が 3 つ未満のシンボル、0〜1 個のプロセスに影響
変更が 3〜10 個のシンボル、2〜5 個のプロセスに影響
変更が 10 個を超えるシンボルまたは多数のプロセスに影響
変更が認証、支払い、またはデータ整合性コードに影響 非常に高い
PR の diff の外部に d=1 の呼び出し元が存在 潜在的な破損 — フラグを立てる

ツール

gitnexus_detect_changes — PR の diff を影響を受ける実行フローにマッピング:

gitnexus_detect_changes({scope: "compare", base_ref: "main"})

→ 変更されたシンボル: 4 つのファイルで 8 個のシンボル
→ 影響を受けるプロセス: CheckoutFlow, RefundFlow, WebhookHandler
→ リスク: 中

gitnexus_impact — 変更されたシンボルごとの影響範囲:

gitnexus_impact({target: "validatePayment", direction: "upstream"})

→ d=1 (WILL BREAK):
  - processCheckout (src/checkout.ts:42) [CALLS, 100%]
  - webhookHandler (src/webhooks.ts:15) [CALLS, 100%]

→ d=2 (影響を受ける可能性が高い):
  - checkoutRouter (src/routes/checkout.ts:22) [CALLS, 95%]

gitnexus_impact with tests — テストカバレッジの確認:

gitnexus_impact({target: "validatePayment", direction: "upstream", includeTests: true})

→ このシンボルをカバーするテスト:
  - validatePayment.test.ts [direct]
  - checkout.integration.test.ts [via processCheckout]

gitnexus_context — 変更されたシンボルの役割を理解:

gitnexus_context({name: "validatePayment"})

→ 入ってくる呼び出し: processCheckout, webhookHandler
→ 出ていく呼び出し: verifyCard, fetchRates
→ プロセス: CheckoutFlow (ステップ 3/7), RefundFlow (ステップ 1/5)

例: 「PR #42 をレビューする」

1. gh pr diff 42 > /tmp/pr42.diff
   → 4 つのファイルが変更されました: payments.ts, checkout.ts, types.ts, utils.ts

2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})
   → 変更されたシンボル: validatePayment, PaymentInput, formatAmount
   → 影響を受けるプロセス: CheckoutFlow, RefundFlow
   → リスク: 中

3. gitnexus_impact({target: "validatePayment", direction: "upstream"})
   → d=1: processCheckout, webhookHandler (WILL BREAK)
   → webhookHandler は PR の diff に含まれていません — 潜在的な破損!

4. gitnexus_impact({target: "PaymentInput", direction: "upstream"})
   → d=1: validatePayment (PR 内), createPayment (PR 内ではない)
   → createPayment は古い PaymentInput の形状を使用しています — 破壊的変更!

5. gitnexus_context({name: "formatAmount"})
   → 12 個の関数から呼び出されています — ただし、変更は後方互換性があります (オプションのパラメータが追加されました)

6. レビューの概要:
   - リスク: 中 — 3 つの変更されたシンボルが 2 つの実行フローに影響を与えます
   - バグ: webhookHandler は validatePayment を呼び出しますが、新しい署名用に更新されていません
   - バグ: createPayment は変更された PaymentInput 型に依存しています
   - OK: formatAmount の変更は後方互換性があります
   - テスト: checkout.test.ts は processCheckout パスをカバーしていますが、webhook テストはありません

レビューの出力形式

レビューを次のように構成します。

## PR レビュー: <title>

**リスク: 低 / 中 / 高 / 非常に高い**

### 変更の概要
- <M> 個のファイルにわたって <N> 個のシンボルが変更されました
- <P> 個の実行フローが影響を受けます

### 調査結果
1. **[重大度]** 調査結果の説明
   - GitNexus ツールからの証拠
   - 影響を受ける呼び出し元/フロー

### 不足しているカバレッジ
- PR で更新されていない呼び出し元: ...
- テストされていないフロー: ...

### 推奨事項
承認 / 変更をリクエスト / 議論が必要
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

PR Review with GitNexus

When to Use

  • "Review this PR"
  • "What does PR #42 change?"
  • "Is this safe to merge?"
  • "What's the blast radius of this PR?"
  • "Are there missing tests for this PR?"
  • Reviewing someone else's code changes before merge

Workflow

1. gh pr diff <number>                                    → Get the raw diff
2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})  → Map diff to affected flows
3. For each changed symbol:
   gitnexus_impact({target: "<symbol>", direction: "upstream"})    → Blast radius per change
4. gitnexus_context({name: "<key symbol>"})               → Understand callers/callees
5. READ gitnexus://repo/{name}/processes                   → Check affected execution flows
6. Summarize findings with risk assessment

If "Index is stale" → run npx gitnexus analyze in terminal before reviewing.

Checklist

- [ ] Fetch PR diff (gh pr diff or git diff base...head)
- [ ] gitnexus_detect_changes to map changes to affected execution flows
- [ ] gitnexus_impact on each non-trivial changed symbol
- [ ] Review d=1 items (WILL BREAK) — are callers updated?
- [ ] gitnexus_context on key changed symbols to understand full picture
- [ ] Check if affected processes have test coverage
- [ ] Assess overall risk level
- [ ] Write review summary with findings

Review Dimensions

Dimension How GitNexus Helps
Correctness context shows callers — are they all compatible with the change?
Blast radius impact shows d=1/d=2/d=3 dependents — anything missed?
Completeness detect_changes shows all affected flows — are they all handled?
Test coverage impact({includeTests: true}) shows which tests touch changed code
Breaking changes d=1 upstream items that aren't updated in the PR = potential breakage

Risk Assessment

Signal Risk
Changes touch <3 symbols, 0-1 processes LOW
Changes touch 3-10 symbols, 2-5 processes MEDIUM
Changes touch >10 symbols or many processes HIGH
Changes touch auth, payments, or data integrity code CRITICAL
d=1 callers exist outside the PR diff Potential breakage — flag it

Tools

gitnexus_detect_changes — map PR diff to affected execution flows:

gitnexus_detect_changes({scope: "compare", base_ref: "main"})

→ Changed: 8 symbols in 4 files
→ Affected processes: CheckoutFlow, RefundFlow, WebhookHandler
→ Risk: MEDIUM

gitnexus_impact — blast radius per changed symbol:

gitnexus_impact({target: "validatePayment", direction: "upstream"})

→ d=1 (WILL BREAK):
  - processCheckout (src/checkout.ts:42) [CALLS, 100%]
  - webhookHandler (src/webhooks.ts:15) [CALLS, 100%]

→ d=2 (LIKELY AFFECTED):
  - checkoutRouter (src/routes/checkout.ts:22) [CALLS, 95%]

gitnexus_impact with tests — check test coverage:

gitnexus_impact({target: "validatePayment", direction: "upstream", includeTests: true})

→ Tests that cover this symbol:
  - validatePayment.test.ts [direct]
  - checkout.integration.test.ts [via processCheckout]

gitnexus_context — understand a changed symbol's role:

gitnexus_context({name: "validatePayment"})

→ Incoming calls: processCheckout, webhookHandler
→ Outgoing calls: verifyCard, fetchRates
→ Processes: CheckoutFlow (step 3/7), RefundFlow (step 1/5)

Example: "Review PR #42"

1. gh pr diff 42 > /tmp/pr42.diff
   → 4 files changed: payments.ts, checkout.ts, types.ts, utils.ts

2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})
   → Changed symbols: validatePayment, PaymentInput, formatAmount
   → Affected processes: CheckoutFlow, RefundFlow
   → Risk: MEDIUM

3. gitnexus_impact({target: "validatePayment", direction: "upstream"})
   → d=1: processCheckout, webhookHandler (WILL BREAK)
   → webhookHandler is NOT in the PR diff — potential breakage!

4. gitnexus_impact({target: "PaymentInput", direction: "upstream"})
   → d=1: validatePayment (in PR), createPayment (NOT in PR)
   → createPayment uses the old PaymentInput shape — breaking change!

5. gitnexus_context({name: "formatAmount"})
   → Called by 12 functions — but change is backwards-compatible (added optional param)

6. Review summary:
   - MEDIUM risk — 3 changed symbols affect 2 execution flows
   - BUG: webhookHandler calls validatePayment but isn't updated for new signature
   - BUG: createPayment depends on PaymentInput type which changed
   - OK: formatAmount change is backwards-compatible
   - Tests: checkout.test.ts covers processCheckout path, but no webhook test

Review Output Format

Structure your review as:

## PR Review: <title>

**Risk: LOW / MEDIUM / HIGH / CRITICAL**

### Changes Summary
- <N> symbols changed across <M> files
- <P> execution flows affected

### Findings
1. **[severity]** Description of finding
   - Evidence from GitNexus tools
   - Affected callers/flows

### Missing Coverage
- Callers not updated in PR: ...
- Untested flows: ...

### Recommendation
APPROVE / REQUEST CHANGES / NEEDS DISCUSSION