release

name

release

description

Ship a new version of THIS repo's grounding-rules skill in one step — publish (bump + changelog + commit + tag + push via scripts/publish.sh) then refresh the local plugin install (`claude plugin marketplace update grounding-rules`). Use when the user types /release in the grounding-rules repo, or asks to release / publish / cut a new grounding-rules version. Maintainer-only — this project skill is not shipped to plugin consumers.

/release — ship a new grounding-rules version

One command for the whole pipeline: publish → refresh the local install, so the loop is edit SKILL.md → /release.

Usage

/release [patch|minor|major | X.Y.Z] ["one-line changelog note"]

• No bump arg → patch. minor / major / an explicit X.Y.Z also work.
• The note becomes the CHANGELOG entry. If the user omits it, summarize what changed in skills/grounding-rules/SKILL.md since the last tag in one line and use that — don't invent a generic message.

Steps

1. Locate the repo. Work from the repo root (the dir holding .claude-plugin/plugin.json and scripts/publish.sh). If the CWD isn't it, cd ~/Playground/vibe_coding/grounding-rules.
2. Preflight (report, don't nag). git status to see what's being released (usually edits to skills/grounding-rules/SKILL.md); confirm you're on main. Echo one line: releasing vCUR → vNEXT — <note>. The user typing /release IS the go-ahead — proceed without a second confirmation prompt.
3. Publish. Run scripts/publish.sh <bump-or-version> "<note>". It bumps the version in both manifests, prepends the CHANGELOG, commits, tags v<version>, and pushes to GitHub.
4. Refresh this machine's install. Run claude plugin marketplace update grounding-rules so your local plugin matches the new release.
5. Report. Print the new version, the tag, and remind that other users update with /plugin update grounding-rules.

Guardrails

• /release pushes a public tag. Run it only when the user invoked /release — never speculatively, and never as a side effect of another task.
• If scripts/publish.sh fails (push rejected, tag already exists, bad version), STOP and report the exact failure. Don't force-push or re-tag without asking.
• A release is for skill changes only. Don't cut a version for README / tooling / CI edits — those are plain git commit + git push, not /release.
• Don't edit the skill's content here — /release only ships what's already in the working tree. (To change the skill, edit skills/grounding-rules/SKILL.md first, then /release.)