agentleFS
Sign inStart free
ArcQian-bitArcQian-bit/codex-real-engineer-skills/skills/pr-reviewer/SKILL.md

pr-reviewer

Skill1 starsChanged 5 months agoMITView on GitHub

Review pull requests, diffs, commits, and local changes for bugs, regressions, missing verification, and maintainability risks. Use when the user asks for a review, PR review, diff review, pre-merge check, or "what could break". Do not use for broad architecture mapping without a specific diff or for security-only audits where security-scout is more specific.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Look for concrete regressions before style comments.

    line 14
  2. Distinctive:

    Verify whether tests cover the changed behavior and failure modes.

    line 15
  3. Distinctive:

    Do not praise before findings.

    line 39
  4. Distinctive:

    Do not list nits unless the user asked for polish.

    line 40
  5. Distinctive:

    If no issues are found, say so and name residual risk or test gaps.

    line 41
  6. Distinctive:

    Prefer file/line references over general advice.

    line 42
  7. Distinctive:

    Do not request changes for code that is merely different from personal taste.

    line 43

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

PR Reviewer

Review like a maintainer who must protect users.

Review Order

  1. Understand the stated intent from PR title, issue, commit message, or user prompt.
  2. Inspect the diff and nearby code that defines behavior, contracts, and tests.
  3. Look for concrete regressions before style comments.
  4. Verify whether tests cover the changed behavior and failure modes.
  5. Report only actionable findings.

Finding Format

Lead with findings, ordered by severity:

[P1] Short title
File: path/to/file.ext:line
Risk: what breaks and for whom.
Why: the evidence from code or behavior.
Fix: the smallest useful direction.

Use priorities:

  • P0: data loss, security exposure, crash loop, or release blocker.
  • P1: likely user-visible bug or serious regression.
  • P2: correctness, compatibility, or missing-test risk.
  • P3: maintainability issue worth fixing, not merge-blocking.

Rules

  • Do not praise before findings.
  • Do not list nits unless the user asked for polish.
  • If no issues are found, say so and name residual risk or test gaps.
  • Prefer file/line references over general advice.
  • Do not request changes for code that is merely different from personal taste.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free