Borrowing it
Nothing to install: this file belongs to jens-duttke/usage-monitor-for-claude. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/jens-duttke/usage-monitor-for-claude/main/.claude/commands/releasing.mdgit clone --depth 1 https://github.com/jens-duttke/usage-monitor-for-claudeWrote 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/jens-duttke/usage-monitor-for-claude/releasing)<a href="https://agentmods.dev/commands/jens-duttke/usage-monitor-for-claude/releasing"><img src="https://agentmods.dev/badge/commands/jens-duttke/usage-monitor-for-claude/releasing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/jens-duttke/usage-monitor-for-claude/releasing"><img src="https://agentmods.dev/badge/commands/jens-duttke/usage-monitor-for-claude/releasing.svg" alt="Reviewed on agentmods" width="80" 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.00032 | $0.01976 |
| Opus 5.5 | $0.00013 | $0.00790 |
| Sonnet 5.5 | $0.00006 | $0.00395 |
| Haiku 4.5 | $0.00003 | $0.00198 |
Grade A, and why
releasing 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 1mo 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prepare a release for version $ARGUMENTS (a semantic version like 1.21.0). If no version was given, ask for it before doing anything.
Work through the steps sequentially, and stop at the first failure - a half-prepared release is worse than none. Respect the project git rule: never commit, tag, or push - this command edits files, builds the artifact and hands the final command sequence back to the user to run.
Step 1: Preflight - do not touch a single file before this passes
Every check here failed at least once in a real release and cost the whole run. Run them first, in this order.
- Sync with the remote.
git fetch origin, thengit rev-list --left-right --count origin/main...HEAD. Anything other than0on the left means the remote has commits you do not have: stop. Rolling the changelog on a stale tree produces a section that silently omits whatever was pushed meanwhile, and the tag would point at a tree without it. Report what is missing (git log --oneline HEAD..origin/main) and let the user decide how to integrate it. - Clean working tree.
git status --porcelain. Uncommitted or untracked changes mean the tag would not describe what you built: stop and report them. (Untracked scratch files are the usual case - they belong in.gitignoreor in the bin, and that is the user's call.) - Tests green before any edit. Activate the virtual environment, run
python -m unittest discover -s tests. If the suite is already red, stop - the defect belongs to the branch, not to the release, and fixing it is a separate task the user must approve.
The suite must run unattended. If it blocks on a dialog, a prompt or a mysteriously long runtime, treat that as a defect to fix, not something to click away: a test that reaches a real Win32 dialog is also touching the real system.
Step 2: Bump the version
Set the new version in both places (all fields must match exactly):
usage_monitor_for_claude/__init__.py-__version__version_info.py- all four fields:filevers,prodvers,FileVersion,ProductVersion
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.
- 1mo ago Changed b1a559851764
- 1mo ago Changed · +48 lines · +11 tokens per session b375e306f927
- 1mo ago First seen · 60 lines · 21 tokens per session scan A 9e5f927d7c42
releasing is a command published in the GitHub repository jens-duttke/usage-monitor-for-claude (325 stars, last pushed 4d ago), licensed MIT. It adds 32 tokens to every session and 1,976 once invoked, about $0.0001 per session on Opus 5.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 commands, from other repositories
icpg-bootstrap
Infer ReasonNodes from existing git commit history. One-time setup for existing codebases.
pull-repos
Pull all repos (parent + marketplace clones + configured project repos).
quality
A command for temporarily clearing a release quality gate or one named check, while recording the reason and expiry time. A quality gate is a required check that normally blocks completion or release.
session-report
Capture what changed this session and why, scoped to the current branch. Read by ship verbs when synthesizing the commit message; deleted after a successful commit.
git-workflow
Run review, tests, and commit steps, then prepare a pull request.
release-tag
Create and push a version tag after a release PR has been merged.