Skill

review-pr

Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.

Install

npx claudepluginhub demon24ru/code-review-graph

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Perform a comprehensive code review of a pull request or branch diff using the knowledge graph.

SKILL.md

Similar Skills

design-system

Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.

team-skills-platform

167.4k

ui-demo

Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.

team-skills-platform

167.4k

kotlin-patterns

Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.

team-skills-platform

167.4k

Stats

Stars6

Forks3

Last CommitApr 23, 2026

Actions

View Source View Plugin View on GitHub View README

Review PR

Perform a comprehensive code review of a pull request or branch diff using the knowledge graph.

Token optimization: Before starting, call get_docs_section_tool(section_name="review-pr") for the optimized workflow. Never include full files unless explicitly asked.

Steps

Identify the changes for the PR:

If a PR number or branch is provided, use git diff main...<branch> to get changed files
Otherwise auto-detect from the current branch vs main/master

Update the graph by calling build_or_update_graph_tool(base="main") to ensure the graph reflects the current state.

Get the full review context by calling get_review_context_tool(base="main"):

This uses main (or the specified base branch) as the diff base
Returns all changed files across all commits in the PR
On large PRs, call with summary_only=True first to gauge scope before loading full node arrays

Analyze impact by calling get_impact_radius_tool(base="main"):

Review the blast radius across the entire PR
Identify high-risk areas (widely depended-upon code)

Deep-dive each changed file:

Read the full source of files with significant changes
Use query_graph_tool(pattern="callers_of", target=<func>) for high-risk functions
Use query_graph_tool(pattern="tests_for", target=<func>) to verify test coverage
Check for breaking changes in public APIs

Generate structured review output:

## PR Review: <title>

### Summary
<1-3 sentence overview>

### Risk Assessment
- **Overall risk**: Low / Medium / High
- **Blast radius**: X files, Y functions impacted
- **Test coverage**: N changed functions covered / M total

### File-by-File Review
#### <file_path>
- Changes: <description>
- Impact: <who depends on this>
- Issues: <bugs, style, concerns>

### Missing Tests
- <function_name> in <file> - no test coverage found

### Recommendations
1. <actionable suggestion>
2. <actionable suggestion>

Tips

For large PRs, focus on the highest-impact files first (most dependents)

Use semantic_search_nodes_tool to find related code the PR might have missed

Check if renamed/moved functions have updated all callers

Review PR

Perform a comprehensive code review of a pull request or branch diff using the knowledge graph.

Token optimization: Before starting, call get_docs_section_tool(section_name="review-pr") for the optimized workflow. Never include full files unless explicitly asked.

Steps

Identify the changes for the PR:

If a PR number or branch is provided, use git diff main...<branch> to get changed files
Otherwise auto-detect from the current branch vs main/master

Update the graph by calling build_or_update_graph_tool(base="main") to ensure the graph reflects the current state.

Get the full review context by calling get_review_context_tool(base="main"):

This uses main (or the specified base branch) as the diff base
Returns all changed files across all commits in the PR
On large PRs, call with summary_only=True first to gauge scope before loading full node arrays

Analyze impact by calling get_impact_radius_tool(base="main"):

Review the blast radius across the entire PR
Identify high-risk areas (widely depended-upon code)

Deep-dive each changed file:

Read the full source of files with significant changes
Use query_graph_tool(pattern="callers_of", target=<func>) for high-risk functions
Use query_graph_tool(pattern="tests_for", target=<func>) to verify test coverage
Check for breaking changes in public APIs

Generate structured review output:

## PR Review: <title>

### Summary
<1-3 sentence overview>

### Risk Assessment
- **Overall risk**: Low / Medium / High
- **Blast radius**: X files, Y functions impacted
- **Test coverage**: N changed functions covered / M total

### File-by-File Review
#### <file_path>
- Changes: <description>
- Impact: <who depends on this>
- Issues: <bugs, style, concerns>

### Missing Tests
- <function_name> in <file> - no test coverage found

### Recommendations
1. <actionable suggestion>
2. <actionable suggestion>

Tips

For large PRs, focus on the highest-impact files first (most dependents)

Use semantic_search_nodes_tool to find related code the PR might have missed

Check if renamed/moved functions have updated all callers