release

Files (1)

• SKILL.md

SKILL.md (first lines)

# /sdlc:release — the agent may act up to the production gate and cannot pass it

Read `sdlc-loop`. Read `environments` from `sdlc.config.json`: `development.autonomy: auto`,
`staging.autonomy: ask`, `production.autonomy: gate`.

## `prepare`
1. List merged PRs since the last release tag with their `Change:` ids (`gh pr list --state merged --search "merged:>=<tag date>"` or GitLab MCP).
2. Draft `CHANGELOG` entries from the intent titles and spec summaries (not from commit messages), grouped by
   change; note `risk: high` items and any compliance sign-offs required by `compliance-policy`.
3. Run `commands.test`, `commands.build`, `commands.lint`. Paste output. Check the eval suite's last run is
   above `evals.passThreshold`.
4. Open a release PR (`release: <version>`) containing the changelog and the checklist below.

## `staging`
Deploy to staging with `environments.staging.deploy` (the hook will ask; confirm with the user), then run the
rollback rehearsal: `environments.staging.rollback`, then deploy again. Record both outputs in the release PR.
Rollback must be the most rehearsed path in the pipeline.

## `approve <id>` (release manager only)
The `role-gate` hook already stops a non-release-manager from reaching this skill when `roles` is populated
in `sdlc.config.json`; do not re-derive that check here. If `roles` is not yet populated (gate inert), ask
the caller to confirm they are a release manager before proceeding. Then print the exact line for them to
run in their own shell, and do not run production commands yourself in this step:
```
export RELEASE_APPROVAL="<release manager name>:<change id or change ticket>"
```
Post "Release <version> authorised by <name>" to the chat channel if `chat.type` is configured (RingCentral MCP),
and add a comment to the release PR. The authorization is also expected as an approval on the CI `production`
environment (GitHub Environments / GitLab protected environment).

## `production`
Requires `RELEASE_APPROVAL` in the environment; the `production-gate` hook blocks otherwise and explains the
route. Trigger the production deploy via the configured command or CI (`gh workflow run sdlc-deploy.yml -f
environment=production`). Watch status; on failure, run `/sdlc:rollback production` immediately and open an
incident intent. On success, tag the release, post to chat, and record the gate decision (`.sdlc/gate.log` has it).

## `status`
Show current version per environment, pending release PRs, and whether the staging rehearsal is recorded.

## Never
- Set `RELEASE_APPROVAL` yourself, edit `.sdlc/gate.log`, or bypass CI environment protection.
- Deploy to production without a recorded staging rollback rehearsal for this version.

From bibutikoley/ai-sdlc-claude, MIT.

More from bibutikoley/ai-sdlc-claude