Review Pr
Run a structured pull-request review with knowledge-graph context, blast-radius checks, and caller/test lookups before merge.
Overview
review-pr is an agent skill most often used in Ship (also Build, Operate) that reviews a PR or branch diff with a knowledge graph for blast-radius and structured findings.
Install
npx skills add https://github.com/tirth8205/code-review-graph --skill review-prWhat is this skill?
- Five-step workflow: identify changes, refresh graph, get_review_context, get_impact_radius, then per-file deep-dives
- Blast-radius and high-risk dependency surfacing via get_impact_radius_tool
- Graph queries for callers_of and tests_for on changed symbols
- Token-optimized path via get_docs_section_tool(section_name="review-pr") before full file reads
- Auto-detects branch vs main/master or honors PR number / branch argument-hint
- 5 main workflow steps from identify changes through per-file deep-dive
- Token optimization via get_docs_section_tool before loading full files
Adoption & trust: 768 installs on skills.sh; 18.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a large PR and cannot see which widely depended-on code or missing tests make the merge risky.
Who is it for?
Solo maintainers reviewing feature branches or PRs in repos already wired to the code-review-graph tool suite.
Skip if: Greenfield repos with no graph tooling, or reviews that only need style nits without dependency or test linkage.
When should I use this skill?
Review a PR or branch diff using the knowledge graph for full structural context and structured blast-radius output.
What do I get? / Deliverables
You get a structured review with PR-wide context, blast-radius highlights, and per-function caller and test checks grounded in an updated graph.
- Structured PR review document
- Blast-radius and high-risk area summary
- Per-changed-file analysis with caller and test graph notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship/review is the canonical shelf because the workflow targets PR or branch diffs against main and structured merge readiness output. Review subphase matches explicit PR review, impact-radius analysis, and deep-dives on changed high-risk functions.
Where it fits
Run get_review_context and impact radius on a feature branch before approving merge to main.
Deep-dive a refactor PR with query_graph callers_of on exported APIs you changed.
Review a production hotfix branch with the same graph workflow to see downstream blast radius.
How it compares
Use instead of line-only diff chat when you need dependency blast radius and test coverage hints from a graph.
Common Questions / FAQ
Who is review-pr for?
Indie builders and small teams shipping through Git PRs who want graph-backed impact analysis, not just inline diff comments.
When should I use review-pr?
During Ship review before merge; during Build when validating a branch; during Operate when auditing a hotfix branch—whenever you have a base branch and graph tools available.
Is review-pr safe to install?
Treat it like any third-party skill: review the Security Audits panel on this Prism page and confirm graph/git tools only access repos you intend.
SKILL.md
READMESKILL.md - Review Pr
# 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 1. **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 2. **Update the graph** by calling `build_or_update_graph_tool(base="main")` to ensure the graph reflects the current state. 3. **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 4. **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) 5. **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 6. **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