review-pr
installsforks
How to install review-pr?
neolabhq/context-engineering-kit/review-pr
$npx -y skills add NeoLabHQ/context-engineering-kit --skill review-prReview an existing GitHub pull request and post inline review comments on its diff. Use when the changes are on an opened PR rather than your local working tree.
SKILL.md
| 1 | # Pull Request Review Instructions |
| 2 | |
| 3 | You are an expert code reviewer conducting a thorough evaluation of this pull request. Your review must be structured, systematic, and provide actionable feedback. |
| 4 | |
| 5 | **User Input:** |
| 6 | |
| 7 | ```text |
| 8 | $ARGUMENTS |
| 9 | ``` |
| 10 | |
| 11 | **IMPORTANT**: Skip reviewing changes in `spec/` and `reports/` folders unless specifically asked. |
| 12 | |
| 13 | **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! |
| 14 | |
| 15 | --- |
| 16 | |
| 17 | ## Command Arguments |
| 18 | |
| 19 | Parse the following arguments from `$ARGUMENTS`: |
| 20 | |
| 21 | ### Argument Definitions |
| 22 | |
| 23 | | Argument | Format | Default | Description | |
| 24 | |----------|--------|---------|-------------| |
| 25 | | `review-aspects` | Free text | None | Optional review aspects or focus areas for the review (e.g., "security, performance") | |
| 26 | | `--min-impact` | `--min-impact <level>` | `high` | Minimum impact level for issues to be published as inline comments. Values: `critical`, `high`, `medium`, `medium-low`, `low` | |
| 27 | |
| 28 | ### Impact Level Mapping |
| 29 | |
| 30 | | Level | Impact Score Range | |
| 31 | |-------|-------------------| |
| 32 | | `critical` | 81-100 | |
| 33 | | `high` | 61-80 | |
| 34 | | `medium` | 41-60 | |
| 35 | | `medium-low` | 21-40 | |
| 36 | | `low` | 0-20 | |
| 37 | |
| 38 | ### Configuration Resolution |
| 39 | |
| 40 | Parse `$ARGUMENTS` and resolve configuration as follows: |
| 41 | |
| 42 | ``` |
| 43 | # Extract review aspects (free text, everything that is not a flag) |
| 44 | REVIEW_ASPECTS = all non-flag text from $ARGUMENTS |
| 45 | |
| 46 | # Parse flags |
| 47 | MIN_IMPACT = --min-impact || "high" |
| 48 | |
| 49 | # Resolve minimum impact score from level name |
| 50 | MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping: |
| 51 | "critical" -> 81 |
| 52 | "high" -> 61 |
| 53 | "medium" -> 41 |
| 54 | "medium-low" -> 21 |
| 55 | "low" -> 0 |
| 56 | ``` |
| 57 | |
| 58 | ## Review Workflow |
| 59 | |
| 60 | Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality. Follow these steps precisely: |
| 61 | |
| 62 | ### Phase 1: Preparation |
| 63 | |
| 64 | Run following commands in order: |
| 65 | |
| 66 | 1. **Determine Review Scope** |
| 67 | - Check following command to understand changes, use only commands that return amount of lines changed, not file content: |
| 68 | - git status |
| 69 | - git diff --stat |
| 70 | - git diff origin/master --stat or git diff origin/master...HEAD --stat for PR diffs |
| 71 | - change to origin/main if main is used as default branch |
| 72 | - Parse `$ARGUMENTS` per the Command Arguments section above to resolve `REVIEW_ASPECTS`, `MIN_IMPACT`, and `MIN_IMPACT_SCORE` |
| 73 | 2. Launch up to 6 parallel Haiku agents to perform following tasks: |
| 74 | - 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. |
| 75 | - 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 |
| 76 | - Split files based on amount of lines changes between other 1-4 agents and ask them following: |
| 77 | |
| 78 | ```markdown |
| 79 | GOAL: Analyse PR changes in following files and provide summary |
| 80 | |
| 81 | Perform following steps: |
| 82 | - Run [pass proper git command that he can use] to see changes in files |
| 83 | - Analyse following files: [list of files] |
| 84 | |
| 85 | 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. |
| 86 | ``` |
| 87 | |
| 88 | 3. CRITICAL: If PR missing description, add a description to the PR with summary of changes in short and concise format. |
| 89 | |
| 90 | ### Phase 2: Searching for Issues |
| 91 | |
| 92 | Determine Applicable Reviews, then launch up to 6 parallel (Sonnet or Opus) agents to independently code review all changes in the pull request. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md or consitution.md adherence, bug, historical git context, etc.). |
| 93 | |
| 94 | **Available Review Agents**: |
| 95 | |
| 96 | - **security-auditor** - Analyze code for security vulnerabilities |
| 97 | - **bug-hunter** - Scan for bugs and issues, including silent failures |
| 98 | - **code-quality-reviewer** - General code review for project guidelines, maintainability and quality. Simplifying code for clarity and maintainability |
| 99 | - **contracts-reviewer** - Analyze code contracts, including: type design and invariants (if new types added), API changes, data modeling, etc. |
| 100 | - **test-coverage-reviewer** - Review test coverage quality and completeness |
| 101 | - **historical-context-reviewer** - Review historical context o |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
