release · diff

git:20260604.16a146e to git:20260611.6992d66

5 added, 1 removed. Audit A to A.

---
name: release
description: |
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize
CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and
create the GitHub release. Use when shipping a new plugin version. NOT distributed.
argument-hint: "[patch|minor|major] | [X.Y.Z]"
effort: medium
---
# Plugin Release
Cuts a versioned release of the Elixir/Phoenix plugin. Drives the full
checklist from `CLAUDE.md` (Release + Versioning) so every release is
consistent. **Contributor tooling — not shipped in the plugin.**
## Iron Laws — Never Violate These
1. **NEVER release on a red `make ci`** — the gate runs BEFORE committing. No green, no release.
2. **NEVER `claude plugin tag`** — this is a marketplace layout (`plugins/elixir-phoenix/.claude-plugin/plugin.json`, not repo root). Tag manually: `git tag vX.Y.Z`.
3. **THREE NUMBERS MUST MATCH** — `plugin.json` version == CHANGELOG heading == git tag (`vX.Y.Z`). Verify before pushing.
4. **CONFIRM BEFORE PUBLISHING** — pushing the tag and `gh release create` are outward-facing and hard to reverse. Stop and confirm with the user; show exactly what will be pushed/published first.
5. **USERS ONLY UPDATE ON A `plugin.json` BUMP** — never ship CHANGELOG/code changes without bumping the version, or installed users get nothing (cache).
6. **ALWAYS leave a fresh empty `## [Unreleased]`** — one `[Unreleased]` becomes one version heading; re-add an empty one on top.
7. **NEVER force-push** — `git push --force` is hook-blocked here. If history needs rewriting, the user runs it via `!`.
## Step 0: Preconditions
- On `main`, working tree clean except intended release files. If feature work is uncommitted, commit it first.
- - Determine version. Read current `plugins/elixir-phoenix/.claude-plugin/plugin.json`. Pick bump from `## [Unreleased]` contents:
+ - Determine version. Run `git describe --tags --abbrev=0` FIRST — the last
+ released tag is the bump base, NOT `plugin.json` (which may carry an
+ unreleased phased bump). If `plugin.json` is already ahead of the tag,
+ apply the consolidation check below before picking a number.
+ - Read current `plugins/elixir-phoenix/.claude-plugin/plugin.json`. Pick bump from `## [Unreleased]` contents:
- **MAJOR** — breaking change (removed command, workflow redesign)
- **MINOR** — new skill / agent / command / hook
- **PATCH** — bug fix, doc/reference update, description tweak
- **Consolidation check** (per memory): if several phased branch bumps never released, collapse to ONE bump from the last released tag — don't stack intermediate versions.
## Step 1: Bump `plugin.json` version
Set `"version"` in `plugins/elixir-phoenix/.claude-plugin/plugin.json` to `X.Y.Z`.
(Often already bumped during the feature work — confirm it matches the target.)
## Step 2: Finalize CHANGELOG
In `CHANGELOG.md`:
1. Rename `## [Unreleased]` → `## [X.Y.Z] - YYYY-MM-DD` (today's date).
2. Insert a fresh empty section on top (see `${CLAUDE_SKILL_DIR}/references/templates.md`).
3. Optionally add a one-line summary under the new heading (past releases do).
## Step 3: README + intro (only if needed)
- Update `README.md` ONLY if counts/version callouts changed: skill count, agent
count (`grep -nE "[0-9]+ (skills|agents|specialist)" README.md`), or a version banner.
A pure doc/reference PATCH usually needs **no** README change — verify, don't assume.
- Check `plugins/elixir-phoenix/skills/intro/references/tutorial-content.md` cheat sheet
if commands/skills/agents were added, removed, or renamed.
## Step 4: Gate on `make ci`
Run `make ci` (lint + test + validate + eval-all). **Must be green.** If lint trips on
untracked non-source dirs (e.g. `social/`, `.rtk/`), that is not a code failure — exclude
them, don't ship around real failures. See `${CLAUDE_SKILL_DIR}/references/templates.md`.
## Step 5: Commit
```
git add CHANGELOG.md plugins/elixir-phoenix/.claude-plugin/plugin.json # + README if touched
git commit # message below
```
Commit subject (matches history): `Release vX.Y.Z — <short summary>`
End the message with the `Co-Authored-By` trailer (see `CLAUDE.md`).
## Step 6: Tag
```
git tag vX.Y.Z
```
## Step 7: CONFIRM, then publish (outward-facing)
Show the user the pending commit, tag, and release notes. **On confirmation:**
```
git push origin main
git push origin vX.Y.Z
gh release create vX.Y.Z --title "vX.Y.Z — <summary>" --notes-file <changelog-section>
```
Use the new CHANGELOG section as release notes (extract it to a temp file or `--notes`).
## Step 8: Verify
```
gh release view vX.Y.Z
git describe --tags --abbrev=0 # should print vX.Y.Z
```
Confirm to the user: released, tag pushed, GitHub release live.
## Reference
- `${CLAUDE_SKILL_DIR}/references/templates.md` — CHANGELOG/release-notes templates, gate snippets, gotchas