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 commands/stellarshenson/claude-code-plugins/releasegit clone --depth 1 https://github.com/stellarshenson/claude-code-pluginsWhat 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.00000 | $0.02744 |
| Opus 5 | $0.00000 | $0.01372 |
| Sonnet 5 | $0.00000 | $0.00549 |
| Haiku 4.5 | $0.00000 | $0.00274 |
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 yesterday.
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 — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release
Full release pipeline: lint + format, publish the library, sync plugins to its version, journal, commit, push. Use when shipping a finished session's work as a marketplace release.
Execution discipline (READ FIRST - prevents the known failure modes)
These rules are not optional. Two real incidents motivated them: a parallel-tool batch that raced on the git index, and corrupted terminal output that led to a wrong "no Makefile" conclusion.
- One step at a time. NEVER batch dependent operations in parallel. Every git mutation (
add,rm,reset,commit,push) and every version-bump write MUST run as its own tool call, and you MUST read its result before the next. Parallel tool calls are allowed ONLY for independent read-only inspection (e.g. severalgrep/catwith no ordering between them) - never for anything that writes, and never across a step boundary. .git/index.lockmeans a git process is mid-flight or crashed. If you see it: STOP, confirm no git command is still running, thenrm -f .git/index.lockand re-verify with a singlegit statusbefore continuing. Do not blindly retry the locked command.- Distrust corrupted/garbled tool output. If a result looks truncated, shows the wrong file, or contains content that cannot belong to the command (interleaving, control-sequence noise), do NOT draw conclusions from it. Re-run that ONE command alone with a sentinel (
echo MARKER; <cmd>) and confirm the marker before trusting the output. A misread here once caused a wrong "make publish does not exist" conclusion - the target existed and had already run. - One synced version, the library leads.
make publishbumpspyproject.toml(PATCH) and uploads to PyPI - that resulting number isvN, the single source of truth for the release. Step 4 then writesvNinto the 22 plugin strings (7plugin.json+ 7kimi.plugin.json+marketplace.jsonmetadata + 7 entries) so library and plugins always match. NEVER publish the library by hand (uv build/twine) - alwaysmake publish. NEVER set the plugin version independently ofvN(do not run/increment-plugin-versionduring release). - EVERY release ships BOTH the CLI and the plugins. There is no plugin-only release. The plugins are documentation for a CLI they cannot function without: skills and commands are written against the current flags, so shipping plugin text without the matching library strands every user on a CLI that rejects the flags the new docs tell them to use. This is not hypothetical - it is the
unrecognized arguments: --svgincident, where plugins at 1.6.31 drove a library at 1.5.5. A "docs-only" change is still a CLI release: runmake publishanyway sovNadvances on both sides together. The only case where the library does not upload ismake publishfailing, and that ABORTS the release - it never downgrades to a plugin-only push. - Verify after every mutating step before proceeding. Publish → confirm the new
pyproject.tomlversion + the PyPI upload. Sync → confirm all 22 plugin strings equalvNand zero stale ones remain. Stage → confirm the staged set matches intent and nothing leaked in. Commit → confirm file count + clean worktree. Push → confirmLOCAL == REMOTE.
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.
- yesterday First seen · 149 lines · 0 tokens per session scan A 64d4aff619c2
release is a command published in the GitHub repository stellarshenson/claude-code-plugins (3 stars, last pushed 2d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,744 tokens. 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-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.