cut-release

name cut-release description Cuts a new versioned release of claude-code-trace end-to-end without asking any questions. Detects commits since the last ancestral tag, classifies them with conventional-commit rules to pick the semver bump, bumps every version-bearing file in sync, writes the CHANGELOG entry, commits and tags on a release branch, pushes the tag to trigger the GitHub Actions release pipeline, fast-forwards `main` onto the release commit and pushes it, then cleans up the local branch. Use this skill whenever the user mentions cutting, tagging, bumping, or shipping a release — including "cut a release", "release v1.2.3", "tag and release", "bump version", "publish a release", "do a patch release", or "make a new release". Trigger even when the user does not name the version — the skill computes it. Also use proactively when the user finishes a unit of work and asks to publish it. Cut a Release — claude-code-trace Turns "we should release this" into a tagged, pushed, pipeline-triggered, publicly published release with a curated CHANGELOG, in a way that survives the project's strict pre-commit hook chain and stays honest about what's actually shipping. The skill is project-local because the steps depend on this repo's specific shape (three version files, two lockfiles, GH Actions release on v* tag, the spec-drift + test-reflection pre-commit hook pair). Operating mode The skill is fully automated end-to-end and fully synchronous . It never calls AskUserQuestion , never waits for "yes", never branches on user preference, and never runs any command in the background . Every Bash invocation runs in the foreground so the session holds continuously from Phase 1 through Phase 9 — no run_in_background: true , no trailing & , no nohup , no disown . This includes long-running steps like gh run watch in Phase 7; set the Bash timeout parameter to match the expected duration (e.g. 1800000 ms for the release pipeline) rather than detaching. Defaults are deterministic: Scope — always linear: every commit since git describe --tags --abbrev=0 ships. Bump tier — highest conventional-commit tier in the subset (see ${CLAUDE_SKILL_DIR}/references/conventional-commits.md ). BREAKING CHANGE: or !: produces a minor bump while the version is 0.X.Y (pre-1.0 caveat) and a major bump otherwise; the skill never silently promotes to 1.0.0. CHANGELOG — every Added/Fixed bullet is written from commit subjects + diff reads; chore: / docs: / test: / ci: are always skipped. Push order — tag first, then main (so CI sees the tag immediately; main catches up after). The skill aborts (loudly) only on hard preconditions that would corrupt the release: Duplicate version — the proposed vX.Y.Z tag already exists on origin . Abort with Error: vX.Y.Z already exists on origin (commit <sha>). Refusing to release the same version twice. The user must delete the remote tag intentionally if they want a re-release, or bump again. Dirty working tree — uncommitted changes the skill didn't create. Abort with a list of dirty files. npm run check fails — abort and surface the failure verbatim. Before you start Read these references on the first invocation in a session — they describe constants the phase files refer to. ${CLAUDE_SKILL_DIR}/references/project-shape.md — version files, lockfiles, pre-commit hooks, release pipeline wiring. ${CLAUDE_SKILL_DIR}/references/conventional-commits.md — how commit prefixes map to semver bump level. ${CLAUDE_SKILL_DIR}/references/changelog-template.md is loaded when you reach Phase 4. Execution Phase 1 — Inspect and decide Read ${CLAUDE_SKILL_DIR}/steps/phase1-inspect-and-scope.md and follow all instructions. Phase 2 — Build the release branch Read ${CLAUDE_SKILL_DIR}/steps/phase2-build-release-branch.md and follow all instructions. Phase 3 — Bump version files Read ${CLAUDE_SKILL_DIR}/steps/phase3-bump-versions.md and follow all instructions. Phase 4 — Write the CHANGELOG entry Read ${CLAUDE_SKILL_DIR}/steps/phase4-changelog.md and follow all instructions. Phase 5 — Verify, commit, tag Read ${CLAUDE_SKILL_DIR}/steps/phase5-verify-commit-tag.md and follow all instructions. Phase 6 — Push the tag (with duplicate-version preflight) Read ${CLAUDE_SKILL_DIR}/steps/phase6-push-tag.md and follow all instructions. Phase 7 — Watch the pipeline and verify the release is public Read ${CLAUDE_SKILL_DIR}/steps/phase7-publish-github-release.md and follow all instructions. Phase 8 — Push the release commit to main Read ${CLAUDE_SKILL_DIR}/steps/phase8-back-to-main.md and follow all instructions. Phase 9 — Clean up Read ${CLAUDE_SKILL_DIR}/steps/phase9-cleanup.md and follow all instructions. What the skill will NOT do automatically Bypass pre-commit hooks with --no-verify — always fix the underlying issue. Force-push ( git push -f ) to main , the release tag, or any shared branch. Delete a remote tag or remote branch. Cut a major bump ( X.0.0 ) while the version is still 0.X.Y — pre-1.0 the skill caps at minor even when a breaking change is detected. Re-tag an existing version — the duplicate-version preflight in Phase 6 aborts first. The harness's auto-mode classifier may still intercept pushes to shared branches (e.g. git push origin main ) — that is out of skill scope. When it does, surface the error and continue with the remaining phases; the user resolves the push themselves.