| 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
- 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.
- 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.
- 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.
- Refresh this machine's install. Run
claude plugin marketplace update grounding-rules so your local plugin matches
the new release.
- 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.)
