authoring-release-runbook

Derive deploy steps from your architecture-doc and technical-design, write each step as an idempotent copy-paste-safe command with an expected result, add a go/no-go gate, and document a revert with measurable triggers for every forward change. This Skill guides that method against an 11-condition executability and safety bar.

A rollback procedure needs measurable trigger conditions such as error rate or SLO burn-rate, a documented revert for every forward change in reverse order, a lever matched to the deploy strategy, and re-verification to the pre-deploy baseline. Irreversible changes like dropped columns need a roll-forward or restore-from-backup path instead.

Sequence schema changes as an expand-contract migration: add the new element alongside the old, migrate the code, then remove the old element in a later release. This keeps every step backward-compatible and independently rollbackable, avoiding a big-bang change with no clean revert.

No. The runbook documents the manual procedure, verification, and rollback around the pipeline and invokes it, but authoring the pipeline YAML or automation config is a separate cicd-plan concern outside this Skill's scope.

Amend when an upstream document changes or an incident exposes a gap. Edit only the affected steps, re-validate the whole procedure end-to-end for broken downstream preconditions, then bump the document version with a changelog entry naming the trigger.