Pr Review
- 111 installs
- 11.3k repo stars
- Updated August 5, 2026
- toss/es-toolkit
PR Review is a maintainer skill that fetches and deeply reviews es-toolkit pull requests so reviewers can issue structured verdicts with label-specific checks.
About
PR Review is an es-toolkit maintainer skill that batches review of recent open pull requests. It triages each PR, reads the current implementation on main, compares the diff for breaking impact and lodash alignment, runs label-specific checks, and prints a structured verdict. Maintainers invoke it to speed consistent reviews across compat fixes, new functions, core changes, docs, and types without skipping deep context.
- Lists recent open PRs via gh and runs pr-triage per item
- Reads main-branch source, tests, and JSDoc before judging diffs
- Label-specific checks: compat-review, vitest, four-language docs, tsc
- Detects duplicate PRs and summarizes merge-ready vs needs-work counts
Pr Review by the numbers
- 111 all-time installs (skills.sh)
- +4 installs in the week ending Jul 27, 2026 (Skillselion tracking)
- Ranked #436 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/toss/es-toolkit --skill pr-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 111 |
|---|---|
| repo stars | ★ 11.3k |
| Last updated | August 5, 2026 |
| Repository | toss/es-toolkit ↗ |
How do you efficiently review a batch of open PRs with es-toolkit-specific compat, docs, and test expectations?
Fetches open es-toolkit PRs, triages labels, deep-reads diffs, and outputs merge verdicts with checkpoints.
Who is it for?
es-toolkit maintainers or contributors doing structured review of multiple open PRs with gh CLI access.
Skip if: Generic repos without es-toolkit label conventions or reviewers who only need issue triage.
When should I use this skill?
The user runs /pr-review or asks to review recent open PRs on toss/es-toolkit with optional count.
What you get
Per-PR reports with classification, code context, checkpoints, verdict, plus a summary table of merge readiness.
Files
PR Review
Fetch recent PRs, classify, read source code, and produce contextual reviews.
Input
$ARGUMENTS — Number of PRs (default: 10)
Examples:
/pr-review— 10 most recent open PRs/pr-review 20— 20 PRs
Workflow
1. Fetch recent PRs
gh pr list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt2. Triage each PR
Run /pr-triage {number} for each PR to classify.
3. Deep review per PR
For each PR, go beyond classification — read the actual source code and provide context:
a. Read current code
Read the files being modified on main to understand the current behavior:
- Function source: what it does, how it works
- Existing tests: what's already covered
- JSDoc: documented behavior and examples
b. Understand the PR change
Read the diff to understand what's changing:
- What's the before vs after?
- Why does the contributor say this change is needed?
- Does the change match what the code actually needs?
c. Assess impact
- Breaking changes: Does the function signature change? Will existing users be affected?
- JS spec alignment: Does current behavior follow JS/lodash conventions? Does the PR break that?
- Scope: Are all affected files updated? (e.g., docs in all 4 languages, related functions)
- Design principles: Does this align with es-toolkit's 85% use case / simplicity philosophy?
d. Label-specific checks
- compat-fix: Run
/compat-review {number} - new-function: Check completeness (impl + spec + re-export + 4 lang docs)
- core-change:
yarn vitest run src/{category}/{fn}.spec.ts+ review breaking impact - docs: Check all 4 language files updated consistently
- types:
tsc --noEmit
4. Detect duplicates
Group PRs by same function name or same files modified.
5. Report per PR
For each PR, output:
### PR #{number} — {title}
**Classification**: {labels}
**Changed files**: {summary}
**Current code**: {what the function does now, with code snippet}
**PR change**: {what's changing and why, with before/after}
**Context**: {JS spec, lodash behavior, design principle considerations}
**Checkpoints**:
- {specific things to verify}
**Verdict**: {merge / merge with changes / hold for discussion / reject}6. Summary
## PR Review — {date}
| # | Title | Label | Verdict |
|---|-------|-------|---------|
- {N} ready to merge
- {N} need changes
- {N} need discussion
- {N} potential duplicatesRelated skills
Improve Codebase ArchitectureSafely deepen clusters of shallow modules into cohesive, testable units while respecting their external dependencies.566k196k
Caveman ReviewGet ultra-compressed, one-line code review comments that cut noise while keeping every actionable fix.270k94.7kCodebase DesignShared vocabulary for designing deep modules: improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable.266k196kCavecrewDelegate coding tasks to specialized subagents that return compressed output, keeping the main context window usable for much longer sessions.220k94.7kCode ReviewReviews a branch or PR diff on two axes at once: conformance to coding standards plus a code-smell baseline, and whether it actually implements the original spec.201k196k
Requesting Code ReviewDispatch a consistent, high-signal code reviewer subagent that catches plan deviations and quality issues before merging or continuing development.183k264kFAQ
What is the default number of PRs reviewed?
Ten most recent open PRs unless the user passes a different count argument.
How does it handle compat-fix PRs?
It routes those through /compat-review and lodash consistency expectations.
What must new-function PRs include?
Implementation, spec, re-export, and documentation updates across all four supported languages.