Menu
Automated pull request review for your repos. Five parallel agents, confidence scoring, convention-file compliance, and GitHub comment posting.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | pr-code-review |
| description | Automated pull request review for your repos. Five parallel agents, confidence scoring, convention-file compliance, and GitHub comment posting. |
| status | active |
| version | 1 |
Purpose: Run an automated code review on any open PR in one of your repos before it merges. Five specialized agents analyze the diff from independent angles. Each finding is scored for confidence. Only high-confidence issues post to GitHub as a review comment.
Trigger: The operator invokes "PR Code Review" (or /pr-review) on a PR branch in a repo with open PRs.
Inputs: PR number or current branch (defaults to current branch if not specified).
Outputs: GitHub PR comment with numbered issues and full SHA links, or a no-issues confirmation.
Status: active
This skill assumes a convention file at the repo root, typically CLAUDE.md, but README.md, CONTRIBUTING.md or a .cursorrules file works the same way. Agent 1 (Convention Compliance) reads whatever convention file your repo uses and checks the diff against it.
If your team has mandatory standards that live in a separate document (a design system reference, an API style guide, a security checklist), name that document explicitly in Agent 1's brief so the lens checks against it too. If your convention file defines markup or content hygiene rules (title length limits, alt text requirements, heading structure), spot-check changed pages against those rules directly rather than relying on a general read.
The five-agent structure and the confidence-scoring gate transfer to any repo. The specific lenses in Step 4 are a starting set, not a fixed list. Add or swap a lens for what your codebase actually needs: accessibility, i18n, a specific framework's anti-patterns, a compliance requirement unique to your domain.
Keep this skill distinct from any deeper periodic audit your team runs (a scheduled architecture review, a full-codebase security pass). This skill is the lightweight per-PR gate before a merge: scoped to the diff, automated, runs every time. A deeper audit is manual, multi-phase and infrastructure-wide. One is a merge guard. The other is a scheduled structural review. Don't collapse them into one process.
This skill uses gh CLI for all GitHub interaction. Allowed tools are scoped to:
gh pr view, gh pr diff, gh pr list, gh pr comment
gh issue view, gh issue list, gh search
Do not use WebFetch for GitHub data. Use gh only.
Launch a Haiku agent to check whether the PR is eligible for review. Skip if any of the following are true:
If ineligible, halt and report why. Do not proceed.
Launch a Haiku agent to return a list of file paths to relevant convention files in the repo:
Return paths only, not file contents.
Launch a Haiku agent to view the PR and return:
Launch five Sonnet agents simultaneously. Each agent reads the PR diff and returns a list of issues with the reason each was flagged.
Agent 1: Convention Compliance Read the convention files identified in Step 2. Check whether the changes comply. Note: a convention file is guidance for the coding agent as it writes code, so not all instructions apply during review. Focus on instructions that clearly govern the kind of change being made. If your convention file names mandatory per-page or per-module standards, spot-check changed files against those standards explicitly.
Agent 2: Bug Scan (changes only) Read the file changes in the PR. Do a shallow scan for obvious bugs. Do not read extra context beyond the diff. Focus on large bugs. Avoid small issues and nitpicks. Ignore likely false positives.
Agent 3: Git History Context Read the git blame and history of the files modified. Identify any bugs in light of that historical context, patterns that were intentional, decisions that have been made before, constraints that are load-bearing.
Agent 4: Prior PR Comment Review Read previous PRs that touched the same files. Check for comments on those PRs that may also apply to the current change.
Agent 5: Code Comment Compliance Read code comments in the modified files. Check whether the changes comply with any guidance or constraints described in those comments.
For each issue found in Step 4, launch a parallel Haiku agent. Give each agent the PR, the issue description, and the convention file list from Step 2.
Pass this rubric to each scoring agent verbatim:
Score this issue on a scale from 0-100 indicating confidence that it is a real issue and not a false positive.
0: Not confident at all. This is a false positive that does not stand up to light scrutiny, or is a pre-existing issue.
25: Somewhat confident. This might be a real issue but may also be a false positive. The agent was not able to verify it is real. If the issue is stylistic, it is one not explicitly called out in the relevant convention file.
50: Moderately confident. The agent was able to verify this is a real issue but it might be a nitpick or not happen often in practice. Relative to the rest of the PR, it is not very important.
75: Highly confident. The agent double-checked the issue and verified it is very likely real and will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue directly mentioned in the relevant convention file.
100: Absolutely certain. The agent double-checked the issue and confirmed it is definitely real, will happen frequently in practice, and the evidence directly confirms this.
For issues flagged due to convention file instructions: double-check that the convention file actually calls out that issue specifically. If it does not, score lower.
Drop any issue with a confidence score below 80.
If no issues remain after filtering, proceed to Step 7. Do not post a comment yet.
Repeat the eligibility check from Step 1. The PR state may have changed while analysis was running. If the PR is now ineligible, halt without posting.
If issues remain after filtering, post a PR comment using gh pr comment. Follow this format exactly:
Found [N] issues:
[Link to file and line: full SHA, line range with at least 1 line of context on each side] https://github.com/[owner]/[repo]/blob/[full-sha]/[path/to/file]#L[start]-L[end]
[Link]
If no issues passed the filter, post:
No issues found. Checked for bugs and convention file compliance.
🤖 Generated with Claude Code
Link format rules:
gh pr view --json headRefOid to get the full SHA. Do not construct it from shell expansionhttps://github.com/[owner]/[repo]/blob/[full-sha]/[path]#L[start]-L[end]Comment style:
Do not flag any of the following categories. Pass this list to scoring agents to reduce noise:
Subagent dispatch: set model explicitly per the table below. Never silently inherit the orchestrator's model.
| Step | Model | Reason |
|---|---|---|
| 1, 7 | Haiku | Lightweight eligibility gate |
| 2 | Haiku | File path listing only |
| 3 | Haiku | PR summary |
| 4 (x5) | Sonnet | Deep parallel analysis |
| 5 (x N issues) | Haiku | Scoring with rubric |
| 8 | Direct (gh CLI) | Comment posting |
gh CLI for all GitHub operations. Do not use WebFetch for GitHub data.gh pr view --json headRefOid, never via shell variable expansion in the comment.Status is active. Execution is authorized on operator invocation. No pre-approval gate required beyond the Step 1 eligibility check.
This skill operates under an ambassador posture: it posts comments to public repositories on your behalf. Primary: hold the quality bar. Only high-confidence findings post. A false positive on a public PR costs credibility, not just review time. Secondary: every comment is a logged, citable artifact. The posted review is the trace, and it needs to be accurate. The 80 confidence threshold and the false positive taxonomy are both expressions of that boundary. They are not optional.
Source Harvest is the gateway skill for systematic pattern extraction from external repos and tools. Many users adopt Source Harvest first, then layer additional skills like this one on top.
Systematic Debugging is the discipline this skill defers to when something breaks mid-run. If a technical error surfaces during a review run, that skill's Phase 1 investigation runs before any retry attempt.
If Source Harvest isn't installed yet: Install Source Harvest via IGOS. If Systematic Debugging isn't installed yet: Install Systematic Debugging via IGOS.
(Empty. Populated when execution mistakes occur during sessions.)
Use when a long-form manuscript (book chapter, ebook, multi-chapter playbook, long-form digital product) needs an editing pass to identify and remove AI writing tells. Sweeps across 8 pattern categories, assembles a structured edit packet for operator review, and applies approved edits.
Use when you have spare capacity and want to set your system improving without active attention. Operator-invoked only, never scheduled. Safe, additive, reversible hygiene work runs under a threshold model with a permanent floor of actions the agent never takes on its own.
Use when archiving several workspace artifacts at once with per-artifact approval gates before any archive move executes.
Use when deciding whether a piece of deterministic, no-judgment work should route to a secondary AI provider instead of your primary interface. Covers the provider catalog, the five-condition eligibility test and the dispatch script.
Retire a stalled or indefinitely-deferred plan without losing its value. Candidate scan, harvest, distribute, sweep, archive and codify.
Use when the operator wants parallel sub-agent research aggregated into a structured report. Spawns up to 4 independent workers each investigating a different angle, then synthesizes findings for operator review. Research feeds decisions, does not trigger execution.