Borrowing it
Nothing to install: this file belongs to ractive/hyalo. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/ractive/hyalo/main/.claude/skills/release/SKILL.mdgit clone --depth 1 https://github.com/ractive/hyaloWrote 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/ractive/hyalo/release)<a href="https://agentmods.dev/skills/ractive/hyalo/release"><img src="https://agentmods.dev/badge/skills/ractive/hyalo/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/ractive/hyalo/release"><img src="https://agentmods.dev/badge/skills/ractive/hyalo/release.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.00102 | $0.01899 |
| Opus 5.5 | $0.00041 | $0.00760 |
| Sonnet 5.5 | $0.00020 | $0.00380 |
| Haiku 4.5 | $0.00010 | $0.00190 |
Grade A, and why
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 26d 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 — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release hyalo
Cuts a release vX.Y.Z from main. The GitHub Release publish event is
what triggers the build/package pipeline (.github/workflows/release.yml,
shared via ractive/release-workflows) — so the release is created last,
after everything on main is final.
Hard rules
- NEVER create git tags manually.
gh release createmakes the tag. - CI enforces tag == workspace
Cargo.tomlversion; mismatch fails the pipeline after the tag exists — check the version BEFORE releasing. - Everything lands on
mainbefore the release is created. The mechanical release commits (version bump, changelog rotation) go directly on main — a release is a synchronous maintainer act; don't spin up a PR for them. - Every
hyaloinvocation below meanstarget/release/hyalo(build it first if stale). The barehyaloon PATH is the previously installed release — it predates the version being cut and will reject new config keys/flags (v0.18.0 example: it choked on[changelog]in.hyalo.tomland didn't knowlint --profile).
1. Preconditions
Decide the version from the [Unreleased] contents (pre-1.0 convention
here: minor bump for features/breaking, patch for fix-only). Check published
versions across channels before choosing it: gh release list --limit 5 and
npm view @ractive-ch/hyalo versions --json, plus the target versions of the
npm platform packages and crates when publishing those. A missing GitHub tag
does not mean the version is unused. If a channel already published that
version from older source, choose a fresh version for the new changes across
channels; immutable package versions cannot be replaced. Completing a partial
release at an existing version is only appropriate for the same source and
artifacts, using the publication workflow's existing-version checks.
The 2026-09-13 dogfood found exactly this split: GitHub's latest was 0.21.0,
npm already shipped 0.23.0, and CHANGELOG.md had both a dated [0.23.0]
section and substantial [Unreleased] content. Releasing the new work therefore
needs a new version (0.24.0 for the current feature-bearing changes), preserving
the existing 0.23.0 history. Recheck registry state when actually releasing.
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.
- 26d ago Changed · +6 lines 6a77c58677e6
- 1mo ago Changed · +24 lines de32171ea8ac
- 2mo ago First seen · 121 lines · 102 tokens per session scan A 2481fc6a9155
release is a skill published in the GitHub repository ractive/hyalo (27 stars, last pushed 5d ago), licensed MIT. It adds 102 tokens to every session and 1,899 once invoked, about $0.0004 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-notes
Compare the repository with the team's Folio wiki and write release notes: read git log since the last tag, read the Roadmap table, create or update a Release notes page and add what the roadmap table is missing. Use when asked for release notes or to sync the wiki with the code.
release-note-captain
Use this skill when a project is finished, shipped, deployed, published, or released and the user wants a release note created or updated in Obsidian. It covers collecting release facts, choosing the note path, writing a concise release summary, updating existing notes safely, and preserving follow-up actions.
synthetic-release-notes
Draft release notes from user-provided changes.
publish-pr
Use in /implement at the draft→ready boundary to squash the branch's review-iteration commits into one (non-interactive soft-reset + recommit + force-with-lease) and mark the draft PR ready. Takes the commit message as input (sourced from the plan-file before cleanup). GitHub-specific (gh) behind a host-neutral…
changelog-writer
Use when a release is being prepared and a human-readable changelog must be generated from merged pull requests.
release-rollback
A release and rollback checklist for code or scripts, covering readiness checks, release decisions, and recovery after an incident.