Borrowing it
Nothing to install: this file belongs to edilsonvilarinho/usage-monitor. 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/edilsonvilarinho/usage-monitor/main/.claude/skills/usage-monitor-release-beta/SKILL.mdgit clone --depth 1 https://github.com/edilsonvilarinho/usage-monitorWrote 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/skills/edilsonvilarinho/usage-monitor/usage-monitor-release-beta)<a href="https://agentmods.dev/skills/edilsonvilarinho/usage-monitor/usage-monitor-release-beta"><img src="https://agentmods.dev/badge/skills/edilsonvilarinho/usage-monitor/usage-monitor-release-beta/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/skills/edilsonvilarinho/usage-monitor/usage-monitor-release-beta"><img src="https://agentmods.dev/badge/skills/edilsonvilarinho/usage-monitor/usage-monitor-release-beta.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.00061 | $0.03233 |
| Opus 5.5 | $0.00024 | $0.01293 |
| Sonnet 5.5 | $0.00012 | $0.00647 |
| Haiku 4.5 | $0.00006 | $0.00323 |
Grade A, and why
usage-monitor-release-beta 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 — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Usage Monitor Beta Release
Run the whole life of a beta for the users who opted into the beta channel (issue #355). Publishing
is the stable release flow (usage-monitor-release) with a
different tag and a different promise: a beta never becomes latest, so nobody outside the
channel receives it.
Operations (the argument picks one)
| Argument | What it does | Section |
|---|---|---|
patch / minor / major |
Publish beta.1 of a new series for the next stable of that type |
Workflow |
next |
Publish beta.N+1 of the open series (the way to fix a bad beta) |
Workflow |
promote |
Publish the stable vX.Y.Z of the open series — the beta "goes to main/master" |
Promote |
withdraw [tag] |
Hide a beta: nobody new is offered it (reversible) | Withdraw |
restore [tag] |
Undo a withdraw |
Restore |
There is no "move the beta to main": the tag already points to a commit on main —
verify-version refuses anything else. The code is merged before the beta exists; what "going to
stable" means is publishing a new, stable build of that code (promote). There is also no
rollback for testers who already installed a beta: the app never downgrades. They leave the beta
when a higher version reaches them — the next beta or the stable.
How the channel works (read before tagging)
- Tag format:
vX.Y.Z-beta.N,N ≥ 1. Nothing else is accepted —verify-versionrejects-rc.1,-betawithout a number and any other suffix, and the Linux updater refuses them too. - The workflow sets
prerelease: trueandmake_latest: falsefor-beta.Ntags. Clients outside the channel read/releases/latest, which the GitHub API never answers with a prerelease — that is the whole protection, and it also covers app versions older than the channel. - Clients inside the channel list
/releases?per_page=20and take the highest non-draft version by SemVer precedence:42.0.0-beta.1 < 42.0.0-beta.2 < 42.0.0. The stable42.0.0therefore reaches every beta tester of the42.0.0series. Turning the channel off never downgrades. X.Y.Zis the next stable version the beta previews. Never tag a beta for a number that is already released as stable:41.0.0-beta.1afterv41.0.0is lower than the running stable and is never offered to anyone.- Packaging: Exe/Dmg carry only
X.Y.Z(jpackage rejects the suffix), Deb/Rpm carryX.Y.Z~beta.N;CURRENT_APP_VERSION, the NSIS installer name, the tarball and the release assets keep the fullX.Y.Z-beta.N.
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 · 175 lines · 61 tokens per session scan A b9ab2da179aa
usage-monitor-release-beta is a skill published in the GitHub repository edilsonvilarinho/usage-monitor (16 stars, last pushed yesterday), licensed MIT. It adds 61 tokens to every session and 3,233 once invoked, about $0.0002 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-10-16.
Other skills, from other repositories
land-and-deploy
Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.
pipeline-digest
Daily release-pipeline digest with a change gate — reports which plugins are pending release, whether main's CI is green, and which branches went stale, and notifies the operator only when that state actually moved since the last run. Use when the operator asks "what moved in the pipeline", "anything to ship"…
ci-cd-ops
CI/CD pipeline patterns with GitHub Actions, release automation, and testing strategies. Use for: github actions, workflow, CI, CD, pipeline, deploy, release, semantic release, changesets, goreleaser, matrix, cache, secrets, environment, artifact, reusable workflow, composite action.
releasing
Automate semantic versioning releases with CHANGELOG validation, comparison link management, GitHub Actions workflow triggering, and monitoring. Scaffold release infrastructure for new projects. Use when user runs /release command, mentions "release version", "cut a release", "create release", "publish release", "tag…
release-please-setup
Scaffold or migrate a repository onto release-please. Generates release-please-config.json, .release-please-manifest.json, and a release-please.yml workflow, plus an opt-in menu of tag-keyed deploy/publish templates (Docker/ECR matrix, frontend host deploy, npm OIDC publish, GitHub Release asset, Fly.io deploy…
land-and-deploy
Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.