agentleFS
Sign inStart free
frostneyfrostney/pascal-mcp-sdk/.agents/skills/review-pr/SKILL.md

review-pr

Skill2 starsChanged 3 months agoMITView on GitHub

Resolves current pull-request review findings in place, validates and pushes fixes, and can autonomously converge and merge an opted-in pull request. Use when the user runs /review-pr or /review-pr automatic-merge.

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 175 edited versions we read keep these.

  • 4

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Treat review, approval, and CI evidence as valid only for the current PR head.

    line 32
  2. Distinctive:

    Read the current head, PR diff, unresolved threads, top-level review findings, active review tools and their terminal states, required …

    line 53
  3. Very specific:

    If resolve-reviews is registered, use it for thread mechanics while keeping this skill's invariants.

    line 56
  4. Distinctive:

    Run checks relevant to the changed behavior, including rendered UI and accessibility checks for user-facing changes.

    line 62
  5. Very specific:

    Use /update-pr to commit and push.

    line 64
  6. Distinctive:

    Stop without merging for a material product decision, unrelated failure, unsafe or divergent PR, unavailable terminal external dependency, …

    line 74

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

Review PR

Resolve the current PR's actionable review findings without creating a second review conversation. With the exact automatic-merge qualifier, converge the PR and merge it.

Invariants

  • Preserve unrelated work. Never amend, force-push, or revert changes you did not author.
  • Reply only in the originating review thread when a reply is useful. Do not post top-level PR summaries or issue comments. In automatic-merge mode, a documented review-tool retrigger command is the only allowed top-level comment.
  • Validate findings before changing code and run the relevant project checks after fixes.
  • Discover active review tools from current repository configuration, branch protection, checks, and PR activity. Do not hardcode one provider or require an integration that is disabled, historical, or merely installed.
  • Treat review, approval, and CI evidence as valid only for the current PR head. A new commit or baseline merge resets every affected gate.

Automatic merge

The exact automatic-merge qualifier authorizes relevant fixes, validation, new commits, plain pushes, documented reviewer retriggers, monitoring, one squash merge, source-branch deletion, and local cleanup under git-workflow. Normal /review-pr remains non-merging. An explicit read-only instruction remains non-mutating and disables automatic merge.

An active review tool is a merge gate when repository policy or the current PR shows it was intentionally invoked. Inspect inline threads plus top-level reviews, summaries, suggestions, and nitpicks. For CodeRabbit when active, a rate limit, quota response, incomplete run, or missing verdict is pending rather than passed; apply equivalent evidence-based semantics to other tools.

Workflow

  1. Confirm the branch has an open PR and merge the remote default branch if behind.
  2. Read the current head, PR diff, unresolved threads, top-level review findings, active review tools and their terminal states, required checks, affected code, and applicable project instructions.
  3. If resolve-reviews is registered, use it for thread mechanics while keeping this skill's invariants. Otherwise handle the threads directly.
  4. Evaluate every current finding. Fix validated in-scope findings; reply inline when acknowledgement, clarification, or a question is needed; resolve completed threads. Dismiss invalid, obsolete, duplicate, or out-of-scope findings only with evidence. Never silently ignore a nitpick.
  5. Run checks relevant to the changed behavior, including rendered UI and accessibility checks for user-facing changes.
  6. Use /update-pr to commit and push. If unavailable, follow its documented no-amend, no-force-push workflow directly.
  7. In normal mode, report the outcome, findings addressed, commits, observed validation, review-tool state, and PR URL.
  8. In automatic-merge mode, repeat the workflow against the new head. Wait with bounded backoff for required checks and every active review tool. When a tool is incomplete, errored, or rate-limited, use its documented retrigger mechanism when current evidence says it is allowed; a required command comment may use the narrow top-level exception. Do not impose a retry-count limit beyond the host platform.
  9. Stop without merging for a material product decision, unrelated failure, unsafe or divergent PR, unavailable terminal external dependency, or unresolved required finding. Report the exact blocker.
  10. Once the current head is ready, every required check is green, every active review tool has a completed verdict, and no actionable finding remains, squash-merge and delete the source branch through git-workflow. Sync the local default branch, remove only clean worktrees owned by this run, and report the merged PR, final head, validation, reviews, and cleanup.

Download now (ZIP)

  • Other versions185 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 185

    1. denoland/deno★ 109ksame name
    2. ToolJet/ToolJet★ 41ksame name
    3. remix-run/remix★ 33ksame name
    4. tirth8205/code-review-graph★ 32ksame name
    5. alpinejs/alpine★ 32ksame name
    6. nrwl/nx★ 29ksame name
    7. PrefectHQ/fastmcp★ 28ksame name
    8. jlowin/fastmcp★ 28ksame name
    9. livewire/livewire★ 24ksame name
    10. microsoft/fluentui★ 20ksame name

    175 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use write-product-spec, diagnose-ci-failures and 10 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.
    • zerx-labSkill

      write-product-spec

      Write a PRODUCT.md spec for a significant user-facing feature in Zap, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.

      Also in 4 projects that use this

    • zerx-labSkill

      diagnose-ci-failures

      Diagnose CI failures for a PR using the GitHub CLI, extract error logs, and generate a plan to fix them. Use when the user asks to check CI status, pull CI issues, triage test failures, or investigate PR build failures.

      Also in 3 projects that use this

    • n24q02mSkill

      review-delta

      Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.

      Also in 3 projects that use this

    • n24q02mSkill

      build-graph

      Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.

      Also in 3 projects that use this

    • charlesmatteSkill

      write-tech-spec

      Generate a technical specification document from an existing PRD through relentless technical interview and codebase exploration. Use when user wants to write a tech spec, technical specification, technical design document, TDD (technical design doc), or go deeper on the technical details of a PRD.

      Also in 4 projects that use this

    • dekozaSkill

      fix-pr

      Repair an existing pull request's review findings and target-branch conflicts, verify the result, and update the same open PR.

      Also in 5 projects that use this

    • +2 more from zerx-lab
    • +1 more from n24q02m
  • In this repository19 other files it gives its agents.

Does it work?

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

Reviews can't be read right now.

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