/release

name: release
description: Cuts a project release. Discovers the project's release procedure (Makefile target, RELEASING.md, CI workflow, etc.) and offers to capture it durably if missing. Always invokes /review-release as preflight, proposes a version bump from CHANGELOG, then presents an exact command plan for operator confirmation before executing step-by-step. Halts on first failure rather than attempting rollback.
model: opus

Release - Cut a Project Release

Executes the project's release procedure with safety guards appropriate to a high-blast-radius operation. Discovers the procedure from the project itself rather than dictating one, always runs `/review-release` as preflight, and never pushes past a BLOCKER. Plans before executing; halts on first failure rather than guessing at recovery.

**Scope of action:** local repo and configured remotes. The skill pushes commits, pushes tags, and (when the procedure includes them) publishes to package registries. It does not attempt automatic rollback of partially-executed releases.

**Reversibility note:** local steps (version bump, commit, local tag) are reversible with `git reset` / `git tag -d`. The remote push is effectively irreversible once anyone has fetched. Package-registry publication is irreversible (most registries permit yank but not delete). The skill names each step's reversibility class in the plan.

Philosophy

**High blast radius warrants high friction.** Tagging and pushing a release is the kind of action that should never happen by accident. The skill is generous with confirmation prompts and pessimistic about partial-failure recovery. Auto-execution is never the default.

**Composition, not duplication.** Preflight checking is `/review-release`'s job. This skill always invokes it and fail-stops on red. It does not re-implement the checklist or offer to skip it.

**Discover the procedure, don't invent it.** Release procedure is project-specific — `make release`, `npm publish`, `cargo publish`, `gh release create`, a custom CI workflow, or some combination. The skill searches the conventional surfaces before falling back to asking the user. If asked, it offers durable capture so the next release is fully automated.

**Halt on first failure.** Release sequences are not atomic. A failure halfway through (e.g., tag pushed but `npm publish` failed) leaves the project in a partial state. The skill stops at the first failure and surfaces the partial state for human decision rather than pushing through or guessing at rollback.

Workflow Overview

┌────────────────────────────────────────────────────────┐
│                        RELEASE                         │
├────────────────────────────────────────────────────────┤
│  1. Detect repo context                                │
│  2. Discover release procedure                         │
│  3. If procedure not found: offer durable capture      │
│  4. Determine target version (propose from CHANGELOG)  │
│  5. Idempotence check (scan for partial prior run)     │
│  6. Run /review-release as preflight (fail-stop)       │
│  7. Construct release plan (commands + reversibility)  │
│  8. Present plan + confirm                             │
│  9. Execute step-by-step (one pause at local→remote    │
│     boundary; halt on first failure)                   │
│ 10. Final summary                                      │
└────────────────────────────────────────────────────────┘

Workflow Details

1. Detect Repo Context

Run all of the following; abort cleanly on any failure:

• **Is this a git repo?** `git rev-parse --is-inside-work-tree`. Abort if not.
• **Main branch detection.** Try `git symbolic-ref refs/remotes/origin/HEAD`, then check for `main`, then `master`. Ask the user if none detected.
• **Current branch.** `git branch --show-current`.
• **Working tree clean.** `git status --porcelain`. **Abort if dirty** with the suggestion: "Commit or stash before releasing." Releases from a dirty tree are unsafe.
• **Up-to-date with origin.** `git fetch`, then check `git rev-list --count HEAD..@{u}`. If behind, abort with the suggestion to pull. If ahead, note this (it's expected if the release commit is being prepared locally, but flag it).
• **On the main branch.** If current branch is not the main branch, ask the user to confirm intent — releasing from a non-main branch is unusual but valid (e.g., backport release lines). Do not abort; defer to the user.

2. Discover Release Procedure

Search the following surfaces in order. Stop at the first hit, but record every hit (procedure may span multiple surfaces — e.g., Makefile target + RELEASING.md narrative):

1. **Makefile** — parse for a `release`, `publish`, or `tag` target. Read the recipe. 2. **RELEASING.md** or **RELEASE.md** at repo root. 3. **CONTRIBUTING.md** — look for a section titled "Release", "Releasing", or "Cutting a Release". 4. **CLAUDE.md** (project-level) — look for the same. 5. **package.json** — scripts named `release`, `publish`, `prepublish*`, `version*`, `postversion`. 6. **pyproject.toml** / **Cargo.toml** / equivalent — packaging metadata that implies a publish step. 7. **`.github/workflows/release.yml`** or similar CI release config. 8. **Git tag history** — `git log --tags --simplify-by-decoration --pretty="format:%d %s"` to infer pattern from prior releases (tag format like `v1.2.3` vs `1.2.3`, accompanying commit message convention like `chore: release v1.2.3`).

Record what was found and where. **Prefer executable sources over prose** — a Makefile target is the authoritative procedure if it exists.

3. Offer Durable Capture if Missing

If step 2 found no procedure (no executable target, no prose doc, no CI workflow, no git-tag pattern beyond bare history):

• Tell the user no procedure was discoverable.
• Ask the user to describe the release steps in order.
• Once described, offer four options for where to record them:
• **Makefile target** (Recommended) — executable, ver