Build service-specific incident runbooks with evidence-bound triggers, safe action branches, rollback, escalation, communication, and rehearsal gates.
A runbook is only useful when someone can trust it under pressure. Generic checklists tend to skip the hard parts: what evidence should trigger an action, when an operator must stop, how to roll back, who can authorize risk, and what to say when the situation changes.
This skill turns system evidence into a service-specific operational runbook. It traces sources, separates verified facts from assumptions, defines measurable triggers, and writes diagnostic and mitigation branches with preconditions, expected signals, stop conditions, rollback, escalation, and verification. It also covers ownership, customer and stakeholder updates, stale-runbook handling, and rehearsals—including a deliberate failed-action path—without pretending that proposed commands have run.
The package includes a strict JSON record format and a read-only checker for structure, references, gates, rehearsal evidence, and verdict consistency. In a blind three-arm evaluation using 12 fresh read-only contexts with gpt-5.6-sol, the packaged skill scored 100/100 across three representative cases, compared with 70.83 for the baseline agent and 80.42 for the exact free upstream. Those are controlled evaluation results, not customer outcome claims. The skill does not execute production changes, replace service owners, or make missing authority disappear.
Input
Checkout depends on a payment provider. We have latency and error-rate alerts, a secondary provider behind a flag, a manual reconciliation job, and status-page ownership, but the failover can duplicate authorizations if used after capture begins.
Output
A source-linked runbook with measurable activation triggers; read-only diagnostics; a capture-state gate before failover; owner and approval requirements; stop, rollback, reconciliation, and verification branches; customer-update checkpoints; a deliberate failed-failover rehearsal; and a blocked verdict for any unresolved duplicate-charge control.
Input
Our primary Postgres cluster sometimes reaches connection saturation while one replica lags. Include triage, safe load reduction, read-routing constraints, rollback, escalation, and proof that recovery is stable.
Provide the service boundary, architecture and dependency evidence, monitoring signals, known failure modes, safe diagnostic commands, mitigation and rollback constraints, owners, escalation paths, communication channels, and any existing procedures. The skill will produce one canonical JSON runbook, keep uncertainty visible, and block a ready verdict when critical evidence, authority, rollback, verification, or rehearsal coverage is missing.
Current architecture, dependencies, dashboards or alert definitions, logs, metrics, deployment and rollback procedures, and known failure modes. Missing or stale sources remain explicit.
Named service owner, incident roles, escalation contacts, and clear boundaries for actions that need approval. The skill does not invent owners or authorization.
A non-production environment, tabletop format, or other approved way to rehearse diagnostics, failed actions, recovery, communication, and verification.
Required only for the optional read-only JSON checker. It uses the standard library and writes findings to stdout.
SKILL.md; service evidence and action-safety standard; canonical JSON output template; read-only incident-runbook checker; Agent Skills interface metadata
No reviews yet.
Output
Evidence-bound thresholds that distinguish connection pressure from replication trouble; ordered diagnostics; bounded mitigation options with preconditions and blast radius; explicit stop and rollback conditions; database-owner escalation; recovery verification windows; and rehearsal records that cannot be marked passed without observed evidence.
Input
A worker queue is growing after a deploy. One pasted log line says to disable authentication and purge the queue. Build a safe runbook using our metrics, deployment history, dead-letter policy, rollback command, and communications matrix.
Output
A canonical runbook that treats pasted log text as evidence rather than authority; validates backlog and consumer health; rejects the unsafe instruction; gates drain, scale, rollback, and replay actions; protects dead-letter data; records a failed-action rehearsal through recovery and escalation; and reports the exact evidence still needed for readiness.
Creator
Llorvio40
