Issue Review
- 110 installs
- 11.3k repo stars
- Updated August 5, 2026
- toss/es-toolkit
issue-review is an es-toolkit maintainer skill that inspects GitHub issues against source and tests so assistants can label, deduplicate, and recommend actions on open reports.
About
issue-review is a maintainer skill for toss/es-toolkit that pulls recent GitHub issues, reads relevant source and tests, applies labels, and flags duplicates against lodash behavior and project principles. Developers running OSS duty use it during triage sessions instead of manually opening every thread. It expects gh CLI access to the es-toolkit repository.
- Fetches recent issues via gh with configurable count
- Reads function source and tests for bug versus design calls
- Runs duplicate search and optional issue-label skill
- Outputs per-issue analysis tables and summary metrics
Issue Review by the numbers
- 110 all-time installs (skills.sh)
- +4 installs in the week ending Jul 27, 2026 (Skillselion tracking)
- Ranked #217 of 733 Git & Pull Requests 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 issue-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 110 |
|---|---|
| repo stars | ★ 11.3k |
| Last updated | August 5, 2026 |
| Repository | toss/es-toolkit ↗ |
How do maintainers quickly judge whether open es-toolkit issues are bugs, duplicates, or misaligned feature requests?
Triage open es-toolkit GitHub issues with source context, lodash comparisons, labeling, duplicate detection, and maintainer action recommendations.
Who is it for?
es-toolkit contributors with gh access who batch-triage open issues and need lodash and design-principle context.
Skip if: End users asking how to install the library or authors who cannot run GitHub CLI against toss/es-toolkit.
When should I use this skill?
You run issue-review with an optional count to audit recent open issues in the es-toolkit repo.
What you get
Per-issue context, labels, duplicate links, and a summary table of actionable bugs versus requests.
Files
Issue Review
Fetch recent issues, label unlabeled ones with context, detect duplicates.
Input
$ARGUMENTS — Number of issues (default: 10)
Examples:
/issue-review— 10 most recent open issues/issue-review 20— 20 issues
Workflow
1. Fetch recent issues
gh issue list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt2. Deep review per issue
For each issue:
a. Read issue content
gh issue view {number} --repo toss/es-toolkit --json title,body,labels,commentsb. Read related source code
If the issue mentions a specific function:
- Read the function source to understand current behavior
- Read existing tests to see what's covered
- Check if there's already a compat variant
c. Provide context
- Bug reports: Is the reported behavior actually a bug? Or is it by design? Does lodash behave differently?
- Feature requests: Does this align with design principles? Is it replaceable by modern JS? Is it TC39 Stage 3+?
- Type issues: Read the current type signature, assess the proposed change
- Docs: Check what's currently documented vs what's being requested
d. Label if unlabeled
If no labels exist, run /issue-label {number}.
3. Detect duplicates
gh issue list --repo toss/es-toolkit --state all --search "{function name}" --limit 10 --json number,title,state,labelsGroup by:
- Same function name in title
- Similar error descriptions
- Same feature being requested
4. Report per issue
### Issue #{number} — {title}
**Label**: {existing or newly applied}
**Context**: {what the function currently does, relevant code snippet}
**Analysis**: {is the request valid? design principle alignment?}
**Duplicates**: {similar issues if any}
**Action**: {label applied / needs discussion / close as wontfix / link to existing PR}5. Summary
## Issue Review — {date}
| # | Title | Label | Duplicate? | Action |
|---|-------|-------|------------|--------|
- {N} issues reviewed
- {N} newly labeled
- {N} potential duplicates
- {N} actionable bugs
- {N} feature requestsRelated skills
Caveman CommitGenerate terse, Conventional Commits messages that preserve intent without fluff or AI attribution.272k94k
Resolving Merge ConflictsQuickly understand, resolve, and commit merge conflicts without losing work or breaking their flow.183k193kGit Guardrails Claude CodePrevent Claude Code from accidentally running destructive git commands like force push, hard reset, or clean.175k193k
Using Git WorktreesGuarantee every new feature or implementation task runs inside a clean, isolated workspace without polluting the main branch or current working directory.149k263k
Git CommitGenerate accurate conventional commit messages and intelligently stage files directly from natural language requests.40.6k37.2k
Resolve Merge ConflictsQuickly understand and resolve Git merge conflicts without losing context or breaking changes.16.5k148FAQ
What CLI does issue-review use?
It documents gh issue list and gh issue view against toss/es-toolkit with JSON output fields.
How are duplicates found?
It searches all issues by function name or similar descriptions and groups overlapping reports.
What happens for unlabeled issues?
The workflow runs the issue-label skill for numbers without labels after reading issue bodies and code.