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 helderberto/agent-skills --skill to-releasegit clone --depth 1 https://github.com/helderberto/agent-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/helderberto/agent-skills/to-release)<a href="https://agentmods.dev/skills/helderberto/agent-skills/to-release"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/to-release/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/helderberto/agent-skills/to-release"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/to-release.svg" alt="Reviewed on agentmods" width="80" 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.00033 | $0.01183 |
| Opus 5.5 | $0.00013 | $0.00473 |
| Sonnet 5.5 | $0.00007 | $0.00237 |
| Haiku 4.5 | $0.00003 | $0.00118 |
Grade A, and why
to-release 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 2d 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
To Release
For libraries and other versioned packages. One command, two runs; the PR's state picks the phase: open → prepare, merged → publish. You review and merge in between. This skill never merges.
1. Resolve
gh auth status fails → stop: "Run ! gh auth login, then /hb:to-release again." PR from $ARGUMENTS, else the current branch's: gh pr view <PR> --json number,state,headRefName,baseRefName,mergeCommit,title,body. Closed unmerged → stop.
Versions follow semver: MAJOR.MINOR.PATCH, pre-releases X.Y.Z-<id>.N with alpha < beta < rc < the release. git fetch origin --tags, then sort with git -c versionsort.suffix=- tag --sort=-v:refname: plain v:refname ranks 1.0.0 below its own -rc. The first line is the previous tag; the first without a - suffix is the previous stable. New tags match their format (v1.2.3 or 1.2.3). No tag yet → first release at the manifest version.
Prepare (PR open)
-
Checks:
gh pr checks <PR>red or pending → stop and report. -
Version: a manifest in the PR (
package.json,.claude-plugin/plugin.json,Cargo.toml,pyproject.toml, …) is ahead of the previous tag → use it. Otherwise:- Base bump from the commits since the previous stable:
!orBREAKING CHANGE→ major,feat→ minor, else patch. Below1.0.0, major becomes minor. --pre <id>: previous tag is a pre-release of the same base → same<id>incrementsN, a later<id>restarts at.0, an earlier one stops and reports. Otherwise apply the base bump, then-<id>.0.- No
--preand the previous tag is a pre-release → promote its base (1.0.0-rc.2→1.0.0).
Bump every file that carries the version, including copies the repo's docs require, in each file's own syntax (PEP 440 writes
1.0.0a0; the tag stays semver), and commitchore(release): <tag>. Done when every version-bearing file reads the new version. - Base bump from the commits since the previous stable:
-
Changelog:
CHANGELOG.mdexists without an entry for this version → prepend one in its format and commit. No file → the release notes are the changelog; don't create one. -
Notes: shaped like the previous release (
gh release view <previous> --json name,body): its title, sections, voice, and closing PR ref. Write them from the PR body and the commits since the previous tag; a stable release spans everything since the previous stable, pre-releases included. No previous release →## Added/## Changed/## Fixed, empty ones omitted. -
Draft:
gh release create <tag> --draft --title <title> --notes-file <file>, plus--prereleasefor a pre-release so it never becomes Latest; a draft for this tag exists →gh release edit <tag> --notes-file <file>. A draft creates no tag. Push the branch.
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.
- 2d ago Changed 18cd9de6004f
- 3d ago First seen · 46 lines · 33 tokens per session scan A f4c704fcff64
to-release is a skill published in the GitHub repository helderberto/agent-skills (17 stars, last pushed yesterday), licensed MIT. It adds 33 tokens to every session and 1,183 once invoked, about $0.0001 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-10-20.
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, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple…
production-deployment
Zero-downtime deployments with pre-flight checks, staged rollouts, and rollback plans. Never ship to production without a verified rollback strategy.
shipping-and-launch
A production-release checklist and planning guide for putting software in front of real users. It covers testing, security, monitoring, staged rollout, and rollback, which means returning to the previous working version.
shipping-and-launch
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
finishing-a-development-branch
A process for finishing a completed development branch. A branch is a separate line of code changes that can later be merged or submitted as a pull request.
git-workflow
Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.