Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
brave avatar

Review Prs

  • 6 installs
  • 3.5k repo stars
  • Updated August 5, 2026
  • brave/brave-core

review-prs is a Claude Code skill that scans recent pull requests in a configured repository for best-practice violations and posts capped inline review comments.

About

Scans recent pull requests in a configured repository for violations of documented best practices. It runs a file-based pipeline where prepare and collect scripts do the heavy fetching with zero LLM tokens and subagents review each diff, then posts capped inline review comments. It offers an interactive mode that asks for approval and an auto mode for cron. A developer or bot uses it to enforce best practices across a PR queue.

  • Scans open PRs for documented best-practice violations
  • File-based pipeline pushes heavy data through scripts, not the LLM
  • Interactive approval mode plus an auto mode for cron/headless runs

Review Prs by the numbers

  • 6 all-time installs (skills.sh)
  • Ranked #870 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

review-prs capabilities & compatibility

Free; requires gh CLI and python3 for the pipeline scripts.

Capabilities
code review · ci cd
Works with
github
Use cases
code review · ci cd
Runs
Runs locally
Pricing
Free
From the docs

What review-prs says it does

Scan recent open PRs in the configured PR repository for violations of documented best practices.
SKILL.md
This skill only reviews PRs against existing best practices. It must NEVER create, modify, or add new best practice rules or documentation during a review run.
SKILL.md
npx skills add https://github.com/brave/brave-core --skill review-prs

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs6
repo stars3.5k
Last updatedAugust 5, 2026
Repositorybrave/brave-core

What it does

Scan recent PRs in a repository for best-practice violations and post capped inline review comments.

Who is it for?

Teams or bots enforcing documented best practices across a queue of open PRs, including cron runs.

Skip if: Creating or modifying best-practice rules, which it must never do during a review run.

When should I use this skill?

You want to review recent PRs against existing best practices, interactively or via cron.

What you get

Violations are validated against source and posted as deduplicated, capped inline review comments.

By the numbers

  • 3-stage file-based pipeline (prepare, subagents, collect)
  • caps 5 violations per PR

Files

SKILL.mdMarkdownGitHub ↗

Review PRs for Best Practices

Scan recent open PRs in the configured PR repository for violations of documented best practices.

  • Interactive mode (default): drafts comments and asks for user approval

before posting.

  • Auto mode (auto argument): posts all violations automatically without

approval. Designed for cron/headless use.

IMPORTANT: This skill only reviews PRs against existing best practices. It must NEVER create, modify, or add new best practice rules or documentation during a review run.

---

Architecture: File-Based Pipeline

The review pipeline minimizes LLM token usage by pushing all heavy data through files, not context:

1. prepare-review.py (zero LLM tokens) — fetches PRs, diffs, comments; writes subagent prompt files to a temp work directory; outputs a tiny JSON pointer to the work dir 2. Subagents (subagent tokens only) — each reads its prompt from a file, reviews the diff, validates violations by reading source code, writes results to a JSON file 3. collect-results.py (zero LLM tokens) — reads all result files, feeds to post-review.py which handles prioritization, dedup, posting, approval, and notifications

The main LLM session only orchestrates: run scripts, read a small manifest, launch subagents with tiny prompts, run the collector. It never sees diffs, rule text, or violation details.

---

The Job

When invoked with /review-prs [days|page<N>|#<PR>] [open|closed|all] [auto] [reviewer-priority]:

Step 1: Prepare (zero LLM tokens)

Run the prepare script with all arguments:

SKILL_DIR="<absolute path to .claude/skills/review-prs>"
python3 $SKILL_DIR/prepare-review.py [days|page<N>|#<PR>] [open|closed|all] [--auto] [--reviewer-priority]

The script's stdout is a tiny JSON with work_dir and manifest paths. Progress and cost summary go to stderr.

Parse the stdout JSON to get work_dir.

Step 2: Read manifest

Read the manifest file at {work_dir}/manifest.json. It contains:

  • `auto_mode`: whether to post without approval
  • `bot_username`: the bot's GitHub username
  • `pr_repo`: the target PR repository
  • `fetch_summary`: stats on how many PRs were fetched/filtered/skipped
  • `progress_lines`: pre-formatted progress messages — print these to stdout

for cron logs

  • `prs`: array of PRs to review, each containing:
  • number, title, headRefOid, author, hasApproval
  • subagent_prompts: array of entries with prompt_file and results_file

paths (NOT prompt text)

  • `cached_prs`: already-reviewed PRs (handled by prepare script — just log

results)

  • `errors`: per-PR errors encountered during preparation

Print the progress_lines. Log any errors.

For each cached PR, log:

  • If approved is true:

APPROVE: [PR #N](url) (title) - all threads resolved, approved

  • If thread_resolution.unresolved_bot_threads > 0:

CACHED: [PR #N](url) (title) - N threads still unresolved

If no PRs to review (empty prs array), skip to Step 4.

Step 3: Launch subagents

For every PR in prs, for every entry in that PR's subagent_prompts, launch a Task subagent (subagent_type: "general-purpose") with this prompt:

Read your full review instructions from: {prompt_file}
Execute them completely. The instructions contain the PR diff, best practice rules, review rules, and validation requirements.
After reviewing and validating, write your results JSON to the file path specified in the instructions.

Launch ALL subagents across ALL PRs in a single message so they run concurrently.

CRITICAL: Launch ALL subagents — no exceptions. The prepare script already filtered documents by file type. Every entry in subagent_prompts MUST get a subagent. Do NOT skip any.

Wait for all subagents to return.

CRITICAL: NEVER post reviews, comments, or approvals to GitHub yourself. Do NOT use gh api, gh pr review, gh pr comment, or any GitHub API calls to post anything on any PR. All posting is handled exclusively by collect-results.pypost-review.py in Step 4. If you post reviews directly, it creates duplicates.

Step 4: Collect and post (zero LLM tokens)

Run the collector script — it reads all subagent result files and runs post-review.py:

python3 $SKILL_DIR/collect-results.py --work-dir "$WORK_DIR" [--auto]

Pass --auto if auto_mode is true.

The script handles everything: collecting violations from result files, prioritization/capping (5 per PR), rule link validation, deduplication, posting inline reviews, approval for clean PRs, cache updates, and the final summary block.

For interactive mode (no --auto): instead of running collect-results.py directly, read the result files yourself from {work_dir}/pr_{number}/{chunk_id}_results.json, present each violation to the user for approval, then write only approved violations back and run collect-results.py.

Read the script's stderr — it contains the summary. Print it for cron logs.

Summary of what consumes LLM tokens

PhaseToken costWho does it
Fetch PRs, diffs, commentsZeroprepare-review.py
Build subagent prompts (files)Zeroprepare-review.py
Resolve threads, check approvalZeroprepare-review.py
Read manifest, launch subagents~50 tokens per subagentMain LLM session
Rule-checking + validationSubagent tokensSubagents (read prompt from file)
Collect results, post, approveZerocollect-results.py + post-review.py

---

PR Link Format

When displaying PR numbers, ALWAYS use a full markdown link: [PR #<number>](https://github.com/$PR_REPO/pull/<number>). NEVER use bare #<number> — the TUI auto-links them against the wrong repository.

---

Closed/Merged PR Workflow

When reviewing closed or merged PRs and a violation is found:

1. Present the finding to the user (draft comment + ask for approval) 2. If approved, try to post inline review comments. If the API fails, fall back to:

   gh pr comment --repo $PR_REPO {number} --body "[file:line] comment text"

3. Create a follow-up issue in $PR_REPO to track the fix:

   gh issue create --repo $PR_REPO --title "Fix: <brief description>" --body "Found during post-merge review of PR #<NUMBER>. <description>"

4. Reference the new issue back in the PR comment.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.