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.

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.

incident-runbook