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/jpantsjoha/ai-native-developer-experience/release-managernpx skills add jpantsjoha/ai-native-developer-experience --skill release-managergit clone --depth 1 https://github.com/jpantsjoha/ai-native-developer-experienceWrote 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/jpantsjoha/ai-native-developer-experience/release-manager)<a href="https://agentmods.dev/skills/jpantsjoha/ai-native-developer-experience/release-manager"><img src="https://agentmods.dev/badge/skills/jpantsjoha/ai-native-developer-experience/release-manager.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.00064 | $0.01425 |
| Opus 5 | $0.00032 | $0.00713 |
| Sonnet 5 | $0.00013 | $0.00285 |
| Haiku 4.5 | $0.00006 | $0.00143 |
Grade A, and why
release-manager 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 — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Manager
A release without a confirmed process is a deployment. A deployment without a rollback plan is a gamble.
This skill governs the release process itself — not a specific deployment (that is
release-readiness) and not the CI infrastructure (that is github-manager). It ensures
the team has agreed, documented, and is consistently following a versioning and release
strategy, anchored by an ADR.
When to use
- Setting up the release process for a new repository
- Before the first public or production release of a project
- When release practice has become inconsistent: manual uploads, skipped tags, changelog gaps, or no named release owner
- As part of the bootstrap workflow, when the automation area is being defined
- When
delivery-orchestratoridentifies a release-process gap during R2/R3 classification
Operating model context
Three release-adjacent skills exist in this harness with distinct responsibilities:
| Skill | Responsibility |
|---|---|
github-manager |
CI trigger configuration, runner cost, branch protection, tag-event wiring |
release-manager (this skill) |
Process governance: SemVer discipline, changelog, ADR, deviation authority |
release-readiness |
Go/no-go gate for a specific deployment: failure modes, rollback, monitoring |
Use all three in sequence for a new project. Use release-manager alone when auditing or
repairing an existing process. Always hand off to release-readiness before the tag is
pushed.
Default release strategy
Unless a team ADR explicitly records a different approach, the default is:
- Versioning: Semantic Versioning —
MAJOR.MINOR.PATCHPATCH— backwards-compatible bug fixesMINOR— backwards-compatible new capabilityMAJOR— breaking changes
- Tagging:
v{MAJOR}.{MINOR}.{PATCH}tags on the default branch trigger release builds in CI. No other event produces a release artifact. - Artifacts: produced by CI from the tagged commit — never from a local workstation.
- Changelog:
CHANGELOG.mdupdated before every release; format follows Keep a Changelog. - GitHub release: created by the CI pipeline, linked to the tag, with the changelog entry as its body.
- Release authority: the named release owner (recorded in the operating profile)
approves and pushes version tags. No one else pushes
v*tags to the default branch. - Source of record: this repository's issues, ADRs, and architecture docs are the source of truth unless a team ADR explicitly records otherwise.
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 · 138 lines · 64 tokens per session scan A 4c62d171a8da
release-manager is a skill published in the GitHub repository jpantsjoha/ai-native-developer-experience (11 stars, last pushed 28d ago), licensed Apache-2.0. It adds 64 tokens to every session and 1,425 once invoked, about $0.0003 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
push-ci
Push to remote and monitor CI. Validates branch safety, executes git push WITH explicit user approval, then monitors CI run status via gh CLI. Use when: user says 'push', 'push and watch CI', 'ship it', 'push-ci'. Not for: committing (use /smart-commit), creating PRs (use /create-pr), merging (use /merge-prep).
v1-milestone
Factory line for executing one milestone of the HAR v1.0.0 refactor (epic os-factory/har#225) — plan the wave of parallel subagents, implement each issue in its own HAR slot, ship stacked PRs, run the fixture-e2e milestone gate, and hand off for review. Use when asked to "run the next v1 milestone", "work on v1.0.0"…
task-final-report
Apply the final report and PR publication procedure for a Hyper-Waterfall task. Write the final report (report.md), mark the daily task board complete, create the final commit, push the remote publish/task{N} branch, and create an Open PR to {BASEBRANCH}. Invoke only immediately before PR publication after all stages…
release
Release a new version of the mumei repository. Invoke when the user gives an explicit release instruction ("release it", "/release", "patch release", "ship 0.2.0"). Takes no argument or "patch" / "minor" / "major" for a SemVer bump, or a direct version such as "0.2.0". Wraps any uncommitted changes into a single…
release
Release vercel-plugin — run gates, bump version, generate artifacts, commit, and push. Use when asked to "release", "ship", "bump and push", or "cut a release".
release-cut
Cut a Torque Loop release end-to-end and stop at the PR — branch, bump all five version fields, promote the CHANGELOG with lineage + slogan, verify with npm test + doctor, commit chore(release). Use when [Unreleased] has earned a version. Never merges, tags, or publishes a Release; those are Danny's.