pr-review
Skill14 starsChanged 7 days agoMITView on GitHub
Use when reviewing a pull request, branch or diff in any language, to produce the analysis a reviewer decides from: what changed, why, how the structure moved, what it can break, and the decisions only a human can make, at five altitudes from code primitives to delivery and intent. Not a bug hunt, and not framework-specific review.
195 other projects use a version of this.
Adopted by
Most recently taken up by
- static-web-server/static-web-servertheir own version, first seen Nov 9, 2026
- zerx-lab/FluxDowntheir own version, first seen Nov 9, 2026
- civitai/civitaitheir own version, first seen Nov 9, 2026
- harshitsinghbhandari/domain-expansiontheir own version, first seen Nov 8, 2026
- Azure/azure-sdk-toolstheir own version, first seen Nov 8, 2026
- databricks/clitheir own version, first seen Nov 8, 2026
Used with
Projects with it also use oss-pr, pr-automation 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.
CES-LtdSkilloss-pr
Use when creating a pull request, after committing changes, or when user invokes /oss-pr. Covers branch management, quality checks, commit, push, and PR creation.
Also in 3 projects that use this
- CES-LtdSkill
pr-automation
PR Automation Orchestrator: poll open PRs, check CI, run review, fix, and merge eligible PRs. Use when: (1) Invoked by daemon via scripts/pr-automation.sh, (2) User says "/pr-automation".
Also in 3 projects that use this
jtenniswoodSkillexpert-reset
Reimagine this repository from first principles using the current product and user experience as the target. Use when the user says "/expert-reset", asks how the project should be rebuilt if starting again, wants bold architecture or component-structure recommendations, or wants a research-only reset plan unconstrained by current implementation details.
Also in 3 projects that use this
- jtenniswoodSkill
updates
Summarize user-facing project updates from the last 7 days, ordered by importance and written as one-sentence "Feature: description" entries. Use when the user says "/updates", asks what changed recently, or wants a concise list of recent features, device support, fixes that users will notice, or other product value.
Also in 3 projects that use this
openchamberSkillclack-cli-patterns
Use when creating or modifying OpenChamber CLI commands, prompts, terminal output, non-TTY behavior, `--quiet`, or `--json` behavior.
Also in 3 projects that use this
- openchamberSkill
drag-to-reorder
Use when implementing or modifying OpenChamber sortable or drag-to-reorder behavior, especially `@dnd-kit`, touch/mobile interactions, variable-width items, or wrapping layouts.
Also in 3 projects that use this
- +6 more from openchamber
Other versions195 projects use a version of this.
Word for word · 1
- Ovich/swarmstorm★ 14100% same
Edited · 0
None found.
Wrote their own version · 194
- Significant-Gravitas/AutoGPT★ 188ksame name
- pytorch/pytorch★ 105ksame name
- rtk-ai/rtk★ 86ksame name
- saadeghi/daisyui★ 43ksame name
- rustfs/rustfs★ 36ksame name
- dotnet/maui★ 23ksame name
- NVIDIA/Megatron-LM★ 18ksame name
- MiniMax-AI/skills★ 14ksame name
- btriapitsyn/openchamber★ 13ksame name
- openchamber/openchamber★ 13ksame name
184 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.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- brainstormSkill
- brainswarmSkill
- interviewSkill
- whiteboard-defenseSkill
- complexity-reworkSkill
- deepen-moduleSkill
- dependency-graphSkill
- simplify-reworkSkill
- simplifySkill
- write-diagramsSkill
- aiviewSkill
- swarm-boardSkill
- execute-planSkill
- long-horizonSkill
- orchestrate-planSkill
- guide-complexitySkill
- guide-createSkill
- guide-deepen-moduleSkill
- helpSkill
- next-stepSkill
- orchestrateSkill
- cold-readSkill
- write-planSkill
- roadmapSkill
- technical-writingSkill
- write-conventionsSkill
- recurring-review-findingsSkill
- swarmSkill
- design-prototypeSkill
- point-atSkill
- validate-deliverySkill
- verification-skill-createSkill
- create-workbenchSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.
0
Common
Most of the 177 edited versions we read keep these.
1
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
- Very specific: line 18
The diff and the search base are the same revision: Check out the PR's head, or say that the blast radius was not repo-verified: a search …
- Very specific: line 34
A plan reaches the review: when the person names it or the PR's group tag finds it (aiview list --kind plan --tag <group>).
- Distinctive: line 64
A correctness bug hunt is the harness's own review: When nothing runs one, the verdict says nobody checked whether the code works.
“Common” is measured: kept by at least 6 in 10 of the 177 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.
Files
PR review
The deliverable is the decisions a reviewer can make: what changed, how the structure moved, the blast radius, the decision points, then findings, each citing its source. It reviews in layers, independent subagents each reading the change at one altitude.
Scope
/pr-review <PR#>:node scripts/scope.mjs pr <PR#> --layers --json/pr-review <branch|ref>:node scripts/scope.mjs branch <ref> --layers --json- Neither: ask for the fixed point.
Run the script first (path relative to this skill). It resolves the merge-base, lists the files with vendored, generated, build and lockfile paths skipped, carries the stated intent, and says which of L3 and L5 have material. Exit 1 is an empty scope, exit 2 a ref that does not resolve: either stops the review. A dirty working tree is invisible to it: say so.
- The diff and the search base are the same revision. Check out the PR's head, or say that the blast radius was not repo-verified: a search against a tree without the PR cites
file:lineconfidently wrong. - Read the repo's conventions before dispatch:
AGENTS.md,CLAUDE.md, architecture docs,write-conventionswhere it applies. A broken house rule is a finding; unusual but unruled is a decision point. - The diff adds or changes a decision citation (
<topic>#D<n>, or a bareD<n>in code): run thewrite-planskill'sscripts/decisions.mjson the PR's head, with the project's plan folder and--codethe repository. A finding it prints is a finding of the review.
The five layers
The diff decides which run. A layer that does not run is recorded with its reason, in the analysis and in the verdict: a reader takes silence for coverage.
| Layer | Owns | Dispatched when |
| L1 Code Primitives | classes, types, functions, lines; DRY and SOLID; races visible in a function body; test code quality | always |
| L2 Code Structure | directories, modules, files; placement and naming; cohesion and coupling; test file placement | always |
| L3 Data | schema, ORM mappings, tables, migration files as artifacts | they are in the diff |
| L4 Integration | blast radius: callers, consumers, contracts, other repos, config, deploy needs, migration execution order | the diff changes a surface something else consumes |
| L5 Delivery & Intent | stated intent against the diff, completeness, scope creep, documentation, coverage of the stated behaviour | the PR states an intent: description, linked issue, commit messages, or a plan, whose user stories are then checked one by one |
- A plan reaches the review when the person names it or the PR's group tag finds it (
aiview list --kind plan --tag <group>); a named plan makes L5 material whatever the script says. - No stated intent: "L5: not run, no stated intent." An inferred intent checks the code against itself.
- A pattern L5 finds unruled that would pass the five filters of
write-conventionsis proposed as a capture, in chat.
The documents
Two files through the aiview skill, one group pr-<id>, each linking the other. Tell the user the report's URL.
YYYY-MM-DD-pr-<id>.report.md | YYYY-MM-DD-pr-<id>.pr-analysis.md | |
| Reader | the human deciding whether to merge | the next agent, and the human asking "why does it say that?" |
| Size | one screen before the comment block | as long as the evidence needs |
| Holds | the claims | the evidence for each |
- Read
references/documents.mdbefore writing either: the sections, the report's register, the stamp, which diagrams go where. - Publish both before any layer returns: the report's Abstract, What changed and change map, with one
aiview pendingcard per dispatched layer, closed as its return lands. - Every report claim traces to a section of the analysis.
Running the layers
Read references/layers.md before dispatch: the seam table, the four slots of a brief, what a return contains.
- Triage in this session: L3 and L5 from the script's
layers, L4 your call from the diff. Settle every seam the review will meet and the shared facts. Each question has one owner. - Each layer is a fresh-context subagent: the diff, its brief, the output contract, and the instruction "Do not invoke skills or spawn agents: review directly." Name the surface in a brief, keep your hypothesis out of it.
- Merge in this session: dedup, rank by cost, drop what the project's linter or CI already flags.
- A finding outside its layer's jurisdiction is dropped from that return, and re-verified under the owning layer if it matters. One that implicates a skipped layer reopens the triage: dispatch the layer, or record why not.
- Re-verify the findings that carry the verdict: a well-argued wrong finding reaches the author in your name.
Beyond the layers
- A correctness bug hunt is the harness's own review. When nothing runs one, the verdict says nobody checked whether the code works.
- The document records it: "Correctness: not covered."
Red flags
| Thought | Reality |
| "One overall score for the PR" | A blended verdict hides the failing layer. One line per layer, plus the open decisions. |
| "More findings = better review" | Ten cited findings beat forty hunches. |
| "The code around it is a mess too" | Not this PR's bill. Note it, attribute it, approve anyway. |
| "Unverifiable from here, so it blocks" | Ask the author. A question they answer in one line is not a change request. |
| "The proposed comment is the deliverable" | The report is. The comment is its condensate. |
| "The recommendation decides the merge" | It drafts the reviewer's words. The decision stays theirs. |
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
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.