
Review Pr
Run structured pull-request reviews that post only high-signal inline comments with configurable minimum impact.
Overview
Review-pr is an agent skill most often used in Ship (also Build integrations) that conducts systematic pull-request reviews and publishes only inline comments filtered by impact level.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill review-prWhat is this skill?
- Parses optional focus aspects and `--min-impact` threshold (default high).
- Maps five impact bands from critical (81–100) down to low (0–20).
- Mandates inline comments only—no standalone overall review report.
- Skips `spec/` and `reports/` diffs unless the user explicitly requests them.
- Routes review through specialized agents for structured, actionable feedback.
- Five `--min-impact` levels with mapped impact score ranges (critical 81–100 through low 0–20).
- Default minimum impact level is high.
Adoption & trust: 518 installs on skills.sh; 1.1k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need consistent PR critique without a wall of generic summary text or low-value nitpicks cluttering the review thread.
Who is it for?
Solo builders shipping from feature branches who want agent-assisted review with explicit severity filtering and diff-only commentary.
Skip if: Teams that require a formal overall approval summary, full-repo audits outside the PR diff, or deep review of `spec/` and `reports/` without opting in.
When should I use this skill?
A pull request needs thorough, structured review with optional aspect focus and inline-only feedback.
What do I get? / Deliverables
The agent leaves targeted inline comments on changed lines at or above your chosen impact threshold, ready for authors to fix before merge.
- Inline PR comments on specific lines at or above the configured impact level
- No overall review report (by design)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is invoked on open PRs before merge, aligning with pre-release quality gates. Subphase review matches systematic PR evaluation rather than unit testing or security-only audits.
Where it fits
Finish an API integration branch and run review-pr with aspects "security" before opening the PR.
On an open PR, default `--min-impact high` to surface only merge-worthy inline findings.
Pass review-aspects including security when shipping auth changes to a SaaS backend.
Re-run on a hotfix PR with `--min-impact critical` during an incident follow-up merge.
How it compares
Use instead of ad-hoc “review this PR” chat that dumps a long narrative report with no impact gating.
Common Questions / FAQ
Who is review-pr for?
Indie developers and small teams using agent-assisted Git workflows who want structured PR feedback posted as inline comments on the diff.
When should I use review-pr?
In Ship during pre-merge review on an open PR; also in Build when finishing a feature branch before you open the PR, especially when you pass focus aspects like security or performance.
Is review-pr safe to install?
Treat it like any skill that reads repository code and may comment on PRs—review the Security Audits panel on this page and confirm it only touches the PR scope you intend.
SKILL.md
READMESKILL.md - Review Pr
# Pull Request Review Instructions You are an expert code reviewer conducting a thorough evaluation of this pull request. Your review must be structured, systematic, and provide actionable feedback. **User Input:** ```text $ARGUMENTS ``` **IMPORTANT**: Skip reviewing changes in `spec/` and `reports/` folders unless specifically asked. **CRITICAL**: You must post inline comments only! Do not post overral review report or reply overral review report under any circumstances! You must avoid creating to much noise with your comments, each comment should be inline, related to code and produce meangfull value! --- ## Command Arguments Parse the following arguments from `$ARGUMENTS`: ### Argument Definitions | Argument | Format | Default | Description | |----------|--------|---------|-------------| | `review-aspects` | Free text | None | Optional review aspects or focus areas for the review (e.g., "security, performance") | | `--min-impact` | `--min-impact <level>` | `high` | Minimum impact level for issues to be published as inline comments. Values: `critical`, `high`, `medium`, `medium-low`, `low` | ### Impact Level Mapping | Level | Impact Score Range | |-------|-------------------| | `critical` | 81-100 | | `high` | 61-80 | | `medium` | 41-60 | | `medium-low` | 21-40 | | `low` | 0-20 | ### Configuration Resolution Parse `$ARGUMENTS` and resolve configuration as follows: ``` # Extract review aspects (free text, everything that is not a flag) REVIEW_ASPECTS = all non-flag text from $ARGUMENTS # Parse flags MIN_IMPACT = --min-impact || "high" # Resolve minimum impact score from level name MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping: "critical" -> 81 "high" -> 61 "medium" -> 41 "medium-low" -> 21 "low" -> 0 ``` ## Review Workflow Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality. Follow these steps precisely: ### Phase 1: Preparation Run following commands in order: 1. **Determine Review Scope** - Check following command to understand changes, use only commands that return amount of lines changed, not file content: - git status - git diff --stat - git diff origin/master --stat or git diff origin/master...HEAD --stat for PR diffs - change to origin/main if main is used as default branch - Parse `$ARGUMENTS` per the Command Arguments section above to resolve `REVIEW_ASPECTS`, `MIN_IMPACT`, and `MIN_IMPACT_SCORE` 2. Launch up to 6 parallel Haiku agents to perform following tasks: - One agent to check if the pull request (a) is closed, (b) is a draft. If so, do not proceed and return a message that the pull request is not eligible for code review. - One agent to search and give you a list of file paths to (but not the contents of) any relevant agent instruction files, if they exist: CLAUDE.md, AGENTS.md, **/consitution.md, the root README.md file, as well as any README.md files in the directories whose files the pull request modified - Split files based on amount of lines changes between other 1-4 agents and ask them following: ```markdown GOAL: Analyse PR changes in following files and provide summary Perform following steps: - Run [pass proper git command that he can use] to see changes in files - Analyse following files: [list of files] Please return a detailed summary of the changes in the each file, including types of changes, their complexity, affected classes/functions/variables/etc., and overall description of the changes. ``` 3. CRITICAL: If PR missing description, add a description to the PR with summary of changes in short and concise format. ### Phase 2: Searching for Issues Determine Applicable Reviews, then l