From claude-resources
Release publication discipline: semver decision, tag creation, changelog generation, GitHub Releases. Part of the opt-in ops-skills plugin. Use ONLY when ops_enabled=true. Pair with core/git-workflow §6 for versioning strategy selection.
npx claudepluginhub deandum/claude-resources --plugin go-skillsThis skill uses the workspace's default tool permissions.
A release is a promise: "this version is stable, supported, and downstream-safe." Releases ship with tags, changelogs, and expectations. This skill covers the mechanics of cutting a release safely. For versioning-scheme selection (semver vs. calvert), see `core/git-workflow` §6.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
A release is a promise: "this version is stable, supported, and downstream-safe." Releases ship with tags, changelogs, and expectations. This skill covers the mechanics of cutting a release safely. For versioning-scheme selection (semver vs. calvert), see core/git-workflow §6.
ops_enabled=false — do not publish releases, report the intended release as a follow-upv1.0.0-rc.1 or similar, never as a stable versionUnder semver (MAJOR.MINOR.PATCH):
0.0.X) — bug fixes, no API changes, no behavior changes for existing callers0.X.0) — new features, backwards-compatible additionsX.0.0) — breaking changes, removed or changed behaviorRule: if any existing caller needs to change code to keep working, it is a MAJOR bump. "It's a small change" is not a reason to skip a MAJOR bump — it is a reason to be surprised at how small a breaking change can be.
Under calvert (YYYY.MM.DD or YY.MINOR): the date is the version. No judgment call, no debate.
Before creating the tag, draft the release notes:
Release notes say why each item matters to a user, not what the diff says. "Fixed race in worker pool" beats "Modified pool.go to use sync.Once".
Tags are annotations on commits, not branches:
git tag -a v1.2.3 -m "Release v1.2.3"
Never create a tag from a branch head without confirming the commit. The branch may have moved since your last pull. Always: fetch, confirm the commit SHA, then tag.
See ops/git-remote §4 — push the tag by explicit name:
git push origin v1.2.3
Not --tags. The explicit name is the confirmation step.
gh release create v1.2.3 --notes-file release-notes.md (or the platform's equivalent):
A published release is immutable. If it was wrong:
Deleting a release deletes checksums and signatures that downstream consumers may depend on. Do not.
| Shortcut | Reality |
|---|---|
| "It's a small change, I'll bump PATCH instead of MAJOR." | If anything breaks for a caller, it's MAJOR. Size is irrelevant. |
| "I'll write the release notes later." | You won't. Or you will, and they'll be wrong because the details faded. |
| "Tagging from the branch head is fine — I just pushed." | Someone else may have pushed after. Confirm the SHA. |
| "I'll delete the release and re-cut it — cleaner." | You'll break downstream checksums. Cut a new patch instead. |
"I'll push with --tags to save a step." | You'll push every local tag, including scratch tags. Push by name. |
-a (unannotated tags lose author/date/message)ops_enabled=true confirmed in session context before any release command-a from the exact intended commit SHA--tagsops_enabled=false: release reported as a follow-up with proposed version and draft notes