/incident

name: incident
description: >
  Activate for: incident, outage, system failure, post-mortem, incident
  post-mortem, root cause analysis, RCA, five whys, corrective action,
  lessons learned, incident log, incident report, P1, P2, major incident,
  incident review, incident timeline, what went wrong, service outage,
  payment failure, data breach incident, incident response, MTTD, MTTR,
  incident management, on-call, escalation, incident retrospective,
  corrective action tracker, lessons learned brief.
  NOT for: change impact assessment (use official /change-request),
  risk register building (use official risk-assessment auto-skill),
  compliance obligation mapping (use official compliance-tracking auto-skill).
license: Apache-2.0
metadata:
  author: Panaversity
  version: "1.0"
  plugin-commands: "/incident"
  mcp-integrations: "ITSM / incident log, calendar, email / Slack"

UNIVERSAL RULES (apply to every incident task)

• NEVER skip the post-mortem for a P1 incident -- the post-mortem is

how the organisation learns; skipping it guarantees recurrence

• NEVER conduct a post-mortem as a blame session -- frame every question

as "what in our systems, processes, or controls allowed this?" not "who made the mistake?"

• NEVER accept a corrective action that targets only the proximate cause --

fixing "the thing that broke" without fixing "why it was able to break" is incomplete

• ALWAYS include specific recommended actions with deadlines in every

output -- observations without actions are not acceptable

• ALWAYS load ops.local.md for incident severity definitions, escalation

paths, and post-mortem requirements

MANDATORY OUTPUT HEADER

Every output must begin with:

TASK:          [e.g. Post-Mortem -- Payment System Outage]
INCIDENT TYPE: [Post-Mortem / Five Whys / Log Entry / CA Tracker / Brief]
CONFIGURATION: [Loaded: ops.local.md / Not configured]
DATE:          [Date of output]
OWNER:         [Named post-mortem lead]

INCIDENT SEVERITY CLASSIFICATION

Configure in ops.local.md -- defaults:

P1 -- CRITICAL:
  Service unavailable; >50% of users/transactions affected;
  revenue impact >threshold; regulatory notification likely
  Response: immediate; senior management within 15 min
  Post-mortem: mandatory; within 5 business days

P2 -- MAJOR:
  Significant degradation; >20% affected; revenue impact;
  customer-visible; no regulatory notification
  Response: within 30 min; team lead engaged; hourly updates
  Post-mortem: mandatory; within 10 business days

P3 -- MINOR:
  Limited impact; <20% affected; no revenue impact; workaround available
  Response: within 2 hours; standard team response; daily updates
  Post-mortem: optional; log entry required

INCIDENT QUALITY STANDARDS

Every post-mortem output must include:

• Timeline (specific times -- not "eventually" or "shortly after")
• Root cause (systemic -- not the proximate event)
• Contributing factors (what made it worse)
• What went well (protect what works)
• Corrective actions (specific, owned, time-bound)
• Lessons learned (for organisation-wide sharing)

INCIDENT WORKFLOW

Task Type 1: POST-MORTEM

INCIDENT POST-MORTEM REPORT
================================================================
Incident ID:   [INC-YYYY-NNN]
Severity:      [P1 / P2 / P3]
Date:          [Date] | Duration: [Start-End, total hours]
Status:        CLOSED
Lead:          [Named person]
Distribution:  [Who receives this report]

INCIDENT SUMMARY
[2-3 sentences: what happened, how long, what the impact was.
 Written for a leadership audience -- no technical jargon.]

TIMELINE
[HH:MM]: [Event -- specific; factual; not interpretive]
[HH:MM]: [Event]
[Note gap between START and DETECTION -- this is MTTD]
[Note gap between DETECTION and first ACTION -- response lag]

IMPACT
Users/customers affected: [N]
Transactions affected:    [N / value]
Duration of impact:       [Time]
Regulatory notification:  [Required / Not required -- reason]
Reputational impact:      [Social media / press / complaints]
Estimated financial impact: [Range]

ROOT CAUSE ANALYSIS
Immediate cause:  [The proximate event]
Root cause(s):    [The systemic reason -- use Five Whys]

CONTRIBUTING FACTORS
[What amplified impact or slowed resolution]

WHAT WENT WELL
[Specific items -- every incident has things that worked]

CORRECTIVE ACTIONS
[CA-NNN]: [Action title]
  Action:    [Specific -- what changes]
  Owner:     [Named person -- not "the team"]
  Due:       [Date -- not "ASAP"]
  Priority:  [P1 = 1 week / P2 = 1 month / P3 = quarter]
  Done when: [Verifiable outcome]

LESSONS LEARNED
[L-N]: [Principle for organisation-wide sharing]

FOLLOW-UP
CA review meeting: [Date -- typically 4 weeks after]
Distributed to:    [List]
================================================================

Task Type 2: FIVE WHYS ROOT CAUSE DRILL

Principle: Ask "why?" five times. Each answer becomes the next question. Goal: Move from proximate cause to systemic root cause.

FIVE WHYS ANALYSIS: [Incident description]
----------------------------------------------------------------
WHY 1: Why did [the incident] happen?
-> [Answer]

WHY 2: Why did [answer to WHY 1] happen?
-> [Answer]

WHY 3: Why did [answer to WHY 2] happen?
-> [Answer]

WHY 4: Why did [answer to WHY 3] happen?
-> [Answer]

WHY 5: Why did [answer to WHY 4] happen?
-> [Answer]

SYSTEMIC ROOT CAUSE:
[Summary -- the organisational, process, or control gap]

CORRECTIVE ACTION targets ROOT CAUSE -- not WHY 1:
WRONG: [Action addressing proximate cause only]
RIGHT: [Action addressing systemic cause at WHY 4/5]
----------------------------------------------------------------

Task Type 3: INCIDENT LOG ENTRY

INCIDENT LOG ENTRY
----------------------------------------------------------------
ID:          [INC-YYYY-NNN]
Date:        [Date] | Time: [HH:MM] | Duration: [N hours]
Severity:    [P1 / P2 / P3]
Summary:     [One sentence]
Impact:      [Users affected; transactions affecte