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/after-production-releasenpx skills add noisy/noisy-coding --skill after-production-releasegit 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/after-production-release)<a href="https://agentmods.dev/skills/noisy/noisy-coding/after-production-release"><img src="https://agentmods.dev/badge/skills/noisy/noisy-coding/after-production-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.00084 | $0.00804 |
| Opus 5 | $0.00042 | $0.00402 |
| Sonnet 5 | $0.00017 | $0.00161 |
| Haiku 4.5 | $0.00008 | $0.00080 |
Grade A, and why
after-production-release scanned grade A with 1 finding 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 5d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
truth with `curl -s https://raw.githubusercontent.com/noisy/noisy-coding/main/.claude-plugin/plugin.json | grep version`. How it starts
The opening of the file, as written. The whole thing — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
After a production release: tell the user exactly how to refresh
Every release ends with the same user question: "what do I do now?" Sometimes it is one step, sometimes three — never make the user derive it. After the image lands on Docker Hub (verify — don't announce before the build is green), ALWAYS deliver:
- aloud: one sentence naming the release and how many steps it costs ("2.7.7 — one command, container only"); speak the user's language, the examples here are just templates;
- in the console: a numbered checklist of ONLY the required steps, in order, with nothing optional mixed in.
Deriving the steps — look at what the release actually changed
| Changed in this release | Required step |
|---|---|
src/noisy_coding/**, Dockerfile, dashboard/** |
container: /noisy-coding:update once, any production thread (pulls, quotes Highlights, recreates; volume/key survives) |
hooks/**, commands/**, skills/**, .claude-plugin/** (plugin payload) |
plugin: claude plugin update noisy-coding@noisy — ONCE PER PROFILE (work + CLAUDE_CONFIG_DIR=~/.claude-personal for personal) |
| plugin payload (as above) | reload: /reload-plugins (or restart) IN EVERY LIVE SESSION — sessions opened after the update pick it up themselves |
Compose the checklist from the rows that apply. Common shapes:
- Image-only (daemon/server/dashboard fix): 1 step —
/noisy-coding:update. - Plugin-only (hooks/commands/skills): 2 steps × profiles — plugin update per profile, reload per session. No container touch.
- Both halves (e.g. a fix spanning mcp_exec.sh AND server.py): 3 steps — plugin update per profile → reloads →
/noisy-coding:update. Say explicitly that ONE half alone leaves the bug alive (see the 2.7.6 lesson: container on 2.7.6 with plugins on 2.7.5 still misroutes).
Gotchas to mention when relevant
- The marketplace has no build step — the new plugin version is available
the second the bump lands on
main. Ifplugin updatestill fetches the old one, it is the local catalog cache: retry in a moment. Check ground truth withcurl -s https://raw.githubusercontent.com/noisy/noisy-coding/main/.claude-plugin/plugin.json | grep version. - The Docker image DOES take ~3–4 min after the tag — never announce the update instructions before the release workflow is green and the tag shows on Docker Hub.
- The dev instance is separate: restart
scripts/dev_daemon.shfor daemon changes,npm run build+ tab reload for dashboard changes — only when the user is actively using dev.
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.
- 5d ago First seen · 55 lines · 84 tokens per session scan A 0c4f56744f0b
after-production-release is a skill published in the GitHub repository noisy/noisy-coding (8 stars, last pushed today), licensed MIT. It adds 84 tokens to every session and 804 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). 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…