Agent Skills › tintinweb/pi-gitnexus › gitnexus-pr-review

gitnexus-pr-review

GitHub

用于审查 Pull Request，评估合并风险、变更影响范围及测试覆盖率。通过获取 Diff、映射受影响流程并分析依赖关系，提供包含正确性、破坏性变更及最终审批建议的结构化评审报告。

skills/gitnexus-pr-review/SKILL.md tintinweb/pi-gitnexus

Trigger Scenarios

用户请求审查 PR 询问 PR 的具体变更内容评估合并 PR 的安全性或风险

Install

npx skills add tintinweb/pi-gitnexus --skill gitnexus-pr-review -g -y

More Options

Use without installing

npx skills use tintinweb/pi-gitnexus@gitnexus-pr-review

指定 Agent (Claude Code)

npx skills add tintinweb/pi-gitnexus --skill gitnexus-pr-review -a claude-code -g -y

安装 repo 全部 skill

npx skills add tintinweb/pi-gitnexus --all -g -y

预览 repo 内 skill

npx skills add tintinweb/pi-gitnexus --list

SKILL.md

Frontmatter

{
    "name": "gitnexus-pr-review",
    "description": "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?\""
}

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?"
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. gitnexus_impact({target: "<symbol>", direction: "upstream"})       → Blast radius per change
4. gitnexus_context({name: "<key symbol>"})                           → Understand callers/callees
5. Summarize findings with risk assessment

If index is stale → run /gitnexus analyze 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

Review Output Format

## 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

Example: "Review PR #42"

1. gh pr diff 42
   → 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. Review summary:
   - MEDIUM risk — 3 changed symbols affect 2 execution flows
   - BUG: webhookHandler not updated for new validatePayment signature
   - BUG: createPayment depends on changed PaymentInput type
   - OK: formatAmount change is backwards-compatible