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本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
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
$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. 下の青いボタンを押して
gitnexus-pr-review.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
gitnexus-pr-reviewフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
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 analyzein 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