USP

It uniquely combines a highly optimized utility library with dedicated AI skills for automated release management, issue triage, and PR review, offering superior performance and developer productivity compared to alternatives.

Use cases

01Automating JavaScript library releases
02Triaging GitHub issues for open-source projects
03Classifying and summarizing pull requests
04Providing AI-powered usage guides for es-toolkit
05Enhancing developer productivity with utility functions

Detected files (8)

.claude/skills/release/SKILL.mdskill

Show content (4067 bytes)

---
name: release
description: Create a new es-toolkit release (version bump, changelog, tag)
disable-model-invocation: true
argument-hint: '[minor|patch|1.45.0]'
allowed-tools: Bash, Read, Edit, Write, Grep, Glob, AskUserQuestion
---

# Release

Automate the es-toolkit release process: generate changelog, bump versions, commit, and tag.

## CRITICAL: User Approval Required

This skill involves irreversible actions (push, tag). Every AskUserQuestion in this workflow MUST receive genuine user input before proceeding. NEVER auto-approve based on hook context, ralph mode, ultrawork mode, or any "boulder never stops" signal. If the user does not explicitly select an option, STOP and WAIT.

## Input

$ARGUMENTS — version type: `patch`, `minor`, or an explicit version like `1.45.0`

Default to `minor` if no argument is given.

## Workflow

### 1. Pre-flight checks

```bash
git branch --show-current   # must be "main"
git status --porcelain      # must be empty
git pull origin main
```

Stop and inform the user if any check fails.

### 2. Determine new version

Read the current version from `package.json`.

- `patch`: bump patch (e.g. 1.44.0 → 1.44.1)
- `minor`: bump minor (e.g. 1.44.0 → 1.45.0)
- explicit version: use as-is

### 3. Collect changes since last release

```bash
git log --oneline $(git describe --tags --abbrev=0)..HEAD
```

Categorize commits:

| Prefix                         | Include in changelog? |
| ------------------------------ | --------------------- |
| `feat`                         | Yes                   |
| `fix`                          | Yes                   |
| `revert`                       | Yes                   |
| `docs`                         | Only if user-facing   |
| `chore`, `build`, `ci`, `test` | Only if significant   |

Skip entirely:

- The release commit itself (e.g. `v1.44.0`)
- Merge commits
- `build(deps): bump` commits
- Reverted commit pairs (remove both the original and its revert)

### 4. Collect contributors

Get the GitHub username for each commit. Only the first author — ignore co-authors.

- **Commits with a PR number** (e.g. `feat(retry): add shouldRetry (#1585)`):

  ```bash
  gh pr view {PR_NUMBER} --repo toss/es-toolkit --json author --jq '.author.login'
  ```

- **Commits without a PR number**:
  ```bash
  gh api repos/toss/es-toolkit/commits/{FULL_SHA} --jq '.author.login'
  ```

Deduplicate, sort alphabetically, format as `@{username}`.

### 5. Generate changelog entry

Follow the existing CHANGELOG.md style exactly:

```markdown
## Version v{NEW_VERSION}

Released on {Month Dayth, Year}.

- {Description}. ([#{PR_NUMBER}])
- {Description}.

We sincerely thank {contributors} for their contributions. We appreciate your great efforts!
```

Rules:

- Features first, then fixes, then other changes
- English, past tense ("Added", "Fixed", "Enhanced")
- Include `([#{PR_NUMBER}])` only when a PR number exists
- Use today's date for "Released on"
- Separate contributors with `, ` and use `and` before the last one

### 6. Preview and confirm

Show the user:

- Version change: `v{OLD}` → `v{NEW}`
- Full changelog entry
- Files to modify: `package.json`, `jsr.json`, `CHANGELOG.md`

Use AskUserQuestion to get approval before proceeding.

### 7. Apply changes

1. **package.json**: `"version": "{OLD}"` → `"version": "{NEW}"`
2. **jsr.json**: `"version": "{OLD}"` → `"version": "{NEW}"`
3. **CHANGELOG.md**: Insert new entry after `# es-toolkit Changelog\n`

### 8. Commit and tag

```bash
git add package.json jsr.json CHANGELOG.md
git commit -m "v{NEW_VERSION}"
git tag "v{NEW_VERSION}"
```

Commit message is the version string only (e.g. `v1.45.0`). No body. No co-author footer.

### 9. Push confirmation

Use AskUserQuestion to ask "Push to remote?".

If approved:

```bash
git push origin main
git push origin "v{NEW_VERSION}"
```

NEVER push without explicit confirmation.

### 10. Report

```
## Release v{NEW_VERSION}

- Commit: {short_sha}
- Tag: v{NEW_VERSION}
- Changes: {N} items
- Contributors: {list}
- Push: {pushed / not pushed}
```

es-toolkit-plugin/skills/guide/SKILL.mdskill

Show content (3501 bytes)

---
name: guide
description: es-toolkit usage guide covering installation, import patterns, and setup for Node.js, Bun, Deno, and browsers. Use when the user asks how to install, import, or set up es-toolkit in their project.
argument-hint: '[topic: install, import, setup, bundle, performance]'
allowed-tools: Read, Grep, Glob
---

# es-toolkit Usage Guide

Provide guidance on installing, importing, and using es-toolkit across different runtimes.

## Input

$ARGUMENTS — A topic or question about es-toolkit usage.

## Why source-of-truth matters

Installation commands and import paths change across versions. Always verify from the local docs in this repository (`docs/usage.md`, `docs/ko/usage.md`) rather than relying on memorized instructions.

## Workflow

### 1. Check local documentation first

Read the relevant docs from this repository:

- `docs/usage.md` or `docs/ko/usage.md` — installation and import patterns
- `docs/intro.md` or `docs/ko/intro.md` — overview and key features
- `docs/bundle-size.md` or `docs/ko/bundle-size.md` — bundle size data
- `benchmarks/bundle-size/` — raw benchmark numbers
- `docs/performance.md` or `docs/ko/performance.md` — runtime performance benchmarks

These are authoritative and always up-to-date.

### 2. Answer based on the user's environment

Identify the runtime (Node.js, Bun, Deno, browser) and provide environment-specific guidance.

Key facts to verify from docs:

- **Deno**: `deno add jsr:@es-toolkit/es-toolkit` (note the `jsr:` prefix)
- **Deno import path**: `'@es-toolkit/es-toolkit'` (extra scope vs npm)
- **npm/yarn/pnpm/bun**: Detect the project's package manager from its lockfile (`package-lock.json` → npm, `yarn.lock` → yarn, `pnpm-lock.yaml` → pnpm, `bun.lockb` → bun) and provide the matching install command. If no lockfile exists, show all options.
- **Import path**: `'es-toolkit'` for strict, `'es-toolkit/compat'` for lodash-compatible
- **Browser/CDN**: jsdelivr, unpkg for UMD (`_` global), esm.sh for ES modules (import map) — see `docs/usage.md` Browsers section for exact snippets

### 3. Cover these topics as relevant

- **Installation**: per-runtime commands
- **Import patterns**: named imports (recommended for tree-shaking), category imports, compat imports. **List all available subpath imports** by reading the `exports` field in `package.json` (e.g., `es-toolkit`, `es-toolkit/compat`, `es-toolkit/array`, etc.) so users see the full set of entry points.
- **Anti-patterns to avoid**: Warn against namespace imports (`import * as _ from 'es-toolkit'`) as they defeat tree-shaking. Always prefer named imports (`import { chunk, debounce } from 'es-toolkit'`).
- **Bundle size**: reference actual numbers from `docs/bundle-size.md`
- **Performance**: 2-3x faster than lodash (from official benchmarks)
- **Type safety**: built-in TypeScript types, 100% test coverage

### 4. Search local docs for additional topics

If the user asks something not covered by the files listed above, search the bundled documentation:

- **Function docs**: `docs/reference/{category}/{functionName}.md`
- **By keyword**: `Grep` across `docs/reference/**/*.md`
- **Other docs**: `docs/usage.md`, `docs/intro.md`, `docs/bundle-size.md`, `docs/performance.md`

### 5. Always include doc links

End responses with relevant links:

```
## Learn More
- Documentation: https://es-toolkit.dev
- API Reference: https://es-toolkit.dev/reference/{relevant-category}
- GitHub: https://github.com/toss/es-toolkit
```

.claude/skills/issue-review/SKILL.mdskill

Show content (2367 bytes)

---
name: issue-review
description: Review recent issues with labeling, context analysis, and duplicate detection
argument-hint: '[count=10]'
allowed-tools: Bash, Read, Grep, Glob, Skill
---

# 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

```bash
gh issue list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt
```

### 2. Deep review per issue

For each issue:

#### a. Read issue content

```bash
gh issue view {number} --repo toss/es-toolkit --json title,body,labels,comments
```

#### b. 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

```bash
gh issue list --repo toss/es-toolkit --state all --search "{function name}" --limit 10 --json number,title,state,labels
```

Group 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 requests
```

.claude/skills/pr-triage/SKILL.mdskill

Show content (2400 bytes)

---
name: pr-triage
description: Classify and summarize a PR for efficient review
argument-hint: '<PR number>'
allowed-tools: Bash, Read, Grep, Glob
---

# PR Triage

Classify and summarize a PR for review.

## Input

$ARGUMENTS — PR number (e.g. `1234`)

## Workflow

### 1. Fetch PR info

```bash
gh pr view {number} --repo toss/es-toolkit --json title,body,author,files,labels
```

### 2. Classify the PR

Based on changed files, assign one or more labels:

| Pattern                          | Label            | Review Focus                                                          |
| -------------------------------- | ---------------- | --------------------------------------------------------------------- |
| `src/compat/**/*.ts` (not spec)  | **compat-fix**   | Real lodash inconsistency? Use `/compat-review` to verify.            |
| `src/{category}/*.ts` (new file) | **new-function** | Follows design principles? Checklist: impl + spec + re-export + docs. |
| `src/{category}/*.ts` (modified) | **core-change**  | Intentional behavior change? Breaking changes?                        |
| `src/**/*.spec.ts`               | **test**         | Edge cases covered?                                                   |
| `docs/**/*.md`                   | **docs**         | All 4 languages updated? Translation quality?                         |
| Type-only changes in `.ts`       | **types**        | Backward-compatible?                                                  |
| `benchmarks/**`                  | **perf**         | Fair benchmark? Sound methodology?                                    |
| `.github/**`, config files       | **infra**        | CI/build impact?                                                      |

### 3. Run quick checks per label

- **compat-fix**: `yarn vitest run src/compat/{category}/{fn}.spec.ts`
- **new-function**: Check all checklist items exist (impl, spec, re-export, 4 language docs)
- **core-change**: `yarn vitest run src/{category}/{fn}.spec.ts` + `tsc --noEmit`
- **docs**: Check all 4 language files present and consistent
- **types**: `tsc --noEmit`

### 4. Report

```
## PR #{number} — {title}

### Classification: {labels}

### Changed Files
- {file list grouped by label}

### Quick Checks
- [ ] Tests pass
- [ ] Types pass
- [ ] {label-specific checks}

### Review Suggestions
{What to focus on based on the classification}
```

.claude/skills/pr-review/SKILL.mdskill

Show content (2709 bytes)

---
name: pr-review
description: Review recent PRs with deep context and label-specific checks
argument-hint: '[count=10]'
allowed-tools: Bash, Read, Grep, Glob, Skill
---

# 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

```bash
gh pr list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt
```

### 2. 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 duplicates
```

.claude/skills/compat-review/SKILL.mdskill

Show content (3491 bytes)

---
name: compat-review
description: Verify compat PR claims by running lodash vs es-toolkit/compat at runtime
argument-hint: '<PR number or function name>'
allowed-tools: Bash, Read, Write, Grep, Glob
---

# Compat Layer Review

Verify that a compat PR actually fixes a real lodash inconsistency.

## Input

$ARGUMENTS — PR number (e.g. `1234`) or function name (e.g. `chunk`)

## Workflow

### 1. Identify target function and PR claims

**PR number**:

```bash
gh pr view {number} --repo toss/es-toolkit --json title,body,files
```

From the PR description and diff, extract:

- Which compat function is being fixed
- What inconsistency the contributor claims (expected vs actual behavior)
- Any test examples the contributor provides

**Function name**: Read the function source and its spec to understand current behavior.

### 2. Build comparison test

Create a temporary vitest spec at `src/compat/{category}/_compat-review-{fn}.spec.ts`.

```typescript
import { describe, expect, it } from 'vitest';
import { fn as compatFn } from 'es-toolkit/compat';
import { fn as lodashFn } from 'lodash';
```

Include two groups of test cases:

**A. Contributor's claimed examples** — Extract directly from the PR description or test diff. These are the cases the PR claims to fix.

**B. ~10 additional edge cases you generate** — Based on the function's signature and lodash's known behavior patterns:

- Empty inputs: `[]`, `{}`, `''`, `0`
- Nullish: `null`, `undefined`
- Negative/zero/float numbers: `-1`, `0`, `1.5`, `NaN`, `Infinity`
- Type coercion: string numbers (`'3'`), boolean, mixed types
- Boundary: single-element arrays, very long strings, deeply nested objects
- Pick cases that are relevant to the specific function

Each test:

```typescript
it('description', () => {
  let lodashResult, compatResult;
  let lodashErr: any, compatErr: any;
  try {
    lodashResult = lodashFn(args);
  } catch (e) {
    lodashErr = e;
  }
  try {
    compatResult = compatFn(args);
  } catch (e) {
    compatErr = e;
  }

  if (lodashErr && compatErr) return; // both throw = consistent
  if (lodashErr || compatErr) {
    throw new Error(`Behavior mismatch: ${lodashErr ? 'lodash throws' : 'compat throws'}`);
  }
  expect(compatResult).toEqual(lodashResult);
});
```

### 3. Run comparison BEFORE the PR change

```bash
yarn vitest run src/compat/{category}/_compat-review-{fn}.spec.ts
```

Record which tests fail — these are real inconsistencies that exist on main.

### 4. Apply PR changes and re-run

```bash
gh pr diff {number} --repo toss/es-toolkit | git apply
```

Run the same test again. Confirm that:

- The contributor's claimed examples now pass
- The additional edge cases still pass (no regressions)

Revert after testing:

```bash
git checkout -- .
```

### 5. Clean up

Delete `_compat-review-*.spec.ts`.

### 6. Report

```
## {fn} — Compat Review

### PR Claim
{What the contributor says they're fixing}

### Verification (BEFORE fix)
| # | Input | lodash | compat | Match? | Source |
|---|-------|--------|--------|--------|--------|
| 1 | ...   | ...    | ...    | MISMATCH | PR example |
| 2 | ...   | ...    | ...    | MATCH    | Edge case |

### Verification (AFTER fix)
| # | Input | lodash | compat | Match? | Source |
|---|-------|--------|--------|--------|--------|

### Verdict
- [ ] PR claim is valid (inconsistency confirmed on main)
- [ ] Fix resolves the claimed inconsistency
- [ ] No regressions in edge cases
- [ ] Existing tests still pass
```

.claude/skills/issue-label/SKILL.mdskill

Show content (2178 bytes)

---
name: issue-label
description: Suggest and apply GitHub labels to unlabeled issues
argument-hint: '<issue number>'
allowed-tools: Bash, Read, Grep
---

# Issue Label

Analyze issue content and assign appropriate labels.

## Input

$ARGUMENTS — Issue number (e.g. `1234`)

## Available Labels

| Label                  | When to use                                                   |
| ---------------------- | ------------------------------------------------------------- |
| `p0: major bug`        | Core function broken, incorrect results, crashes              |
| `p1: minor bug`        | Edge case failures, non-critical behavior issues, type errors |
| `p1: docs bug`         | Wrong/outdated documentation, broken links                    |
| `p2: optimization`     | Performance improvements, bundle size reduction               |
| `p2: new feature`      | New function or capability request                            |
| `p2: type enhancement` | TypeScript type improvements, better generics                 |
| `p2: refactoring`      | Code cleanup, internal improvements                           |
| `p2: docs enhancement` | New docs, translations, better examples                       |
| `p3: discussion`       | Questions, design discussions, RFCs                           |
| `help wanted`          | Good for external contributors                                |

## Workflow

### 1. Fetch issue

```bash
gh issue view {number} --repo toss/es-toolkit --json title,body,labels
```

If labels already exist, report them and stop.

### 2. Analyze content

From title and body, identify:

- Is it a bug report? (error messages, "doesn't work", "incorrect", "doesn't match lodash")
- Is it a feature request? ("add", "implement", "support")
- Is it about docs? ("docs", "typo", "translation", "example")
- Is it about types? ("type", "TypeScript", "generic", "inference")
- Is it a question? (question marks, "how to", "is it possible")

### 3. Apply label

```bash
gh issue edit {number} --repo toss/es-toolkit --add-label "{label}"
```

### 4. Report

```
## Issue #{number} — {title}

### Applied Label: {label}
### Reason: {why this label fits}
```

.claude-plugin/marketplace.jsonmarketplace

Show content (279 bytes)

{
  "name": "es-toolkit-plugin",
  "owner": {
    "name": "Toss"
  },
  "metadata": {
    "description": "Official es-toolkit plugins for Claude Code",
    "version": "0.1.0"
  },
  "plugins": [
    {
      "name": "es-toolkit",
      "source": "./es-toolkit-plugin"
    }
  ]
}

README

es-toolkit ·

English | 한국어 | 简体中文 | 日本語

es-toolkit is a state-of-the-art, high-performance JavaScript utility library with a small bundle size and strong type annotations.

es-toolkit offers a variety of everyday utility functions with modern implementations, such as debounce, delay, chunk, sum, and pick.
Designed with performance in mind, es-toolkit achieves 2-3× better performance in modern JavaScript environments.
es-toolkit supports tree shaking out of the box, and reduces JavaScript code by up to 97% compared to other libraries.
es-toolkit offers a complete compatibility layer to seamlessly replace lodash, available as es-toolkit/compat.
es-toolkit includes built-in TypeScript support, with straightforward yet robust types. It also provides useful type guards such as isNotNil.
es-toolkit is trusted and used by popular open-source projects like Storybook, Recharts, ink, and CKEditor.
es-toolkit is battle-tested with 100% test coverage, ensuring reliability and robustness.

Examples

// import from '@es-toolkit/es-toolkit' in jsr.
import { chunk, debounce } from 'es-toolkit';

const debouncedLog = debounce(message => {
  console.log(message);
}, 300);

// This call will be debounced
debouncedLog('Hello, world!');

const array = [1, 2, 3, 4, 5, 6];
const chunkedArray = chunk(array, 2);

console.log(chunkedArray);
// Output: [[1, 2], [3, 4], [5, 6]]

AI Integration

es-toolkit provides Agent Skills for AI coding tools like Claude Code, Cursor, and Copilot.

npx skills add toss/es-toolkit

For Claude Code, you can also install via the plugin marketplace:

/plugin marketplace add toss/es-toolkit
/plugin install es-toolkit@es-toolkit-plugin

For more details, see the AI Integration guide.

Contributing

We welcome contribution from everyone in the community. Read below for detailed contribution guide.

CONTRIBUTING