Release workflow

Pre-release audit

Before cutting a release, run a cross-cutting audit of the codebase:

/pre-release full           # run all audits (security, perf, regression, docs)
/pre-release security       # security only
/pre-release performance    # performance only

This catches issues that day-to-day feature agents miss because they are domain-scoped. The pre-release audit applies a “what becomes a public commitment?” lens across the full codebase.

This is a one-time gate, not an iterative loop. Run once at feature freeze, triage findings, fix blockers, then run once more as a final check.

Cutting the release

/release [version]

The /release command handles the full flow:

1. Determine version — reads CHANGELOG.md [Unreleased] and suggests semver (patch for fixes only, minor for added features, major for breaking changes)
2. Pre-flight — parallel checks: clean working tree, changelog entries exist, documentation covers all new features
3. Run scripts/release.sh — assembles changelog fragments into CHANGELOG.md, bumps version in all version-bearing files, creates a chore/release-{version} branch
4. MR → merge → tag — the release goes through a branch and MR like every other change. After merge, confirm the merge commit’s own branch pipeline passed, then tag and create the release. A tag starts its own pipeline in which every job gated on a branch or MR does not exist, so nothing else in the pipeline will tell you the commit you are publishing was red; release-pipeline-gate is what enforces it for tag-triggered publish jobs.

GitLab Flow

The template supports two branching models. Choose one during setup and document it in CLAUDE.md:

• Simple (tag on main): feature branch → MR → main → tag. Best for projects that deploy continuously or don’t have a staging/production split.
• Full (with production branch): feature branch → MR → main (staging) → merge to production → tag. Best for projects with a formal release train.