pr-review
Skill5 starsChanged 47 days agoMITView on GitHub
use this when reviewing a PR or diff before it lands on project-main or trunk, or when the builder is acting on review comments — reviewer is not the builder; two axes (Standards vs Spec); builder verifies comments before implementing.
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 · 0
None found.
Edited · 0
None found.
Wrote their own version · 195
- 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
185 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 repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- maintainers/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- buying-researcherSkill
- cursor-cloud-agents-whenSkill
- debug-anthropicSkill
- debug-pocockSkill
- debugSkill
- discover-the-ideaSkill
- docs-google-styleSkill
- golang-safetySkill
- golang-securitySkill
- golang-testingSkill
- grok-acpSkill
- host-config-pyinfraSkill
- lang-cppSkill
- lang-csharpSkill
- lang-cSkill
- lang-dartSkill
- lang-dockerSkill
- lang-goSkill
- lang-javaSkill
- lang-js-tsSkill
- lang-kotlinSkill
- lang-luaSkill
- lang-makefileSkill
- lang-phpSkill
- lang-powershellSkill
- lang-protobufSkill
- lang-pythonSkill
- lang-rubySkill
- lang-rustSkill
- lang-shellSkill
- lang-sqlSkill
- lang-swiftSkill
- lang-terraformSkill
- language-routerSkill
- lang-web-markupSkill
- modern-pythonSkill
- sdlc-artifactsSkill
- sdlc-onboardingSkill
- security-hardeningSkill
- shell-safetySkill
- tddSkill
- tracker-sdlcSkill
- ui-craftSkill
- ux-designSkill
- verify-before-doneSkill
- yagniSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 178 edited versions we read keep these.
8
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
- could be automatic: a setting could enforce it
- Distinctive: line 10
Review skills should not write: Read, report, escalate. Fixes are a different pass.
- Distinctive: line 42
Reviewer stays read-only: Do not spawn nested reviewers.
- Distinctive: line 44
Also request review: when stuck, before a risky refactor, and after a complex bugfix — not only at the Review land gate.
- Distinctive: line 49
After Review findings, the builder loads this section (same skill).
- Distinctive: line 50
Do not performatively agree.
- Distinctive: line 52
Read all items. Restate unclear ones or ask — do not implement a partial set.
- Distinctive: line 54
Check each item against this codebase (breaks existing?
- Distinctive: line 62
If you pushed back and were wrong: say what you checked, then fix.
“Common” is measured: kept by at least 6 in 10 of the 178 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
Rewrite. Process from obra/superpowers requesting-code-review @ b36e0829. Dual-axis from mattpocock/skills code-review (Standards vs Spec) @ 3cca18b3. Id is pr-review, not /code-review.
Review skills should not write. Read, report, escalate. Fixes are a different pass.
Aligns with SDLC Review: review before the item lands on project-main (or trunk if there is no project-main). Review is an explicit gate: internal lands are local merges with no PR, and that does not skip it; PRs are only for outside or remote workers. See Review and Project-main. Builder, verifier and reviewer are distinct; mint, then resume: Item agents.
Iron law
No land on project-main (or trunk) on builder self-review alone.
Always
- Pin the range. Three-dot diff vs project-main (or trunk if there is no project-main, or another fixed point the manager named). Confirm the ref resolves and the diff is non-empty. Do not review versus trunk while project-main exists.
- Craft context only (first launch). Description, ticket/LLD/spec
link, base/head SHAs, standards sources (
AGENTS.md,CODING_STANDARDS.md, CONTRIBUTING). Not the builder transcript. Later rounds: resume the same reviewer and send the new range; see Item agents. - Two axes, separate:
- Standards — repo conventions + judgement smells (see baseline). Documented repo rules override smells.
- Spec — ticket/LLD/acceptance: missing, wrong, or scope creep. Quote the requirement.
- Report both axes under
## Standardsand## Spec. Do not merge or rerank across axes. - Act: Critical/Important before land; Minor can follow. Push back with reasoning if the reviewer is wrong.
- Reviewer stays read-only. Do not spawn nested reviewers. Do not write, merge, or “just fix it” from the review skill.
- Also request review when stuck, before a risky refactor, and after a complex bugfix — not only at the Review land gate.
Receiving review (builder)
After Review findings, the builder loads this section (same skill). Do not performatively agree. Do not implement before verifying.
- Read all items. Restate unclear ones or ask — do not implement a partial set.
- Check each item against this codebase (breaks existing? YAGNI? reviewer missing context?).
- Order: blocking/security → simple → complex. Test each (
tdd/verify-before-done). - Push back with evidence when the suggestion is wrong for this stack or unused (grep). Architectural conflict → operator.
- Reply on the review thread when the host has one, not only as a top-level “fixed.”
- If you pushed back and were wrong: say what you checked, then fix. No long apology.
Ask first
| Topic | Why |
| No spec/ticket available | Spec axis may skip — say so explicitly |
| Skipping a separate reviewer because “tiny diff” or no PR | Still mint (or resume) the reviewer before land |
| Reviewer wants write/merge tools | Review skill must not grow write privilege; manager owns the land |
Never
| Never | Why |
| Self-review as the only Review gate | SDLC: reviewer is not the builder |
| Reviewing versus trunk while project-main exists | Land target is project-main |
| Trust “LGTM” without reading the diff | No evidence |
| Review skill that deploys, merges, or rotates secrets | Review skills should not write |
Smell baseline (judgement only)
Repo standards win. Skip what tooling already enforces. Label as heuristic, not hard fail unless a documented standard says so:
Mysterious Name · Duplicated Code · Feature Envy · Data Clumps · Primitive Obsession · Repeated Switches · Shotgun Surgery · Divergent Change · Speculative Generality · Message Chains · Middle Man · Refused Bequest
Roles
| Role | Owns | Does not own |
| architect | Requesting a clean reviewer (then resuming it) | Treating self-LGTM as Review |
| builder | Verify then fix Critical/Important; reasoned pushback | Blind “you’re right” patches; using builder memory as the review |
| security | Security axis at Review (trust boundaries); intake | Rewriting product specs in review |
| tester | CI evidence the reviewer can cite | Product Spec axis |
| manager | Land order (local, serialized merges; PRs only for outside or remote workers); after-act | Blessing land without Review |
Red flags
- “I’ll just skim it myself in this session”
- “The builder explained why it’s fine”
- “Spawn a new reviewer every round so it stays fresh”
- “We’ll integrate all the item branches at the end”
- Merging Standards pass to hide Spec fail (or the reverse)
- Reviewer opening write tools “to finish the review”
- “Let me implement that now” before checking the codebase
- Nested reviewer subagent from the reviewer
- Skipping review because “it’s simple” or “we’re in a hurry”
Upstream pins
- Process: obra/superpowers
requesting-code-review@b36e0829c6d0140e93cfef2ca599b1b07d4a7797 - Receive: obra/superpowers
receiving-code-review@b36e0829c6d0140e93cfef2ca599b1b07d4a7797 - Dual-axis: mattpocock/skills
skills/engineering/code-review@3cca18b368ae95cdbdebbff572ccafa662551015
See SOURCES.md.
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.