resonance-ops-incident

Coordinates live production incident response from severity declaration through verified recovery and blameless postmortem.

Updated Dec 1, 2025
One-click install
npx skills add https://github.com/manusco/wolfgang --skill resonance-ops-incident-manusco
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: resonance-ops-incident
Source: https://github.com/manusco/wolfgang/tree/main/.agents/skills/ops/incident
Command: npx skills add https://github.com/manusco/wolfgang --skill resonance-ops-incident-manusco

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When production is down, teams often waste critical minutes hunting root causes, arguing over severity, or stacking speculative fixes. This Skill enforces a disciplined incident command procedure: mitigate first with reversible actions, assign a single Incident Commander, communicate on a fixed cadence, and verify recovery against real signals before declaring resolved. ## Core Features & Use Cases - Severity Declaration: Maps impact to SEV1-SEV4 using a severity matrix, with a round-up rule when impact is ambiguous. - Mitigation-First Algorithm: Prioritizes reversible levers (rollback, feature flag, failover) over live root-cause analysis, one change at a time. - Communication Cadence: Separates internal responder channels from external status pages with committed update intervals per severity. - Blameless Postmortem: Drafts timelines, 5-whys on contributing factors, and owned action items without blaming individuals. - Use Case: Paged at 2 AM because checkout is throwing 500s after a deploy. The Skill walks you through confirming impact, declaring SEV1, naming an IC, rolling back the deploy, posting stakeholder updates, and verifying recovery before writing the postmortem. ## Quick Start Run the incident procedure for the current production outage where checkout is returning 500 errors after the latest deploy.

Frequently Asked Questions about resonance-ops-incident

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I respond to a production outage step by step?▼

Confirm the impact with a real signal, declare a SEV1-SEV4 severity, assign one Incident Commander, then mitigate with the fastest reversible action such as a rollback or feature flag. Communicate on a fixed cadence and verify recovery against the health signal before declaring resolved.

How do I decide between SEV1 and SEV2 severity?▼

Assess how much of the product is unusable, whether money, data, or safety is at risk, and whether impact is growing. When genuinely ambiguous, declare the higher severity and downgrade later, since under-declaring costs far more than over-declaring.

Should I find the root cause before rolling back a bad deploy?▼

No. Mitigate first with the fastest reversible action while users are affected, then move root-cause investigation to a separate debugging session after the system is stable. Diagnosing live while users are down is the classic incident response failure.

What makes a postmortem blameless?▼

A blameless postmortem names roles and actions rather than individuals as culprits, runs 5-whys past human error to structural gaps, and assigns every action item a named owner and due date. It assumes people acted reasonably with the information they had.

When should I not declare an incident?▼

Do not declare a SEV when the signal is unconfirmed, such as a single flaky alert without corroborating evidence, or when degradation affects only non-production systems with no user impact. Confirm impact first, since a rollback fired at a phantom is its own incident.