Review Changes
Run a graph-backed, risk-scored review of a diff with blast radius, test gaps, and a merge recommendation before you merge.
Overview
Review Changes is an agent skill for the Ship phase that performs a structured, risk-aware code review using graph change detection, flow impact, test coverage checks, and a merge recommendation.
Install
npx skills add https://github.com/tirth8205/code-review-graph --skill review-changesWhat is this skill?
- Five-step workflow: detect_changes → affected flows → tests_for coverage → impact radius → test suggestions for gaps
- Findings grouped by high/medium/low risk with merge recommendation
- Token budget: start with get_minimal_context, detail_level minimal, ≤5 tool calls and ≤800 output tokens
- Flags untested high-risk functions and proposes specific test cases
- ≤800 total output tokens
- 5 numbered review steps
Adoption & trust: 685 installs on skills.sh; 18.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a diff but no ordered way to see blast radius, test gaps, and merge risk without burning tokens on noisy exploration.
Who is it for?
Solo builders using code-review-graph MCP tools who want pre-merge reviews tied to execution paths and test coverage.
Skip if: Repos without the graph stack, purely stylistic review, or changes where you refuse graph tools and minimal-context discipline.
When should I use this skill?
Perform a thorough, risk-aware code review using the knowledge graph (detect_changes, flows, tests, impact radius).
What do I get? / Deliverables
You get high/medium/low findings, coverage status, suggested tests for gaps, and a clear merge recommendation after a bounded graph review workflow.
- risk-grouped findings (high/medium/low)
- test coverage status
- merge recommendation
Recommended Skills
Journey fit
How it compares
Use for impact-graph review workflows instead of ad-hoc 'read the PR' chat without detect_changes and get_impact_radius.
Common Questions / FAQ
Who is review changes for?
Developers and agent users on projects wired to code-review-graph who need risk-scored reviews before merge.
When should I use review changes?
In Ship/review when you have a changeset to land—after feature work in Build and before release prep—especially when high-risk functions need tests_for checks.
Is review changes safe to install?
Review the Security Audits panel on this Prism page and only grant the graph/MCP permissions your environment requires.
SKILL.md
READMESKILL.md - Review Changes
## Review Changes Perform a thorough, risk-aware code review using the knowledge graph. ### Steps 1. Run `detect_changes` to get risk-scored change analysis. 2. Run `get_affected_flows` to find impacted execution paths. 3. For each high-risk function, run `query_graph` with pattern="tests_for" to check test coverage. 4. Run `get_impact_radius` to understand the blast radius. 5. For any untested changes, suggest specific test cases. ### Output Format Provide findings grouped by risk level (high/medium/low) with: - What changed and why it matters - Test coverage status - Suggested improvements - Overall merge recommendation ## Token Efficiency Rules - ALWAYS start with `get_minimal_context(task="<your task>")` before any other graph tool. - Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. - Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens.