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/aethrox/doctrine/release-versioningnpx skills add aethrox/doctrine --skill release-versioninggit clone --depth 1 https://github.com/aethrox/doctrineWrote 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/aethrox/doctrine/release-versioning)<a href="https://agentmods.dev/skills/aethrox/doctrine/release-versioning"><img src="https://agentmods.dev/badge/skills/aethrox/doctrine/release-versioning.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.00084 | $0.01319 |
| Opus 5 | $0.00042 | $0.00660 |
| Sonnet 5 | $0.00017 | $0.00264 |
| Haiku 4.5 | $0.00008 | $0.00132 |
Grade A, and why
release-versioning 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 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.
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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Versioning
The version number and changelog are derived, never chosen by feel. Conventional Commits classifies each change; that classification computes the SemVer bump; the bump renders straight into a Keep a Changelog entry. Skip a step and the other two have nothing to compute from.
Phase 1: Commit classification (Conventional Commits)
Every commit that touches shipped behaviour is typed:
<type>(<optional scope>)!: <description>
<optional body>
<optional footer(s)>
| Type | Meaning | SemVer effect |
|---|---|---|
fix |
bug fix | PATCH |
feat |
new backwards-compatible capability | MINOR |
feat! / fix! / any type with ! or a BREAKING CHANGE: footer |
incompatible API change | MAJOR |
docs, style, refactor, perf, test, build, ci, chore |
no shipped behaviour change | none |
refactorandperfcarry no version bump only if the public interface is unchanged; aperfthat changes a function signature is afeator a breaking change, not aperf.- The
!and theBREAKING CHANGE:footer are the only signals that force a MAJOR bump. Do not infer "this feels big"; if nothing changed for a consumer's existing calls, it is not breaking. - One commit, one logical change. A commit mixing a
fixand an unrelatedfeatforces the classifier to guess; split it. - Write generated commit and changelog prose without em dashes: use a comma, colon, period, or a reworded sentence instead.
Done when every commit in the range to be released has an unambiguous type and, for any breaking one, a BREAKING CHANGE: footer describing what a consumer must change.
Phase 2: Version computation (SemVer)
Given MAJOR.MINOR.PATCH, and reading the range since the last release in Conventional Commit order of precedence (MAJOR beats MINOR beats PATCH; one breaking commit anywhere in the range forces MAJOR regardless of how many fixes sit next to it):
- Any breaking commit → bump MAJOR, reset MINOR and PATCH to 0.
- Else any
feat→ bump MINOR, reset PATCH to 0. - Else any
fix→ bump PATCH. - Else (only non-releasing types) → no release; do not cut one just because time passed.
- Below
1.0.0: MINOR may carry breaking changes by convention (the public API is declared unstable); state this explicitly in the project's README if relied on, since it silently overrides the table above.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 89 lines · 84 tokens per session scan A 8d450b852032
release-versioning is a skill published in the GitHub repository aethrox/doctrine (18 stars, last pushed 23d ago), licensed MIT. It adds 84 tokens to every session and 1,319 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-30.
Other skills, from other repositories
release-openspec
Use this skill when releasing OpenSpec: audit merged work and changeset coverage, decide whether a catch-up changeset PR is needed, prepare or resume the Changesets Version Packages PR, cut a beta or stable release, verify publishing, and polish GitHub release notes. Also use when asked whether an open release PR is…
changelog-writer
Write changelogs for Bifrost releases. Reads git history, bumps module versions following the core→framework→plugins→transport hierarchy, writes transports/changelog.md (enterprise-style) and per-module changelog.md files, and updates version files. Invoked with /changelog-writer or /changelog-writer .
split-commit-into-stack
Split one oversized commit or branch into a stack of independently reviewable Graphite (gt) PRs - deciding what genuinely separates, what is atomic and must stay whole, and proving each lower PR builds and passes without the ones above it. Use when asked to "split this PR", "this commit is too big", "break this into a…
release-checklist
Pre-release safety audit for the Bifrost repo. Scans database migrations changed in a release for high-scale deadlock / lock-contention risks and for work that blocks application boot time, then produces a pass/warn/fail report with a concrete remediation plan. Invoked with /release-checklist [git-ref-range]. Built to…
release-notes
Edit an existing GitHub release's body into the project's bilingual (English + Chinese) template format with a References section built from merged PRs. Use when 修改 release、整理发布说明、release notes、编辑 release 内容、发版后整理、edit release body.
xcodebuildmcp-docs-release-review
Use when reviewing XcodeBuildMCP documentation, CLI command references, website manifest generation, changelog, release notes, and release script changes.