pr-reviewlisted

Team baseline for PR and code review — produces scope, blockers, nits, and strengths. Auto-triggers when you say review this PR, check this diff, review these changes, pre-review before I share, what do you think of this PR, or review the diff on this branch. Defers to any other installed skill whose description identifies it as handling PR review, code review, or diff review — if such a skill is present, prefer it over this one (jig's version is a slim baseline). Does not defer to the generic built-in `review` skill. Do not use for: spec-compliance review of a finished slice (use `/jig:independent-review` instead); standalone architecture-doc review (use `/jig:arch-review`, or a richer installed arch-review skill, instead); single-line typo fixes or trivial whitespace changes (just merge and move on).
ramboz/jig · ★ 4 · Code & Development · score 73

Install: claude install-skill ramboz/jig

> Spec 012 introduced this skill as jig's **team baseline** for PR and > code review. It is the first non-stub active jig skill that ships > without a `.py` helper — pr-review is fundamentally a judgment skill, > and the determinism it needs (`git diff`, file-type detection) Codex > can run inline. If any other skill is installed whose description > identifies it as handling PR review, code review, or diff review, Codex > can prefer that one over jig's baseline — the > deferral is category-based, not name-specific, so a richer user skill > named anything (`pr-review`, `code-reviewer`, `team-pr`, etc.) wins. > Jig's slim version remains the auto-trigger when no such skill is > installed. ## What this skill does Produces a four-section markdown review of a pull request, a diff, or a branch's accumulated changes: 1. **Scope** — a one-paragraph summary of what the PR is (new feature, bug fix, refactor, dep bump, etc.) and what it touches. 2. **Blockers** — concrete must-fix items. Each blocker has a file path, a line number, and a one-sentence rationale. 3. **Nits** — nice-to-haves and small polish items. Same shape as blockers but lower urgency. 4. **Strengths** — what the change gets right. Keeps tone constructive and surfaces patterns worth repeating. The review is **breadth over depth**: catch the obvious across any language/stack, leave the deep language-specific antipatterns to a richer user-installed PR/code-review skill (or to a code reviewer with full dom