Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/karlkfi/claude-bouncernpx agentmods add commands/karlkfi/claude-bouncer/releaseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/karlkfi/claude-bouncer/release)<a href="https://agentmods.dev/commands/karlkfi/claude-bouncer/release"><img src="https://agentmods.dev/badge/commands/karlkfi/claude-bouncer/release.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00015 | $0.00859 |
| Opus 5 | $0.00008 | $0.00430 |
| Sonnet 5 | $0.00003 | $0.00172 |
| Haiku 4.5 | $0.00002 | $0.00086 |
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 8d 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cut a release. docs/development/release-process.md is the authority: read it
before deviating from anything below, and do not restate it back to the user.
$ARGUMENTS is empty (survey all five), a plugin name, or a plugin name and a
level. A level given here is the user's call — do not talk them out of it, but
say so if the evidence points elsewhere.
1. Get the facts
python3 scripts/release.py status --notes $ARGUMENTS
Each plugin comes back with its version, its delta since its own last tag, the
## Release note line each author wrote, and a verdict of release, hold, or
none. The verdict is a starting point, not the answer. It reads commit
types and harvested notes; it cannot read a diff. A None sitting beside a
change that moves a decision is the one failure CI cannot catch, so read the
commits under any hold before accepting it.
2. Choose the level, from what the change did to the guard's decisions
The runbook's axis, not a generic SemVer table: did the set of decisions move, in either direction? Patch is the same decisions, better. Minor is the boundary moving, including new denials. Major is identity or configuration breaking — a rename, a removed override, an inverted default verdict.
State the level per plugin with the evidence you chose it from, then confirm the whole plan with the user before writing anything. For a multi-plugin cut, one release PR carries every plugin, and each gets its own tag afterwards.
3. Write the notes
One file per tag at plugins/<name>/docs/releases/vX.Y.Z.md, holding the body
verbatim with no title heading. Read a shipped one first — the three plugins
with a docs/releases/ directory have thirty between them. Harvested notes
are the bullets, not raw material for them.
Anything merged before the consolidation needs a full URL rather than a bare
#NNN: PR numbers restarted at #1 here, so #175 links to the wrong repo's
pull request.
Put the draft through deslop and verify-claims before opening the PR. These
notes are the most-read prose the project ships, and a published body is
corrected only by fixing the file, landing it, and re-publishing.
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.
- 8d ago First seen · 82 lines · 15 tokens per session scan A cdb21a72eaaf
release is a command published in the GitHub repository karlkfi/claude-bouncer (3 stars, last pushed today), licensed MIT. It adds 15 tokens to every session and 859 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-31.
Other commands, from other repositories
update-documentation
You are a release engineer responsible for maintaining the root-level CHANGELOG.md and verifying plugin READMEs. Analyze git changes, update the single CHANGELOG.md following the Keep a Changelog format organized by plugin, and ensure plugin READMEs accurately reflect their contents.
doc-changelog
Generation and maintenance of the project changelog.
ops-gitflow
Manage the GitFlow branching model: init, feature, release and hotfix branches.
work-flow-release
Complete workflow to prepare and publish a release.
ops-release
Release workflow with changelog and versioning.
sync-ecosystem
Detect API changes, sync satellite repos, and publish releases.