ai-sdlc-claude

Release manager

Read time: 8 minutes.

What this is

Claude prepares releases: changelog from the accepted intents, checks, eval pass rate, staging deploy, and a rollback rehearsal. It cannot release to production. The production gate is three layers deep (a hook that needs your named authorization, CI environment approval, and in regulated orgs a managed setting), and every decision at the gate is logged with a timestamp. Rollback is a single rehearsed command.

Your commands

/sdlc:release status              versions per environment, pending release PRs, rehearsal recorded?
/sdlc:release prepare             changelog + checks + eval rate → release PR with checklist
/sdlc:release staging             deploy to staging, rollback, redeploy (recorded)
/sdlc:release approve <id>        prints your authorization line; posts to chat and the release PR
/sdlc:release production          runs only with RELEASE_APPROVAL present
/sdlc:rollback <env> --reason ""  the one rehearsed command, then verification and an incident intent

A release, step by step

1. /sdlc:release prepare: Claude lists merged PRs since the last tag with their change ids, drafts the changelog from intent titles and spec summaries (not commit messages), runs build/test/lint, checks the eval pass rate, and opens a release PR with the checklist. High-risk items and compliance sign-offs are called out.
2. /sdlc:release staging: deploy to staging (the hook asks you to confirm), then rollback, then deploy again. Both outputs go in the release PR. No production release without a recorded rehearsal for that version.
3. /sdlc:release approve <id>: Claude checks you are listed as a release manager and prints, for you to run in your own shell:

   export RELEASE_APPROVAL="<your name>:<change id or change ticket>"
   

   It posts “Release authorised by " to the chat channel (RingCentral) and the release PR. In CI the same authorization is your approval of the `production` environment (GitHub) or pressing play on the protected job (GitLab); the approver's name becomes `RELEASE_APPROVAL` automatically.

4. /sdlc:release production: with the authorization present the deploy runs and the decision is logged to .sdlc/gate.log. Without it, this is what anyone sees:

   Production deploys need a named release authorization. Route to approval: the release manager runs
   '/sdlc:release approve <change-id>' ...
   

Rollback

/sdlc:rollback production --reason "5xx spike after 2.4.0": runs environments.production.rollback, verifies the metric is back at baseline (Sentry/Grafana), writes sdlc/incidents/<id>/intent.md, posts to the channel. The control-band job can trigger the same runbook automatically at 3σ post-deploy errors; the environment approval still applies. Staging rehearses rollback weekly by schedule so the path is proven before it is needed.

What only you can do

Authorise production. Decide to roll back. Nothing and nobody can set RELEASE_APPROVAL on your behalf.

What you never have to do

Assemble a changelog, run deployment runbooks by hand under pressure, or wait for a change advisory board meeting: the gate is enforced every time, for everyone, and the evidence is attached.

How you know it is working

/sdlc:metrics: wait per gate visible and falling; gate violations reaching production at zero; DORA measures from the pipeline.

This site is open source. Improve this page.