| name | incident-runbook |
| description | Escalation procedure and blast-radius checks for risky or destructive infrastructure changes. Use this before any destroy, credential rotation, or production change to decide the approval path and required sign-off. |
| metadata | {"domain":"infrastructure","risk":"high"} |
Incident Runbook
Use this skill before any destructive action, credential rotation, or production change. It
decides the blast-radius rating and the approval path the plan must take.
Blast-radius check
Before approving, answer three questions and record the answer in ChangePlan.blast_radius:
- Environment — production, staging, or dev? Production multiplies risk.
- Scope — how many downstream services depend on this resource? List every dependent
in
affected_services. Three or more is a wide blast radius.
- Reversible? — is there a clean rollback (snapshot, prior config, re-issue)? If not,
set
reversible: false and treat the change as high risk.
A change is high blast radius if it is irreversible, touches a stateful resource, or
fans out to three or more services.
Escalation and approval path
- low / medium risk → a single human confirmation before
apply_change is enough.
- high risk → confirmation plus an audit-trail entry. The
apply_change tool already
records high-risk and destructive executions to the approval audit trail; do not bypass
it.
- destroy on a stateful resource → there must be a verified snapshot, and the first
rollback_steps entry must be restoring from it. Check the resource's latest snapshot
with inspect_resource; if one is on record, name it in the rollback step and proceed to
the gated approval. Only if there is genuinely no snapshot on record do you stop and
surface that instead of asking for approval.
Credential rotation
- Rotate by name only. Never read, echo, or log the old or new secret value.
- A production credential rotation is always at least
high risk: dependents must pick up
the new value, and a bad rotation can take down every service that uses it.
- Rollback for a rotation is re-issuing or re-enabling the prior credential, not printing
it — note that in
rollback_steps without naming any secret value.
After approval
When the human approves, call apply_change once with a one-line summary. If the human
rejects, stop — no retries, no workarounds. Report that no change was made.
