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 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/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/aethrox/doctrine/release-versioning"><img src="https://agentmods.dev/badge/skills/aethrox/doctrine/release-versioning.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.01319 |
| Opus 5.5 | $0.00034 | $0.00528 |
| Sonnet 5.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 1mo 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.
- 1mo ago First seen · 89 lines · 84 tokens per session scan A 8d450b852032
release-versioning is a skill published in the GitHub repository aethrox/doctrine (19 stars, last pushed 1mo ago), licensed MIT. It adds 84 tokens to every session and 1,319 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
release-changelog-harness
Chooses ecosystem-native release and changelog tooling (Changesets, Melos, release-plz) plus binary distribution (GitHub Release tarballs, install.sh) when the product is an executable. Use for release CI, install.sh, versioning, CHANGELOGs, shipping MCP/CLI without clone, or meta repos that only ship skills via npx…
aiwg-pr
AIWG-specific pull request delivery workflow for AIWG product/workspace changes; not the generic repository PR process.
artifact-metadata
Manage artifact metadata, versioning, ownership, and review history across the SDLC lifecycle.
git-mirror-audit
Verify configured secondary git mirrors are present and not drifting from the primary remote/default branch.
polish-docs-meta
Finalize documentation and project metadata for a ship-ready release. Use after implementation is complete, tests pass, and devcheck is clean. Safe to run at any stage — each step checks current state and only acts on what still needs work.
aiwg-delivery-pr
AIWG-specific delivery pull request workflow; explicit alias for aiwg-pr, not a generic repository PR guide.