rune-incident

Triage, contain, and document production incidents with structured postmortem reports.

1|Updated Mar 22, 2026
One-click install
npx skills add https://github.com/dangvu008/VietTruyen --skill rune-incident-dangvu008
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rune-incident
Source: https://github.com/dangvu008/VietTruyen/tree/main/.agents/skills/rune-incident
Command: npx skills add https://github.com/dangvu008/VietTruyen --skill rune-incident-dangvu008

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Production outages often trigger chaotic debugging while the system is still down, turning minor incidents into major ones. This Skill enforces a strict incident response order — triage severity first, contain the blast radius before investigating, root-cause only after the system is stable, and document everything in a postmortem. ## Core Features & Use Cases - Severity Triage: Classifies incidents as P1 (full outage), P2 (partial degradation), or P3 (minor issue) with defined containment time targets for each level. - Containment-First Workflow: Blocks root-cause analysis and code changes until containment is verified via health checks, supporting strategies like rollback, feature flags, traffic shifting, and rate limiting. - Postmortem Generation: Produces a complete incident report with timeline, root cause, contributing factors, and a prevention actions table saved to .rune/incidents/. - Use Case: Your login service starts returning 503 errors after a deploy. Invoke the skill to classify it as P2, roll back to the previous commit, verify recovery via watchdog, run a security check, and generate a postmortem identifying the connection pool exhaustion root cause. ## Quick Start Respond to the production outage where users report login failures by triaging severity, containing the issue, and generating a postmortem report.

Frequently Asked Questions about rune-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?

Triage severity first using the P1/P2/P3 matrix, then contain the blast radius with rollback, feature flags, or traffic shifting before any investigation. Only after health checks confirm stability should you run root cause analysis and write the postmortem.

How to classify incident severity as P1, P2, or P3?

P1 is a full outage affecting all users, such as 5xx on the root path or broken auth, requiring containment within 15 minutes. P2 is partial degradation like elevated error rates or regional failures with a 1-hour target. P3 covers minor cosmetic or edge-case issues with a 4-hour target.

What should a postmortem report include?

A postmortem includes severity, duration, user impact, a timestamped timeline from detection to resolution, the specific root cause, contributing factors, what went well and wrong, and a prevention actions table where every action has an owner and due date.

Can I fix code during an active incident response?

No. The skill explicitly forbids code changes during incident response — it only investigates and contains. Shipping fixes during an active P1/P2 without containment risks turning smaller incidents into larger ones, so fixes are handled as a separate task.

Why check for security issues during a performance incident?

Security dimensions are not always obvious — an incident that looks like a performance issue may involve data exposure, unauthorized access patterns, or injection attacks. The skill mandates a security check before closing every incident, escalating to a security protocol if a block is detected.