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/arjunprabhulal/devops-skills/release-managementnpx skills add arjunprabhulal/devops-skills --skill release-managementgit clone --depth 1 https://github.com/arjunprabhulal/devops-skillsWrote 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/arjunprabhulal/devops-skills/release-management)<a href="https://agentmods.dev/skills/arjunprabhulal/devops-skills/release-management"><img src="https://agentmods.dev/badge/skills/arjunprabhulal/devops-skills/release-management.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.00089 | $0.01322 |
| Opus 5 | $0.00044 | $0.00661 |
| Sonnet 5 | $0.00018 | $0.00264 |
| Haiku 4.5 | $0.00009 | $0.00132 |
Grade A, and why
release-management 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 6d 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 — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Management
Release management is a coordination problem, not a technical one — the hard part is rarely cutting the tag, it's making sure everyone (consumers of a library, downstream services, users reading changelogs, on-call engineers) agrees on what "version 2.4.0 is live" actually means. Teams that skip this discipline end up with versions that don't map to any coherent set of changes, changelogs nobody trusts, and multi-service releases that go out in the wrong order.
A version number is a promise to consumers about what changed and whether it's safe to adopt — treat it as an API, not a label.
A release is a communication artifact as much as a deployment event — get the meaning right, not just the mechanics.
1. Use semantic versioning as a contract, not a convention
MAJOR.MINOR.PATCH only works if every consumer can trust it: major means breaking changes, minor means backward-compatible additions, patch means backward-compatible fixes. The instant a team bumps a patch version for a breaking change "because it was small," semver stops being a contract and every downstream consumer has to read the diff anyway, which defeats its entire purpose. This matters most for anything with external consumers — libraries, public APIs, CLIs; internal services deployed continuously can often skip strict semver in favor of the git SHA or build number as the real identity, with semver reserved for anything versioned independently of deploy cadence.
- Breaking change → major, no exceptions, even if it "seems small."
- New capability, backward compatible → minor.
- Fix only, no interface change → patch.
Done when: a consumer can decide whether to upgrade by reading the version number alone, without reading the diff.
2. Generate changelogs from the source of truth, not from memory
A changelog written by someone trying to remember what happened over the last sprint is unreliable and always lags reality. Generate it from commit messages (conventional commits), PR titles, or linked issues at release-cut time, and have a human edit for clarity rather than write from scratch. The goal is a changelog a user can act on — "what do I need to know before upgrading" — not a raw commit dump.
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.
- 6d ago First seen · 113 lines · 89 tokens per session scan A d1ac743ba22b
release-management is a skill published in the GitHub repository arjunprabhulal/devops-skills (3 stars, last pushed 12d ago), licensed MIT. It adds 89 tokens to every session and 1,322 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
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…
comet-archive
Comet Classic 阶段 5 —— 确认归档、合并 delta spec 并完成分支收尾。.
finishing-a-development-branch
当实现完成、所有测试通过、需要决定如何集成这份工作时使用.
skillshare-changelog
Generate CHANGELOG.md entry from recent commits in conventional format. Also syncs the website changelog page. Use this skill whenever the user asks to: generate a changelog, document what changed between tags, or create a new CHANGELOG entry. If you see requests like "write the changelog for v0.17", "what changed…
skillshare-release
End-to-end release workflow for skillshare. Runs tests, generates changelog (via /changelog), optionally writes local RELEASENOTES, updates version numbers, commits, and drafts announcements. Use when the user says "release", "prepare release", "cut a release", "release v0.19", or any request to publish a new version.…
prepare-release
Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run /prepare-release.