Eight agent skills that do the slow part of reviewing a pull request — the careful reading — and hand you the two or three findings that earn a comment, with the reasoning attached so you can check them in seconds.
Reviewing a pull request well takes two things that are hard to do quickly. Reading the change carefully enough to find what actually breaks — and then deciding which of those findings is worth the author's time. The first is slow. The second is the part everyone skips when the first ran long.
These skills carry both. They spend the time on the reading — reading order, four passes over the diff, sweeping the whole repo for anything the change touched — then score every finding and keep only the ones that clear the bar. What reaches you is short, specific, and already checked against the test suite.
Reading order, four passes over the diff, blast-radius sweeps, and a reproduction before anything is claimed.
A weighted 10-point score. Below the floor it never reaches you. Related findings merge into one comment.
Concrete claim, minimal patch, one line of why — so you can approve or dismiss it at a glance.
Every skill is self-contained. Install one and it works on its own.
FLOOR is the minimum score a finding must reach to be worth posting. 7.5 where a miss is asymmetric and cannot be un-shipped. 8.5 where noise is expensive and the stakes are low — there you cut harder, not softer.
Every candidate finding is scored on correctness, architectural impact, urgency, and how much it costs the author to act on. The floor decides what reaches you.
| Score | Band | Action |
|---|---|---|
| 9.0–10 | Subtle bug, race, leak, edge-case crash, security flaw | Must post, with a patch |
| 8.0–8.9 | Type safety, test isolation, structural polish | Post as a suggestion |
| 6.0–7.9 | Cosmetic refactor, micro-optimization, preference | Do not post on the PR |
| < 6.0 | Generic lint, praise, hallucination | Reject silently |
Three separate 7.5 nits about the same pattern do not add up to a 9.0. They add up to one 8.5 about the pattern, posted at the first occurrence. Hard budget: one comment per ~200 changed lines, five max.
Good job on the error handling! However, catching a broad exception here can be restrictive. Consider narrowing the exception type for better error handling.
Polite, plausible, unactionable. Names no failure mode, so the author cannot tell whether it matters.
This now catchesConnectionErrortoo, so a network blip reaches the caller as aConfigParseErrorand the retry atloader.py:64never fires:
except ParseError as exc:
raise ConfigParseError(path) from exc
WDYT?
Same observation underneath. One is a notification; the other names the failure and carries the patch. Illustrative — not a real project.
Descriptions carry explicit trigger conditions, so the agent routes to the right skill without you naming it.
Illustrative session. Numbers are not from a real repository.
Plain Markdown with standards-compliant frontmatter. Any agent that reads a
SKILL.md works — and a human can read them directly.
Everything:
npx skills add priyank766/OpenSource-SKILL
A single skill — nothing it does not need is copied:
npx skills add priyank766/OpenSource-SKILL --skill security-review
As a plugin:
/plugin marketplace add priyank766/OpenSource-SKILL /plugin install opensource-review-suite
Or as plain skills:
npx skills add priyank766/OpenSource-SKILL -a claude-code -g -y
Lands in ~/.claude/skills/, picked by description.
Global, for every project:
npx skills add priyank766/OpenSource-SKILL -a codex -g -y
Or scoped to one repo:
npx skills add priyank766/OpenSource-SKILL -a codex -y
Global lands in ~/.codex/skills/, project in
.agents/skills/.
Also targets Cursor, Gemini, Antigravity, opencode, Copilot, and Cowork — see the install matrix.