Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/toss/es-toolkit/releasenpx skills add toss/es-toolkit --skill releasegit clone --depth 1 https://github.com/toss/es-toolkitWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00018 | $0.01080 |
| Opus 5 | $0.00009 | $0.00540 |
| Sonnet 5 | $0.00004 | $0.00216 |
| Haiku 4.5 | $0.00002 | $0.00108 |
Grade A, and why
release scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
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
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): bumpcommits- 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)):gh pr view {PR_NUMBER} --repo toss/es-toolkit --json author --jq '.author.login'
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 156 lines · 18 tokens per session scan A bd442ee03374
release is a skill published in the GitHub repository toss/es-toolkit (11,320 stars, last pushed 2d ago), licensed MIT. It adds 18 tokens to every session and 1,080 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…
ship
Build, commit, push & version bump workflow - automates the complete release cycle.
ce-commit-push-pr
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
ship
Commit and push the current work properly — lint, run the release gate, write a detailed commit message, push to GitHub. Use whenever work reaches a milestone or the user says ship it, commit, or push.
comet-safe-delivery
在保护无关脏改动、关联 worktree、子模块和用户明确边界的前提下，提交、推送、合并或完成范围明确的 Comet 变更。用户要求提交、推送、合并回目标分支、清理 worktree 或交付已准备好的改动时使用。.
verify-and-ship
Run all quality checks (tests, lint, typecheck), fix failures, update the changelog, commit, push, and create/update the pull request or merge request.