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 majiayu000/spellbook --skill release-engineeringgit clone --depth 1 https://github.com/majiayu000/spellbookWrote 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/majiayu000/spellbook/release-engineering)<a href="https://agentmods.dev/skills/majiayu000/spellbook/release-engineering"><img src="https://agentmods.dev/badge/skills/majiayu000/spellbook/release-engineering/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/majiayu000/spellbook/release-engineering"><img src="https://agentmods.dev/badge/skills/majiayu000/spellbook/release-engineering.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.00069 | $0.00432 |
| Opus 5.5 | $0.00028 | $0.00173 |
| Sonnet 5.5 | $0.00014 | $0.00086 |
| Haiku 4.5 | $0.00007 | $0.00043 |
Grade A, and why
release-engineering 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.
What it actually says
Release Engineering
Purpose
Use this skill to turn "ready to merge" into a controlled release. It connects code, data, config, deployment, monitoring, and rollback.
Release Classification
Classify the release before choosing gates:
| Type | Extra Gates |
|---|---|
| Patch fix | focused regression test, rollback proof |
| Feature release | feature flag, docs/changelog, product acceptance |
| API or SDK change | versioning, deprecation, compatibility tests |
| Database migration | data-contract-migrations, backup, backfill, recovery |
| Config or secret change | config-secrets-environments, rotation, drift check |
| Infrastructure change | canary, health checks, capacity and rollback |
Release Plan
For non-trivial releases, require:
- Version or release identifier.
- Changelog entries grouped by user impact.
- Build artifacts and provenance.
- Migration and config gates.
- Canary or staged rollout plan.
- Monitoring dashboard and alert expectations.
- Rollback or roll-forward command.
- Owner, decision time, and abort criteria.
Verification
Use fresh commands from the current session. Typical gates:
git status --short
git log --oneline -n 5
# project-specific build/test command
# migration dry run or validation query
# deployment health check
Do not claim a release shipped unless remote git, CI, artifact, and runtime state have each been checked at the required level.
Output Shape
release_scope:
version_or_identifier:
included_changes:
excluded_changes:
pre_release_checks:
rollout_steps:
migration_and_config_gates:
monitoring:
rollback_or_recovery:
go_no_go_status:
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 · 66 lines · 69 tokens per session scan A d40a3d93ef72
release-engineering is a skill published in the GitHub repository majiayu000/spellbook (288 stars, last pushed yesterday), licensed MIT. It adds 69 tokens to every session and 432 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-09-03.
Other skills, from other repositories
lov-release-via-cicd
A release workflow for Node, Tauri, Vite, shell, and GitHub Release projects. It checks or configures automated versioning and publishing, including macOS signing and notarisation when relevant.
release
This skill should be used when the user asks about "release process", "versioning", "semantic versioning", "semver", "release automation", "publishing", "package publishing", "release checklist", "version bump", "release notes", or needs guidance on release workflows and version management.
yocto-ci-release
Yocto CI, reproducible build, and release engineering skill for AI coding agents. Use for kas, repo manifests, Git submodules, containerized builds, CI runners, downloads and sstate caches, hash equivalence, PR build gates, QEMU tests, hardware smoke tests, artifact publishing, SDK releases, SBOM/license manifests…
shell-scripting
Use when a ticket adds or changes shell scripts — bash automation, CI steps, install or release scripts, git hooks, Makefile recipes — and they must follow the Google Shell Style Guide, be safe under set -euo pipefail (knowing its caveats), quote every expansion, clean up temp files and locks, stay portable across GNU…
land-and-deploy
Land and deploy workflow. Merges the PR, waits for CI and deploy, verifies production health via canary checks. Takes over after /ship creates the PR. Use when: "merge", "land", "deploy", "merge and verify", "land it", "ship it to production". (gstack).
github-release-workflow
Create GitHub releases and verify CI-built assets.