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/noisy/noisy-coding/creating-releasesnpx skills add noisy/noisy-coding --skill creating-releasesgit clone --depth 1 https://github.com/noisy/noisy-codingWrote 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/noisy/noisy-coding/creating-releases)<a href="https://agentmods.dev/skills/noisy/noisy-coding/creating-releases"><img src="https://agentmods.dev/badge/skills/noisy/noisy-coding/creating-releases.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 | $0.00073 | $0.00951 |
| Opus 5 | $0.00036 | $0.00476 |
| Sonnet 5 | $0.00015 | $0.00190 |
| Haiku 4.5 | $0.00007 | $0.00095 |
Grade A, and why
creating-releases 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 4d 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 — 87 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Creating releases
Releases here are cut with gh from the CLI — never the GitHub web UI —
and the notes are a PRODUCT SURFACE, not a changelog dump: a future
daemon/agent will quote them verbatim to convince users to upgrade
(that's the plan behind the VersionBadge and #18). Write them for that
reader.
Mechanics (in order)
python3 scripts/bump_version.py X.Y.Z— keeps the four version files in sync (pyproject, uv.lock, dashboard/package.json, plugin.json); NEVER bump by hand, drift once shipped a stale plugin (issue #7).- Commit the bump (
chore: release vX.Y.Z), tagvX.Y.Z, push both:git push origin main vX.Y.Z. gh release create vX.Y.Z -R noisy/noisy-coding --title "…" --notes "…".- The tag triggers the release workflow (verify-version gate + Docker
image with provenance). Watch it (
gh run list --workflow=release) and confirm the tag appears on Docker Hub BEFORE telling the user to update — the image takes ~3-4 min; the marketplace needs no build. - Then follow the
after-production-releaseskill: spoken one-liner + minimal refresh checklist derived from what changed.
Version number
- PATCH — fixes, invisible changes.
- MINOR — anything the user can see or a new capability; big visible UI batches are MINOR too (2.8.0 was a UI overhaul).
- Krzysztof calls the number; suggest one, don't tag until he says.
Release notes — the format that matters
## Highlights
> The section an upgrade-nudging agent should quote.
- **One bold sentence naming what changed for the USER.** Then 1–3
sentences: the pain that existed, what happens now. Write pain-first —
"X used to happen; now Y" beats a feature list.
## Also in this release
- Smaller items, one line each. Real changes only — no refactor noise.
## Upgrade notes
- Derived from WHAT CHANGED (see after-production-release): container
only / plugin only / both halves — with the exact commands, and the
warning that one half without the other leaves cross-boundary bugs
alive when both changed.
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.
- 4d ago First seen · 87 lines · 73 tokens per session scan A 4031f174accc
creating-releases is a skill published in the GitHub repository noisy/noisy-coding (7 stars, last pushed 2d ago), licensed MIT. It adds 73 tokens to every session and 951 once invoked, about $0.0004 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 skills, from other repositories
changelog
Create changelog files for important commits in a PR.
release-cli
Cuts a STABLE CLI release (vX.Y.Z-cli marker tag; not for beta or alpha markers, which this lane silently skips while burning the tag) — the 🚀 Release (CLI) lane builds the Linux packages, publishes the marker release, and dispatches npm publish with provenance. Covers version alignment across package.json and…
release-engine
Cuts a kesha-engine release (bare vX.Y.Z tag) per CLAUDE.md rules — pre-flight audits, engine-only version bump, annotated tag carrying the notes, draft validation with authenticated download, publish, then verify. Refuses to auto-run; user must explicitly invoke. Knows the workflow-frozen-at-the-tag trap, the gh-cli…
start-talking
Start and run an explicit, interactive Cadence Code conversation with Codex or Antigravity using fully local speech input and output. Use only when the user explicitly invokes $start-talking, /start-talking, or asks to start talking with Cadence Code.
voice-ai
Use when voice AI — text-to-speech (ElevenLabs, OpenAI TTS), speech-to-text (Whisper), voice cloning, real-time voice agents. Use when working with voice ai.
release-mechanics
Use when touching anything release-shaped — version bumps, tags, draft releases, npm publish and provenance, the build-engine feature matrix, release/ PRs, bun link, or CI jobs that download a published engine. Explains why CLI and engine version independently, why tag names are one-use, why draft assets 404 for…