agentleFS
Sign inStart free
y-miyazakiy-miyazaki/config/.agents/skills/github-pr-review/SKILL.md

github-pr-review

Skill1 starsChanged 9 days agoApache-2.0View on GitHub

Review a pull request once and write an evidence-backed review report (JSON) for a later step to post. Use in conversation when the user gives a PR URL or number and asks for a review. Also the L2 loop entry skill on newly opened PRs when detect JSON is supplied. Findings need a verbatim rule or criteria quote from the base commit, or a concrete bug in the diff. Never posts, approves, or edits source files; do not use to fix a PR (github-pr-revise).

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use git-commit, code-review and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    git-commit

    Stage user-selected paths, confirm the exact staged set, and create one local Conventional Commit, or generate a commit message for staged changes without committing. Use when you want a guarded commit or a ready-to-paste message.

    Also in 4 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When agent_edit_allowed is true, resolve agent_edit_target: on the interactive path use report.

    line 62
  2. Very specific:

    Do not post. Do not run gh pr review, gh pr comment, gh api write calls, or any engine --comment option.

    line 71

“Common” is measured: kept by at least 6 in 10 of the 17 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

UTILITY SKILL — first-pass PR review that produces a report file; the platform renders and posts it.

Input

  • Automation: detect JSON from detect_pr_review.sh with result.pr_number, result.base_sha, result.head_sha, result.changed_files, result.report_path, and result.handoff_key. Read agent_edit_allowed / agent_edit_target / response_language from ## Constraints.
  • Interactive: PR URL or number; there is no detect JSON. Resolve SHAs with read-only gh pr view <n> --json baseRefOid,headRefOid (base = baseRefOid, head = headRefOid). Default: present findings in chat and write no file; when the user asks for a report file, write it to the path the user names.

Output Specification

Report file schema and rendering: common-output-format.md. Automation envelope: category-automation-envelope.md. Evidence and exclusion rules: category-review-rules.md.

Execution Scope

USE FOR:

  • Reviewing the PR diff against agent instruction rules and domain review criteria that exist at the base commit
  • Reporting generic correctness bugs that can be shown with a diff line and a concrete failing input or state
  • Writing the review report to result.report_path when agent_edit_target is report

DO NOT USE FOR:

  • Fixing, committing, or pushing code (use github-pr-revise)
  • Posting reviews or comments, approving, or requesting changes (the platform renders the report and posts one COMMENT review)
  • Issue triage or lint, format, and secret scanning (hooks and CI already run these)

Reference Files Guide

  • common-checklist.md (always read)
  • common-output-format.md (always read)
  • category-review-rules.md (always read)
  • category-automation-envelope.md (read on automation path)
  • category-pr-body-links.md (read when writing the report)
  • assets/report-template.json (read when writing the report)
  • assets/review-body-template.md (read to see how the report is rendered into the review body)
  • assets/inline-comment-template.md (read to see how in-diff findings are rendered inline)

Workflow

Resolve agent_edit_allowed before writing anything:

Sourceagent_edit_allowed
Interactive — defaultfalse — survey only; write no file
Interactive — explicit apply languagetrue — user asks to write the report file in the same request
Automation — ## Constraintsagent_edit_allowed: true or agent_edit_allowed: false from category-automation-envelope.md

When agent_edit_allowed is true, resolve agent_edit_target: on the interactive path use report; on the automation path read agent_edit_target from ## Constraints. Do not branch on other caller metadata outside ## Constraints. The report file is the only file this skill may write.

  1. Automation: read detect JSON; if skip: true or status: error, report the reason and stop without writing a report. Interactive: resolve the PR from the user's URL or number and its SHAs with gh pr view <n> --json baseRefOid,headRefOid.
  2. Confirm the PR's intent: read the PR title and body, linked Issues, and any related spec or design document. Record the result for premises.
  3. Read the PR diff with gh pr diff. Read each changed file at base with git show <base_sha>:<path> (never from the checked-out tree, which may be the PR head), and the head version with gh api / gh pr diff. On the automation path the working tree is the base checkout, so opening files there is equivalent.
  4. Collect applicable rules: read applicable instruction files (nested and path-scoped included) from the base commit with git show <base_sha>:<path>, and domain review criteria matching each changed file type, also from base. Domain criteria are ID-tagged items in review references that exist in the consumer repository at the base commit (for example installed review skills' references/category-*.md); this skill ships none of its own. When none exist for a file type, use only rule and bug evidence for that file. Never read rules from the PR head.
  5. Draft findings limited to the three evidence kinds in category-review-rules.md. Exclude pre-existing problems and every item in the "do not report" list.
  6. Drop findings you cannot support with evidence, and findings with low confidence.
  7. Decide the response language per Response language. Automation: write the report as JSON to result.report_path following assets/report-template.json, and copy head_sha and base_sha from detect result.head_sha / result.base_sha; a missing or stale head_sha makes the platform refuse to post. Interactive: when agent_edit_allowed is false, present the findings in chat and write no file; when agent_edit_allowed is true, write the same JSON to the path the user names, with head_sha / base_sha from gh pr view.
  8. Do not post. Do not run gh pr review, gh pr comment, gh api write calls, or any engine --comment option. gh is read-only here.

Error Handling

ConditionSeverityAction
Detect status: errorFatalStop; write no report
Detect skip: trueInfoReport skip reason; write no report
agent_edit_allowed: falseInfoSurvey only; write no file
agent_edit_target not reportRecoverableSurvey only; note expected agent_edit_target: report
PR intent cannot be read (body, Issue)RecoverableRecord none in premises; keep only findings that stand on their own
Quote cannot be found verbatim at baseRecoverableDrop the finding; do not paraphrase
User asks to fix or implement the feedbackInfoDo not edit files; point to github-pr-revise and stop

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