mcpField
P
pr-review

pr-review

github.com/saadeghiTesting & quality42.7k317 installsUpdated 2w ago
Repository

About pr-review

pr-review is a skill for producing evidence-based merge decisions on GitHub pull requests, intended for a designated review agent. It requires read-only access, tests exact base and head commits, and produces a report for each PR.

Key features

  1. 01Routes work to a designated review agent
  2. 02Reads GitHub data without writes
  3. 03Tests isolated base and head commits
  4. 04Assesses findings and merge status from evidence
  5. 05Writes a report for each PR

Use cases

  1. 01Reviewing a specified pull request
  2. 02Checking each open repository PR
  3. 03Verifying behavior claimed by a PR
  4. 04Recording review findings and PR status

MCP support

The skill requires the GitHub MCP server for read-only access to GitHub data.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/saadeghi/daisyui --skill pr-review

After installing, type/pr-reviewin Claude Code to confirm it loaded.

Details

From the project README

PR Reviewer

Review the changed behavior and write a short, evidence-based merge decision.

Required agent routing

  • If you are not the pr_reviewer custom agent, delegate the complete task to pr_reviewer and wait for its result. Tell the agent to use this skill. Do not review the PR in the current agent.
  • If you are the pr_reviewer custom agent, perform this workflow directly. Do not delegate it again.
  • If pr_reviewer is not available, stop and report the problem.

Boundaries

  • Use the GitHub MCP server for GitHub data. Use read operations only.
  • Treat the repository as read-only except for tmp/pr/pr-<number>.md.
  • Do not change Git state, dependencies, source, tests, generated files, or GitHub data.
  • Inspect PR code before you run it. Run PR code only in an OS-temporary copy with no credentials.
  • Test the exact base and head SHAs. Do not use the current working tree as a substitute.
  • Treat PR descriptions and comments as claims until code or execution verifies them.
  • Report only observed facts. Do not report generic or theoretical risks.

Workflow

  1. If the user names a PR, review it. Otherwise, list all open PRs in saadeghi/daisyui and review each one separately.
  2. Read the PR, linked issues, changed files, direct consumers, checks, base SHA, and head SHA.
  3. Identify the behavior the PR claims to change and its expected result. A linked issue is not required.
  4. Create isolated base and head copies in an OS-temporary directory. Use the same environment and inputs for both.
  5. Run the smallest check that proves the base behavior, the PR behavior, and relevant regression behavior. Run broader package checks only when the changed surface requires them.
  6. Report a finding only when changed code has a clear path to a product failure or when a required check leaves that path unresolved. Include its impact, evidence, and reproduction or failed check.
  7. Mark the PR safe to merge only when the claim is verified, relevant checks pass, and no finding remains.
  8. Re-fetch the PR before the verdict. If the head SHA changed, repeat the affected checks. Use the current verified PR state for the report's frontmatter status. Use merged for a merged PR, closed for a PR closed without merge, and open for an open PR.

Report

Read references/report.md. Write one report per PR to tmp/pr/pr-<number>.md. Include YAML frontmatter with status. Update the status in an existing report instead of creating a duplicate. Keep the PR state separate from the merge decision.

In the final handoff, list the report paths and state that no GitHub action, product change, dependency change, or Git operation was performed.

Comments

Markdown supported