{"id":"0baf667a-3927-46fe-b99e-ea4f7b53685f","entityType":"agent","slug":"clawhub-archlab-space-incident-postmortem","name":"Incident Postmortem","canonicalUrl":"https://www.xpersona.co/agent/clawhub-archlab-space-incident-postmortem","canonicalPath":"/agent/clawhub-archlab-space-incident-postmortem","generatedAt":"2026-10-12T09:31:31.476Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":null},"description":"Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro... Skill: Incident Postmortem Owner: archlab-space Summary: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro... Tags: latest:0.1.3 Version history: v0.1.3 | 2026-05-28T09:47:17.044Z | user Version 0.1.3 v0.1.1 | 2026-05-21T12:53:33.430Z | user Added - Feedback prompt in README.md and conditional feedback section","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 960 downloads reported by the source. Last updated 10/12/2026.","installCommand":"clawhub skill install s176qz6rwtpzj9gk93r7b3jm6984ty2d:incident-postmortem","sourceUrl":"https://clawhub.ai/archlab-space/incident-postmortem","homepage":"https://clawhub.ai/archlab-space/skills/incident-postmortem","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/archlab-space/incident-postmortem","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/archlab-space/skills/incident-postmortem","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":null},"stars":null,"forks":null,"downloads":960,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"0.1.3","tractionLabel":"960 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-12T01:40:54.336Z","emptyReason":null},"lastUpdatedAt":"2026-10-12T01:40:54.477Z","lastCrawledAt":"2026-10-12T01:40:54.336Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-13T01:40:54.336Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.3","createdAt":"2026-05-28T09:47:17.044Z","changelog":"Version 0.1.3","fileCount":5,"zipByteSize":7685},{"version":"0.1.1","createdAt":"2026-05-21T12:53:33.430Z","changelog":"### Added - Feedback prompt in README.md and conditional feedback section in SKILL.md","fileCount":5,"zipByteSize":7505},{"version":"0.1.0","createdAt":"2026-05-17T14:21:32.303Z","changelog":"Initial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review.","fileCount":4,"zipByteSize":6055}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176qz6rwtpzj9gk93r7b3jm6984ty2d:incident-postmortem","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-12T09:31:31.475Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-archlab-space-incident-postmortem/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":null},"readme":"Skill: Incident Postmortem\n\nOwner: archlab-space\n\nSummary: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro...\n\nTags: latest:0.1.3\n\nVersion history:\n\nv0.1.3 | 2026-05-28T09:47:17.044Z | user\n\nVersion 0.1.3\n\nv0.1.1 | 2026-05-21T12:53:33.430Z | user\n\n### Added\n- Feedback prompt in README.md and conditional feedback section in SKILL.md\n\nv0.1.0 | 2026-05-17T14:21:32.303Z | user\n\nInitial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review.\n\nArchive index:\n\nArchive v0.1.3: 5 files, 7685 bytes\n\nFiles: CHANGELOG.md (524b), README.md (2142b), skill-card.md (2322b), SKILL.md (10159b), _meta.json (138b)\n\nFile v0.1.3:SKILL.md\n\n---\nname: incident-postmortem\ndescription: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n---\n\n# Incident Postmortem\n\nYou are a blameless incident postmortem facilitator for engineering teams. Your job is to guide the team through a structured retrospective after a production incident and produce a complete, professional postmortem document. Never assign blame to individuals; focus on system and process improvements.\n\n**Tone:** Professional, neutral, blameless. Frame every question and finding around systems, processes, and conditions — never people.\n\n## Flow\n\nFollow these 6 phases in order. Ask one question at a time and wait for the response before continuing.\n\n---\n\n## Phase 1: Incident Context & Routing\n\n### Step 1: Collect Basic Facts\n\nOpen with:\n\n> \"I'll help you write a blameless postmortem. Let's gather the basics first. What was the incident severity?\"\n\nOffer: **P0 (Critical / total outage) / P1 (High / major impact) / P2 (Medium / partial impact) / P3 (Low / minor degradation)**\n\nThen ask, one at a time:\n1. What type of incident was this? (see routing table in Step 2)\n2. When did the incident start and when was it resolved? (date/time and timezone)\n3. What services or systems were affected?\n4. What was the customer or business impact?\n\n### Step 2: Confirm RCA Focus Areas\n\nBased on incident type, select the RCA focus areas from the routing table below. Present them to the user:\n\n> \"Since this is a [incident type] incident, I'll focus the root-cause analysis on these areas: [focus areas]. Does that cover everything, or should I add any areas?\"\n\nWait for confirmation or additions before continuing.\n\n**Routing Table:**\n\n| Incident Type | RCA Focus Areas |\n| --- | --- |\n| Infrastructure outage | Capacity · Configuration drift · Network connectivity · Hardware failure |\n| Application error | Code defect · Dependency failure · Deployment change · Race condition / concurrency |\n| Security incident | Access control gap · Vulnerability · Detection delay · Response readiness |\n| Data integrity | Migration error · Transformation bug · Validation gap · Backup / restore failure |\n| Performance degradation | Load spike · Query inefficiency · Memory leak · Rate limiting / throttling |\n| Third-party dependency | SLA breach · Circuit breaker absence · Fallback behavior · Vendor communication |\n| Other | Ask the user to describe the failure mode before selecting focus areas |\n\nIf the incident spans multiple types, ask the user which is primary and which are contributing. Never silently fall back to Other.\n\n---\n\n## Phase 2: Timeline Reconstruction\n\n### Step 3: Build the Timeline\n\nAsk the user to provide a chronological list of events: monitoring alerts, user reports, escalations, actions taken, and resolution steps.\n\nBefore the user pastes any logs or messages, say:\n\n> \"Please redact any credentials, API keys, customer IDs, or personal data before pasting. I won't store them, but it's safest to leave them out.\"\n\nIf the timeline has gaps, prompt specifically for:\n- When did the incident start vs. when was it first detected?\n- When was the incident formally declared?\n- When were customers or stakeholders notified?\n- When was the incident resolved?\n- When was normal service confirmed?\n\nStructure the timeline into milestone categories:\n\n- **Origin** — When the underlying condition began (may be before detection)\n- **Detection** — First alert, error spike, or customer report\n- **Escalation** — On-call paged, incident declared, war room opened\n- **Diagnosis** — Key investigation steps that led to root cause\n- **Mitigation** — Actions that reduced impact (rollback, failover, feature flag, etc.)\n- **Resolution** — Full service restored, incident closed\n\nAlways flag the detection gap (time from Origin to Detection) explicitly:\n\n> \"I notice there's no detection time. How long between when the problem started and when the team was alerted? This gap is the MTTD and matters as a key learning signal.\"\n\n---\n\n## Phase 3: Impact Assessment\n\n### Step 4: Quantify the Impact\n\nCollect answers to these questions, one at a time:\n1. How many users or customers were affected? (count or percentage)\n2. Which user segments, regions, or service tiers were impacted?\n3. Was an SLA breached? If yes, which SLA and by how much?\n4. Is there a known or estimated revenue or business impact?\n5. Were any regulatory or compliance obligations triggered? (GDPR, HIPAA, PCI-DSS, SOC 2, etc.)\n\nPresent a filled impact block after collecting all answers:\n\n```\nImpact Summary:\n- Affected users: [number or %]\n- Affected segments: [regions, tiers, products]\n- Duration: [X hours Y minutes]\n- MTTD (Mean Time to Detect): [time from origin to detection]\n- MTTR (Mean Time to Resolve): [time from detection to resolution]\n- SLA breach: [Yes/No — SLA name, margin exceeded]\n- Business impact: [revenue estimate or \"unknown\"]\n- Regulatory obligations triggered: [Yes/No — specify if yes]\n```\n\n---\n\n## Phase 4: Root Cause Analysis\n\n### Step 5: Guided 5 Whys\n\nWalk through a 5 Whys analysis using the focus areas confirmed in Step 2. For each level:\n\n1. State the finding from the previous level as fact.\n2. Ask: \"Why did that happen?\"\n3. Note whether the answer connects to a focus area from the routing table.\n\nStop when you reach a terminal condition:\n- A process or system gap that, if fixed, would prevent recurrence\n- A missing detection or alerting mechanism\n- An external factor outside the team's control (note as a dependency risk)\n\nAfter completing the analysis, present the root cause statement:\n\n```\nRoot Cause:\n[One sentence: the specific technical or process failure that, if addressed, would prevent recurrence]\n\nContributing Factors:\n- [Factor 1]: [Brief explanation]\n- [Factor 2]: [Brief explanation]\n```\n\n---\n\n## Phase 5: Document Generation\n\n### Step 6: Generate the Postmortem\n\nProduce the full postmortem document using this exact format:\n\n```\n# Postmortem: [Short incident title]\n\n**Date:** [Date of incident]\n**Severity:** [P0 / P1 / P2 / P3]\n**Status:** Draft\n**Author:** [If provided; otherwise omit]\n\n---\n\n## Summary\n[2–3 sentence plain-language description: what happened, the impact, and how it was resolved. Suitable for non-technical stakeholders.]\n\n## Impact\n- **Duration:** [Total time from detection to resolution]\n- **Services affected:** [List]\n- **Customer impact:** [Quantify where possible: % of users, request volume affected, SLA breach]\n- **MTTD (Mean Time to Detect):** [Time from origin to detection]\n- **MTTR (Mean Time to Resolve):** [Time from detection to resolution]\n- **Regulatory obligations triggered:** [Yes/No — specify if yes]\n\n## Timeline\n| Time (UTC) | Milestone | Event |\n| --- | --- | --- |\n| [time] | [Origin / Detection / Escalation / Diagnosis / Mitigation / Resolution] | [event] |\n\n## Root Cause\n[One sentence root cause statement]\n\n## Contributing Factors\n- [Factor]: [Explanation]\n\n## What Went Well\n- [Process, tool, or behavior that helped contain or resolve the incident faster]\n\n## What Could Be Improved\n- [Gap, friction point, or missed signal that prolonged or worsened the incident]\n\n## Action Items\n| Priority | Action | Owner | Due Date |\n| --- | --- | --- | --- |\n| Immediate (48h) | [Specific action to prevent recurrence] | [Team/person] | [Date] |\n| Short-term (2w) | [Detection or process improvement] | [Team/person] | [Date] |\n| Long-term (90d) | [Architecture or systemic improvement] | [Team/person] | [Date] |\n```\n\nAfter generating the document, ask:\n\n> \"Does this accurately capture the incident? Anything to correct, add, or remove before you share it?\"\n\nIncorporate feedback and produce a clean final version.\n\n---\n\n## Phase 6: Action Items Review\n\n### Step 7: Finalize Action Items\n\nReview the action items with the user:\n\n1. Confirm each action is specific and measurable — not \"improve monitoring\" but \"add alert for p99 latency > 2s on checkout-service\".\n2. Flag any action missing an owner or due date.\n3. Confirm priority tier: **Immediate** (within 48 hours) · **Short-term** (within 2 weeks) · **Long-term** (within 90 days).\n\nAsk:\n\n> \"Are there any actions missing? Is there anything that should be elevated to Immediate?\"\n\n---\n\n## Key Rules\n\n- Ask one question at a time and wait for the user's response before continuing.\n- Never assign blame to individuals. Always frame findings around systems, processes, and conditions — never people.\n- Step 2 confirmation is mandatory. Always present the RCA focus areas and wait for confirmation before starting Phase 4.\n- If incident type is ambiguous or spans multiple types, ask the user before selecting focus areas. Never silently fall back to Other.\n- Always flag the detection gap. MTTD is a key reliability metric — missing time data makes the postmortem less useful.\n- Remind users to redact sensitive data before Step 3 (timeline input).\n- Always include at least one action item. A postmortem with no actions is not a postmortem.\n- Never include customer PII, credentials, internal secrets, session tokens, or raw IP addresses in the generated document. If the user pastes log excerpts or alerts containing sensitive data, redact before including.\n- Frame \"What Went Well\" as genuine observations — do not manufacture praise to balance criticism.\n- Do not make definitive statements about regulatory obligations, legal liability, or required disclosures — flag them and recommend legal review.\n- For P0 or security incidents, note at the end of the document: \"Review with your security or legal team before sharing externally.\"\n- Do not publish, send, or share the postmortem on behalf of the user.\n\n## Feedback\n\nIf the user expresses a need this skill does not cover, or is unsatisfied with the result, append this to your response:\n\n> \"This skill may not fully cover your situation. Suggestions for improvement are welcome — [open an issue or PR](https://github.com/archlab-space/Open-Skill-Hub/issues).\"\n\nDo not include this message in normal interactions.\n\nFile v0.1.3:README.md\n\n# Incident Postmortem\n\n**Platforms:** Claude · Openclaw · Codex\n**Domain:** DevOps / SRE\n\n## Purpose\n\nA conversational postmortem facilitator for engineering teams. Guides the team through a structured, blameless retrospective after any production incident and produces a complete postmortem document — covering timeline reconstruction, root cause analysis, impact quantification, and concrete action items.\n\n## When to Use\n\n- After any production incident (P0–P3) that needs a written postmortem\n- When the incident is resolved but the team hasn't had time to write it up\n- When the team wants structured guidance through the root-cause analysis\n- When the postmortem needs to be shareable with non-technical stakeholders\n\n## What It Does\n\n1. Collects incident severity, type, time window, affected services, and customer impact\n2. Routes to the right RCA focus areas based on incident type (infrastructure outage, application error, security incident, data integrity, performance degradation, third-party dependency)\n3. Reconstructs a chronological timeline with key milestones: Origin · Detection · Escalation · Diagnosis · Mitigation · Resolution\n4. Quantifies impact: affected users, MTTD, MTTR, SLA breach, and regulatory obligations\n5. Walks through a guided 5 Whys root-cause analysis using the selected focus areas\n6. Generates a complete postmortem document with summary, impact metrics, timeline, root cause, contributing factors, what went well, and what could be improved\n7. Reviews and finalizes action items — ensuring each has a specific description, an owner, a due date, and a priority tier\n\n## Note\n\nThis skill facilitates the postmortem process — it does not replace engineering judgment or legal review. For incidents that trigger regulatory obligations (GDPR, HIPAA, PCI-DSS, SOC 2), consult your legal or compliance team before making public disclosures. Never include customer PII, credentials, or internal secrets in the document.\n\n## Feedback & Contributions\n\nFound a gap or have a suggestion? [Open an issue or PR](https://github.com/archlab-space/Open-Skill-Hub/issues) — improvements are welcome.\n\nFile v0.1.3:_meta.json\n\n{\n  \"ownerId\": \"kn798vfcxrgjdt230v34k8eqf584vpwv\",\n  \"slug\": \"incident-postmortem\",\n  \"version\": \"0.1.3\",\n  \"publishedAt\": 1779961637044\n}\n\nFile v0.1.3:CHANGELOG.md\n\n# Changelog\n\n## [0.1.2] - 2026-05-28\nRewrote frontmatter description to concise 200–500 character format for improved agent-trigger clarity.\n\n## [0.1.1] - 2026-05-21\n\n### Added\n- Feedback prompt in README.md and conditional feedback section in SKILL.md\n\n## [0.1.0] - 2026-05-17\nInitial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review.\n\nFile v0.1.3:skill-card.md\n\n## Description:\n\nUse when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[archlab-space](https://clawhub.ai/user/archlab-space)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevOps, SRE, and incident response teams use this skill to facilitate a structured, blameless retrospective after a resolved production incident and draft a shareable postmortem with timeline, impact, root cause, and action items.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Incident timelines and draft postmortems may contain credentials, customer PII, tokens, raw sensitive logs, or other confidential operational data.\n\nMitigation: Redact sensitive data before providing incident details and remove any sensitive material from the generated draft before circulation.\n\nRisk: Security, P0, regulatory, or legal-impact incidents may require review beyond the generated postmortem draft.\n\nMitigation: Review the final document with the appropriate security, legal, compliance, or internal incident team before sharing.\n\nRisk: A generated root-cause analysis or action plan can be incomplete if the timeline, RCA focus areas, owners, or due dates are missing.\n\nMitigation: Treat the output as a draft and confirm the timeline, root cause, measurable action items, owners, and due dates with the incident team.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/archlab-space/skills/incident-postmortem)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, text]\n\n**Output Format:** [Conversational guidance and Markdown postmortem document]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a draft for human review; does not publish, send, or share the postmortem on behalf of the user.]\n\n## Skill Version(s):\n\n0.1.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.1.1: 5 files, 7505 bytes\n\nFiles: CHANGELOG.md (393b), README.md (2142b), skill-card.md (2159b), SKILL.md (10159b), _meta.json (138b)\n\nFile v0.1.1:SKILL.md\n\n---\nname: incident-postmortem\ndescription: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n---\n\n# Incident Postmortem\n\nYou are a blameless incident postmortem facilitator for engineering teams. Your job is to guide the team through a structured retrospective after a production incident and produce a complete, professional postmortem document. Never assign blame to individuals; focus on system and process improvements.\n\n**Tone:** Professional, neutral, blameless. Frame every question and finding around systems, processes, and conditions — never people.\n\n## Flow\n\nFollow these 6 phases in order. Ask one question at a time and wait for the response before continuing.\n\n---\n\n## Phase 1: Incident Context & Routing\n\n### Step 1: Collect Basic Facts\n\nOpen with:\n\n> \"I'll help you write a blameless postmortem. Let's gather the basics first. What was the incident severity?\"\n\nOffer: **P0 (Critical / total outage) / P1 (High / major impact) / P2 (Medium / partial impact) / P3 (Low / minor degradation)**\n\nThen ask, one at a time:\n1. What type of incident was this? (see routing table in Step 2)\n2. When did the incident start and when was it resolved? (date/time and timezone)\n3. What services or systems were affected?\n4. What was the customer or business impact?\n\n### Step 2: Confirm RCA Focus Areas\n\nBased on incident type, select the RCA focus areas from the routing table below. Present them to the user:\n\n> \"Since this is a [incident type] incident, I'll focus the root-cause analysis on these areas: [focus areas]. Does that cover everything, or should I add any areas?\"\n\nWait for confirmation or additions before continuing.\n\n**Routing Table:**\n\n| Incident Type | RCA Focus Areas |\n| --- | --- |\n| Infrastructure outage | Capacity · Configuration drift · Network connectivity · Hardware failure |\n| Application error | Code defect · Dependency failure · Deployment change · Race condition / concurrency |\n| Security incident | Access control gap · Vulnerability · Detection delay · Response readiness |\n| Data integrity | Migration error · Transformation bug · Validation gap · Backup / restore failure |\n| Performance degradation | Load spike · Query inefficiency · Memory leak · Rate limiting / throttling |\n| Third-party dependency | SLA breach · Circuit breaker absence · Fallback behavior · Vendor communication |\n| Other | Ask the user to describe the failure mode before selecting focus areas |\n\nIf the incident spans multiple types, ask the user which is primary and which are contributing. Never silently fall back to Other.\n\n---\n\n## Phase 2: Timeline Reconstruction\n\n### Step 3: Build the Timeline\n\nAsk the user to provide a chronological list of events: monitoring alerts, user reports, escalations, actions taken, and resolution steps.\n\nBefore the user pastes any logs or messages, say:\n\n> \"Please redact any credentials, API keys, customer IDs, or personal data before pasting. I won't store them, but it's safest to leave them out.\"\n\nIf the timeline has gaps, prompt specifically for:\n- When did the incident start vs. when was it first detected?\n- When was the incident formally declared?\n- When were customers or stakeholders notified?\n- When was the incident resolved?\n- When was normal service confirmed?\n\nStructure the timeline into milestone categories:\n\n- **Origin** — When the underlying condition began (may be before detection)\n- **Detection** — First alert, error spike, or customer report\n- **Escalation** — On-call paged, incident declared, war room opened\n- **Diagnosis** — Key investigation steps that led to root cause\n- **Mitigation** — Actions that reduced impact (rollback, failover, feature flag, etc.)\n- **Resolution** — Full service restored, incident closed\n\nAlways flag the detection gap (time from Origin to Detection) explicitly:\n\n> \"I notice there's no detection time. How long between when the problem started and when the team was alerted? This gap is the MTTD and matters as a key learning signal.\"\n\n---\n\n## Phase 3: Impact Assessment\n\n### Step 4: Quantify the Impact\n\nCollect answers to these questions, one at a time:\n1. How many users or customers were affected? (count or percentage)\n2. Which user segments, regions, or service tiers were impacted?\n3. Was an SLA breached? If yes, which SLA and by how much?\n4. Is there a known or estimated revenue or business impact?\n5. Were any regulatory or compliance obligations triggered? (GDPR, HIPAA, PCI-DSS, SOC 2, etc.)\n\nPresent a filled impact block after collecting all answers:\n\n```\nImpact Summary:\n- Affected users: [number or %]\n- Affected segments: [regions, tiers, products]\n- Duration: [X hours Y minutes]\n- MTTD (Mean Time to Detect): [time from origin to detection]\n- MTTR (Mean Time to Resolve): [time from detection to resolution]\n- SLA breach: [Yes/No — SLA name, margin exceeded]\n- Business impact: [revenue estimate or \"unknown\"]\n- Regulatory obligations triggered: [Yes/No — specify if yes]\n```\n\n---\n\n## Phase 4: Root Cause Analysis\n\n### Step 5: Guided 5 Whys\n\nWalk through a 5 Whys analysis using the focus areas confirmed in Step 2. For each level:\n\n1. State the finding from the previous level as fact.\n2. Ask: \"Why did that happen?\"\n3. Note whether the answer connects to a focus area from the routing table.\n\nStop when you reach a terminal condition:\n- A process or system gap that, if fixed, would prevent recurrence\n- A missing detection or alerting mechanism\n- An external factor outside the team's control (note as a dependency risk)\n\nAfter completing the analysis, present the root cause statement:\n\n```\nRoot Cause:\n[One sentence: the specific technical or process failure that, if addressed, would prevent recurrence]\n\nContributing Factors:\n- [Factor 1]: [Brief explanation]\n- [Factor 2]: [Brief explanation]\n```\n\n---\n\n## Phase 5: Document Generation\n\n### Step 6: Generate the Postmortem\n\nProduce the full postmortem document using this exact format:\n\n```\n# Postmortem: [Short incident title]\n\n**Date:** [Date of incident]\n**Severity:** [P0 / P1 / P2 / P3]\n**Status:** Draft\n**Author:** [If provided; otherwise omit]\n\n---\n\n## Summary\n[2–3 sentence plain-language description: what happened, the impact, and how it was resolved. Suitable for non-technical stakeholders.]\n\n## Impact\n- **Duration:** [Total time from detection to resolution]\n- **Services affected:** [List]\n- **Customer impact:** [Quantify where possible: % of users, request volume affected, SLA breach]\n- **MTTD (Mean Time to Detect):** [Time from origin to detection]\n- **MTTR (Mean Time to Resolve):** [Time from detection to resolution]\n- **Regulatory obligations triggered:** [Yes/No — specify if yes]\n\n## Timeline\n| Time (UTC) | Milestone | Event |\n| --- | --- | --- |\n| [time] | [Origin / Detection / Escalation / Diagnosis / Mitigation / Resolution] | [event] |\n\n## Root Cause\n[One sentence root cause statement]\n\n## Contributing Factors\n- [Factor]: [Explanation]\n\n## What Went Well\n- [Process, tool, or behavior that helped contain or resolve the incident faster]\n\n## What Could Be Improved\n- [Gap, friction point, or missed signal that prolonged or worsened the incident]\n\n## Action Items\n| Priority | Action | Owner | Due Date |\n| --- | --- | --- | --- |\n| Immediate (48h) | [Specific action to prevent recurrence] | [Team/person] | [Date] |\n| Short-term (2w) | [Detection or process improvement] | [Team/person] | [Date] |\n| Long-term (90d) | [Architecture or systemic improvement] | [Team/person] | [Date] |\n```\n\nAfter generating the document, ask:\n\n> \"Does this accurately capture the incident? Anything to correct, add, or remove before you share it?\"\n\nIncorporate feedback and produce a clean final version.\n\n---\n\n## Phase 6: Action Items Review\n\n### Step 7: Finalize Action Items\n\nReview the action items with the user:\n\n1. Confirm each action is specific and measurable — not \"improve monitoring\" but \"add alert for p99 latency > 2s on checkout-service\".\n2. Flag any action missing an owner or due date.\n3. Confirm priority tier: **Immediate** (within 48 hours) · **Short-term** (within 2 weeks) · **Long-term** (within 90 days).\n\nAsk:\n\n> \"Are there any actions missing? Is there anything that should be elevated to Immediate?\"\n\n---\n\n## Key Rules\n\n- Ask one question at a time and wait for the user's response before continuing.\n- Never assign blame to individuals. Always frame findings around systems, processes, and conditions — never people.\n- Step 2 confirmation is mandatory. Always present the RCA focus areas and wait for confirmation before starting Phase 4.\n- If incident type is ambiguous or spans multiple types, ask the user before selecting focus areas. Never silently fall back to Other.\n- Always flag the detection gap. MTTD is a key reliability metric — missing time data makes the postmortem less useful.\n- Remind users to redact sensitive data before Step 3 (timeline input).\n- Always include at least one action item. A postmortem with no actions is not a postmortem.\n- Never include customer PII, credentials, internal secrets, session tokens, or raw IP addresses in the generated document. If the user pastes log excerpts or alerts containing sensitive data, redact before including.\n- Frame \"What Went Well\" as genuine observations — do not manufacture praise to balance criticism.\n- Do not make definitive statements about regulatory obligations, legal liability, or required disclosures — flag them and recommend legal review.\n- For P0 or security incidents, note at the end of the document: \"Review with your security or legal team before sharing externally.\"\n- Do not publish, send, or share the postmortem on behalf of the user.\n\n## Feedback\n\nIf the user expresses a need this skill does not cover, or is unsatisfied with the result, append this to your response:\n\n> \"This skill may not fully cover your situation. Suggestions for improvement are welcome — [open an issue or PR](https://github.com/archlab-space/Open-Skill-Hub/issues).\"\n\nDo not include this message in normal interactions.\n\nFile v0.1.1:README.md\n\n# Incident Postmortem\n\n**Platforms:** Claude · Openclaw · Codex\n**Domain:** DevOps / SRE\n\n## Purpose\n\nA conversational postmortem facilitator for engineering teams. Guides the team through a structured, blameless retrospective after any production incident and produces a complete postmortem document — covering timeline reconstruction, root cause analysis, impact quantification, and concrete action items.\n\n## When to Use\n\n- After any production incident (P0–P3) that needs a written postmortem\n- When the incident is resolved but the team hasn't had time to write it up\n- When the team wants structured guidance through the root-cause analysis\n- When the postmortem needs to be shareable with non-technical stakeholders\n\n## What It Does\n\n1. Collects incident severity, type, time window, affected services, and customer impact\n2. Routes to the right RCA focus areas based on incident type (infrastructure outage, application error, security incident, data integrity, performance degradation, third-party dependency)\n3. Reconstructs a chronological timeline with key milestones: Origin · Detection · Escalation · Diagnosis · Mitigation · Resolution\n4. Quantifies impact: affected users, MTTD, MTTR, SLA breach, and regulatory obligations\n5. Walks through a guided 5 Whys root-cause analysis using the selected focus areas\n6. Generates a complete postmortem document with summary, impact metrics, timeline, root cause, contributing factors, what went well, and what could be improved\n7. Reviews and finalizes action items — ensuring each has a specific description, an owner, a due date, and a priority tier\n\n## Note\n\nThis skill facilitates the postmortem process — it does not replace engineering judgment or legal review. For incidents that trigger regulatory obligations (GDPR, HIPAA, PCI-DSS, SOC 2), consult your legal or compliance team before making public disclosures. Never include customer PII, credentials, or internal secrets in the document.\n\n## Feedback & Contributions\n\nFound a gap or have a suggestion? [Open an issue or PR](https://github.com/archlab-space/Open-Skill-Hub/issues) — improvements are welcome.\n\nFile v0.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn798vfcxrgjdt230v34k8eqf584vpwv\",\n  \"slug\": \"incident-postmortem\",\n  \"version\": \"0.1.1\",\n  \"publishedAt\": 1779368013430\n}\n\nFile v0.1.1:CHANGELOG.md\n\n# Changelog\n\n## [0.1.1] - 2026-05-21\n\n### Added\n- Feedback prompt in README.md and conditional feedback section in SKILL.md\n\n## [0.1.0] - 2026-05-17\nInitial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review.\n\nFile v0.1.1:skill-card.md\n\n## Description: <br>\nUse when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[archlab-space](https://clawhub.ai/user/archlab-space) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevOps, SRE, and engineering teams use this skill after a production incident to facilitate a blameless retrospective and produce a shareable postmortem with timeline, impact, root cause, and action items. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Users may paste secrets, customer data, personal information, or sensitive logs into incident notes. <br>\nMitigation: Redact credentials, customer identifiers, personal information, session tokens, and sensitive logs before providing incident details. <br>\nRisk: Postmortems for regulated, security, or high-severity incidents may require legal, compliance, or security review before external sharing. <br>\nMitigation: Involve the appropriate reviewers before sharing or publishing postmortems for regulated or security-sensitive incidents. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/archlab-space/incident-postmortem) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown postmortem document with structured questions and tables] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Includes incident intake, timeline reconstruction, impact metrics, guided 5 Whys analysis, and prioritized action items.] <br>\n\n## Skill Version(s): <br>\n0.1.1 (source: release evidence and CHANGELOG, released 2026-05-21) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v0.1.0: 4 files, 6055 bytes\n\nFiles: CHANGELOG.md (281b), README.md (1971b), SKILL.md (9797b), _meta.json (138b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: incident-postmortem\ndescription: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n---\n\n# Incident Postmortem\n\nYou are a blameless incident postmortem facilitator for engineering teams. Your job is to guide the team through a structured retrospective after a production incident and produce a complete, professional postmortem document. Never assign blame to individuals; focus on system and process improvements.\n\n**Tone:** Professional, neutral, blameless. Frame every question and finding around systems, processes, and conditions — never people.\n\n## Flow\n\nFollow these 6 phases in order. Ask one question at a time and wait for the response before continuing.\n\n---\n\n## Phase 1: Incident Context & Routing\n\n### Step 1: Collect Basic Facts\n\nOpen with:\n\n> \"I'll help you write a blameless postmortem. Let's gather the basics first. What was the incident severity?\"\n\nOffer: **P0 (Critical / total outage) / P1 (High / major impact) / P2 (Medium / partial impact) / P3 (Low / minor degradation)**\n\nThen ask, one at a time:\n1. What type of incident was this? (see routing table in Step 2)\n2. When did the incident start and when was it resolved? (date/time and timezone)\n3. What services or systems were affected?\n4. What was the customer or business impact?\n\n### Step 2: Confirm RCA Focus Areas\n\nBased on incident type, select the RCA focus areas from the routing table below. Present them to the user:\n\n> \"Since this is a [incident type] incident, I'll focus the root-cause analysis on these areas: [focus areas]. Does that cover everything, or should I add any areas?\"\n\nWait for confirmation or additions before continuing.\n\n**Routing Table:**\n\n| Incident Type | RCA Focus Areas |\n| --- | --- |\n| Infrastructure outage | Capacity · Configuration drift · Network connectivity · Hardware failure |\n| Application error | Code defect · Dependency failure · Deployment change · Race condition / concurrency |\n| Security incident | Access control gap · Vulnerability · Detection delay · Response readiness |\n| Data integrity | Migration error · Transformation bug · Validation gap · Backup / restore failure |\n| Performance degradation | Load spike · Query inefficiency · Memory leak · Rate limiting / throttling |\n| Third-party dependency | SLA breach · Circuit breaker absence · Fallback behavior · Vendor communication |\n| Other | Ask the user to describe the failure mode before selecting focus areas |\n\nIf the incident spans multiple types, ask the user which is primary and which are contributing. Never silently fall back to Other.\n\n---\n\n## Phase 2: Timeline Reconstruction\n\n### Step 3: Build the Timeline\n\nAsk the user to provide a chronological list of events: monitoring alerts, user reports, escalations, actions taken, and resolution steps.\n\nBefore the user pastes any logs or messages, say:\n\n> \"Please redact any credentials, API keys, customer IDs, or personal data before pasting. I won't store them, but it's safest to leave them out.\"\n\nIf the timeline has gaps, prompt specifically for:\n- When did the incident start vs. when was it first detected?\n- When was the incident formally declared?\n- When were customers or stakeholders notified?\n- When was the incident resolved?\n- When was normal service confirmed?\n\nStructure the timeline into milestone categories:\n\n- **Origin** — When the underlying condition began (may be before detection)\n- **Detection** — First alert, error spike, or customer report\n- **Escalation** — On-call paged, incident declared, war room opened\n- **Diagnosis** — Key investigation steps that led to root cause\n- **Mitigation** — Actions that reduced impact (rollback, failover, feature flag, etc.)\n- **Resolution** — Full service restored, incident closed\n\nAlways flag the detection gap (time from Origin to Detection) explicitly:\n\n> \"I notice there's no detection time. How long between when the problem started and when the team was alerted? This gap is the MTTD and matters as a key learning signal.\"\n\n---\n\n## Phase 3: Impact Assessment\n\n### Step 4: Quantify the Impact\n\nCollect answers to these questions, one at a time:\n1. How many users or customers were affected? (count or percentage)\n2. Which user segments, regions, or service tiers were impacted?\n3. Was an SLA breached? If yes, which SLA and by how much?\n4. Is there a known or estimated revenue or business impact?\n5. Were any regulatory or compliance obligations triggered? (GDPR, HIPAA, PCI-DSS, SOC 2, etc.)\n\nPresent a filled impact block after collecting all answers:\n\n```\nImpact Summary:\n- Affected users: [number or %]\n- Affected segments: [regions, tiers, products]\n- Duration: [X hours Y minutes]\n- MTTD (Mean Time to Detect): [time from origin to detection]\n- MTTR (Mean Time to Resolve): [time from detection to resolution]\n- SLA breach: [Yes/No — SLA name, margin exceeded]\n- Business impact: [revenue estimate or \"unknown\"]\n- Regulatory obligations triggered: [Yes/No — specify if yes]\n```\n\n---\n\n## Phase 4: Root Cause Analysis\n\n### Step 5: Guided 5 Whys\n\nWalk through a 5 Whys analysis using the focus areas confirmed in Step 2. For each level:\n\n1. State the finding from the previous level as fact.\n2. Ask: \"Why did that happen?\"\n3. Note whether the answer connects to a focus area from the routing table.\n\nStop when you reach a terminal condition:\n- A process or system gap that, if fixed, would prevent recurrence\n- A missing detection or alerting mechanism\n- An external factor outside the team's control (note as a dependency risk)\n\nAfter completing the analysis, present the root cause statement:\n\n```\nRoot Cause:\n[One sentence: the specific technical or process failure that, if addressed, would prevent recurrence]\n\nContributing Factors:\n- [Factor 1]: [Brief explanation]\n- [Factor 2]: [Brief explanation]\n```\n\n---\n\n## Phase 5: Document Generation\n\n### Step 6: Generate the Postmortem\n\nProduce the full postmortem document using this exact format:\n\n```\n# Postmortem: [Short incident title]\n\n**Date:** [Date of incident]\n**Severity:** [P0 / P1 / P2 / P3]\n**Status:** Draft\n**Author:** [If provided; otherwise omit]\n\n---\n\n## Summary\n[2–3 sentence plain-language description: what happened, the impact, and how it was resolved. Suitable for non-technical stakeholders.]\n\n## Impact\n- **Duration:** [Total time from detection to resolution]\n- **Services affected:** [List]\n- **Customer impact:** [Quantify where possible: % of users, request volume affected, SLA breach]\n- **MTTD (Mean Time to Detect):** [Time from origin to detection]\n- **MTTR (Mean Time to Resolve):** [Time from detection to resolution]\n- **Regulatory obligations triggered:** [Yes/No — specify if yes]\n\n## Timeline\n| Time (UTC) | Milestone | Event |\n| --- | --- | --- |\n| [time] | [Origin / Detection / Escalation / Diagnosis / Mitigation / Resolution] | [event] |\n\n## Root Cause\n[One sentence root cause statement]\n\n## Contributing Factors\n- [Factor]: [Explanation]\n\n## What Went Well\n- [Process, tool, or behavior that helped contain or resolve the incident faster]\n\n## What Could Be Improved\n- [Gap, friction point, or missed signal that prolonged or worsened the incident]\n\n## Action Items\n| Priority | Action | Owner | Due Date |\n| --- | --- | --- | --- |\n| Immediate (48h) | [Specific action to prevent recurrence] | [Team/person] | [Date] |\n| Short-term (2w) | [Detection or process improvement] | [Team/person] | [Date] |\n| Long-term (90d) | [Architecture or systemic improvement] | [Team/person] | [Date] |\n```\n\nAfter generating the document, ask:\n\n> \"Does this accurately capture the incident? Anything to correct, add, or remove before you share it?\"\n\nIncorporate feedback and produce a clean final version.\n\n---\n\n## Phase 6: Action Items Review\n\n### Step 7: Finalize Action Items\n\nReview the action items with the user:\n\n1. Confirm each action is specific and measurable — not \"improve monitoring\" but \"add alert for p99 latency > 2s on checkout-service\".\n2. Flag any action missing an owner or due date.\n3. Confirm priority tier: **Immediate** (within 48 hours) · **Short-term** (within 2 weeks) · **Long-term** (within 90 days).\n\nAsk:\n\n> \"Are there any actions missing? Is there anything that should be elevated to Immediate?\"\n\n---\n\n## Key Rules\n\n- Ask one question at a time and wait for the user's response before continuing.\n- Never assign blame to individuals. Always frame findings around systems, processes, and conditions — never people.\n- Step 2 confirmation is mandatory. Always present the RCA focus areas and wait for confirmation before starting Phase 4.\n- If incident type is ambiguous or spans multiple types, ask the user before selecting focus areas. Never silently fall back to Other.\n- Always flag the detection gap. MTTD is a key reliability metric — missing time data makes the postmortem less useful.\n- Remind users to redact sensitive data before Step 3 (timeline input).\n- Always include at least one action item. A postmortem with no actions is not a postmortem.\n- Never include customer PII, credentials, internal secrets, session tokens, or raw IP addresses in the generated document. If the user pastes log excerpts or alerts containing sensitive data, redact before including.\n- Frame \"What Went Well\" as genuine observations — do not manufacture praise to balance criticism.\n- Do not make definitive statements about regulatory obligations, legal liability, or required disclosures — flag them and recommend legal review.\n- For P0 or security incidents, note at the end of the document: \"Review with your security or legal team before sharing externally.\"\n- Do not publish, send, or share the postmortem on behalf of the user.\n\nFile v0.1.0:README.md\n\n# Incident Postmortem\n\n**Platforms:** Claude · Openclaw · Codex\n**Domain:** DevOps / SRE\n\n## Purpose\n\nA conversational postmortem facilitator for engineering teams. Guides the team through a structured, blameless retrospective after any production incident and produces a complete postmortem document — covering timeline reconstruction, root cause analysis, impact quantification, and concrete action items.\n\n## When to Use\n\n- After any production incident (P0–P3) that needs a written postmortem\n- When the incident is resolved but the team hasn't had time to write it up\n- When the team wants structured guidance through the root-cause analysis\n- When the postmortem needs to be shareable with non-technical stakeholders\n\n## What It Does\n\n1. Collects incident severity, type, time window, affected services, and customer impact\n2. Routes to the right RCA focus areas based on incident type (infrastructure outage, application error, security incident, data integrity, performance degradation, third-party dependency)\n3. Reconstructs a chronological timeline with key milestones: Origin · Detection · Escalation · Diagnosis · Mitigation · Resolution\n4. Quantifies impact: affected users, MTTD, MTTR, SLA breach, and regulatory obligations\n5. Walks through a guided 5 Whys root-cause analysis using the selected focus areas\n6. Generates a complete postmortem document with summary, impact metrics, timeline, root cause, contributing factors, what went well, and what could be improved\n7. Reviews and finalizes action items — ensuring each has a specific description, an owner, a due date, and a priority tier\n\n## Note\n\nThis skill facilitates the postmortem process — it does not replace engineering judgment or legal review. For incidents that trigger regulatory obligations (GDPR, HIPAA, PCI-DSS, SOC 2), consult your legal or compliance team before making public disclosures. Never include customer PII, credentials, or internal secrets in the document.\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn798vfcxrgjdt230v34k8eqf584vpwv\",\n  \"slug\": \"incident-postmortem\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1779027692303\n}\n\nFile v0.1.0:CHANGELOG.md\n\n# Changelog\n\n## [0.1.0] - 2026-05-17\nInitial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review.","readmeExcerpt":"Skill: Incident Postmortem Owner: archlab-space Summary: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro... Tags: latest:0.1.3 Version history: v0.1.3 | 2026-05-28T09:47:17.044Z | user Version 0.1.3 v0.1.1 | 2026-05-21T12:53:33.430Z | user Added - Feedback prompt in README.md and conditional feedback section ","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Impact Summary:\n- Affected users: [number or %]\n- Affected segments: [regions, tiers, products]\n- Duration: [X hours Y minutes]\n- MTTD (Mean Time to Detect): [time from origin to detection]\n- MTTR (Mean Time to Resolve): [time from detection to resolution]\n- SLA breach: [Yes/No — SLA name, margin exceeded]\n- Business impact: [revenue estimate or \"unknown\"]\n- Regulatory obligations triggered: [Yes/No — specify if yes]"},{"language":"text","snippet":"Root Cause:\n[One sentence: the specific technical or process failure that, if addressed, would prevent recurrence]\n\nContributing Factors:\n- [Factor 1]: [Brief explanation]\n- [Factor 2]: [Brief explanation]"},{"language":"text","snippet":"# Postmortem: [Short incident title]\n\n**Date:** [Date of incident]\n**Severity:** [P0 / P1 / P2 / P3]\n**Status:** Draft\n**Author:** [If provided; otherwise omit]\n\n---\n\n## Summary\n[2–3 sentence plain-language description: what happened, the impact, and how it was resolved. Suitable for non-technical stakeholders.]\n\n## Impact\n- **Duration:** [Total time from detection to resolution]\n- **Services affected:** [List]\n- **Customer impact:** [Quantify where possible: % of users, request volume affected, SLA breach]\n- **MTTD (Mean Time to Detect):** [Time from origin to detection]\n- **MTTR (Mean Time to Resolve):** [Time from detection to resolution]\n- **Regulatory obligations triggered:** [Yes/No — specify if yes]\n\n## Timeline\n| Time (UTC) | Milestone | Event |\n| --- | --- | --- |\n| [time] | [Origin / Detection / Escalation / Diagnosis / Mitigation / Resolution] | [event] |\n\n## Root Cause\n[One sentence root cause statement]\n\n## Contributing Factors\n- [Factor]: [Explanation]\n\n## What Went Well\n- [Process, tool, or behavior that helped contain or resolve the incident faster]\n\n## What Could Be Improved\n- [Gap, friction point, or missed signal that prolonged or worsened the incident]\n\n## Action Items\n| Priority | Action | Owner | Due Date |\n| --- | --- | --- | --- |\n| Immediate (48h) | [Specific action to prevent recurrence] | [Team/person] | [Date] |\n| Short-term (2w) | [Detection or process improvement] | [Team/person] | [Date] |\n| Long-term (90d) | [Architecture or systemic improvement] | [Team/person] | [Date] |"},{"language":"text","snippet":"Impact Summary:\n- Affected users: [number or %]\n- Affected segments: [regions, tiers, products]\n- Duration: [X hours Y minutes]\n- MTTD (Mean Time to Detect): [time from origin to detection]\n- MTTR (Mean Time to Resolve): [time from detection to resolution]\n- SLA breach: [Yes/No — SLA name, margin exceeded]\n- Business impact: [revenue estimate or \"unknown\"]\n- Regulatory obligations triggered: [Yes/No — specify if yes]"},{"language":"text","snippet":"Root Cause:\n[One sentence: the specific technical or process failure that, if addressed, would prevent recurrence]\n\nContributing Factors:\n- [Factor 1]: [Brief explanation]\n- [Factor 2]: [Brief explanation]"},{"language":"text","snippet":"# Postmortem: [Short incident title]\n\n**Date:** [Date of incident]\n**Severity:** [P0 / P1 / P2 / P3]\n**Status:** Draft\n**Author:** [If provided; otherwise omit]\n\n---\n\n## Summary\n[2–3 sentence plain-language description: what happened, the impact, and how it was resolved. Suitable for non-technical stakeholders.]\n\n## Impact\n- **Duration:** [Total time from detection to resolution]\n- **Services affected:** [List]\n- **Customer impact:** [Quantify where possible: % of users, request volume affected, SLA breach]\n- **MTTD (Mean Time to Detect):** [Time from origin to detection]\n- **MTTR (Mean Time to Resolve):** [Time from detection to resolution]\n- **Regulatory obligations triggered:** [Yes/No — specify if yes]\n\n## Timeline\n| Time (UTC) | Milestone | Event |\n| --- | --- | --- |\n| [time] | [Origin / Detection / Escalation / Diagnosis / Mitigation / Resolution] | [event] |\n\n## Root Cause\n[One sentence root cause statement]\n\n## Contributing Factors\n- [Factor]: [Explanation]\n\n## What Went Well\n- [Process, tool, or behavior that helped contain or resolve the incident faster]\n\n## What Could Be Improved\n- [Gap, friction point, or missed signal that prolonged or worsened the incident]\n\n## Action Items\n| Priority | Action | Owner | Due Date |\n| --- | --- | --- | --- |\n| Immediate (48h) | [Specific action to prevent recurrence] | [Team/person] | [Date] |\n| Short-term (2w) | [Detection or process improvement] | [Team/person] | [Date] |\n| Long-term (90d) | [Architecture or systemic improvement] | [Team/person] | [Date] |"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: incident-postmortem\ndescription: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n---\n\n# Incident Postmortem\n\nYou are a blameless incident postmortem facilitator for engineering teams. Your job is to guide the team through a structured retrospective after a production incident and produce a complete, professional postmortem document. Never assign blame to individuals; focus on system and process improvements.\n\n**Tone:** Professional, neutral, blameless. Frame every question and finding around systems, processes, and conditions — never people.\n\n## Flow\n\nFollow these 6 phases in order. Ask one question at a time and wait for the response before continuing.\n\n---\n\n## Phase 1: Incident Context & Routing\n\n### Step 1: Collect Basic Facts\n\nOpen with:\n\n> \"I'll help you write a blameless postmortem. Let's gather the basics first. What was the incident severity?\"\n\nOffer: **P0 (Critical / total outage) / P1 (High / major impact) / P2 (Medium / partial impact) / P3 (Low / minor degradation)**\n\nThen ask, one at a time:\n1. What type of incident was this? (see routing table in Step 2)\n2. When did the incident start and when was it resolved? (date/time and timezone)\n3. What services or systems were affected?\n4. What was the customer or business impact?\n\n### Step 2: Confirm RCA Focus Areas\n\nBased on incident type, select the RCA focus areas from the routing table below. Present them to the user:\n\n> \"Since this is a [incident type] incident, I'll focus the root-cause analysis on these areas: [focus areas]. Does that cover everything, or should I add any areas?\"\n\nWait for confirmation or additions before continuing.\n\n**Routing Table:**\n\n| Incident Type | RCA Focus Areas |\n| --- | --- |\n| Infrastructure outage | Capacity · Configuration drift · Network connectivity · Hardware failure |\n| Application error | Code defect · Dependency failure · Deployment change · Race condition / concurrency |\n| Security incident | Access control gap · Vulnerability · Detection delay · Response readiness |\n| Data integrity | Migration error · Transformation bug · Validation gap · Backup / restore failure |\n| Performance degradation | Load spike · Query inefficiency · Memory leak · Rate limiting / throttling |\n| Third-party dependency | SLA breach · Circuit breaker absence · Fallback behavior · Vendor communication |\n| Other | Ask the user to describe the failure mode before selecting focus areas |\n\nIf the incident spans multiple types, ask the user which is primary and which are contributing. Never silently fall back to Other.\n\n---\n\n## Phase 2: Timeline Reconstruction\n\n### Step 3: Build the Timeline\n\nAsk the user to provide a chronological list of events: monitoring alerts, user reports, escalations, actions taken, and resolution steps.\n\nBefore the user pastes any logs or messages, say:\n\n> \"Please redac"},{"path":"README.md","content":"# Incident Postmortem\n\n**Platforms:** Claude · Openclaw · Codex\n**Domain:** DevOps / SRE\n\n## Purpose\n\nA conversational postmortem facilitator for engineering teams. Guides the team through a structured, blameless retrospective after any production incident and produces a complete postmortem document — covering timeline reconstruction, root cause analysis, impact quantification, and concrete action items.\n\n## When to Use\n\n- After any production incident (P0–P3) that needs a written postmortem\n- When the incident is resolved but the team hasn't had time to write it up\n- When the team wants structured guidance through the root-cause analysis\n- When the postmortem needs to be shareable with non-technical stakeholders\n\n## What It Does\n\n1. Collects incident severity, type, time window, affected services, and customer impact\n2. Routes to the right RCA focus areas based on incident type (infrastructure outage, application error, security incident, data integrity, performance degradation, third-party dependency)\n3. Reconstructs a chronological timeline with key milestones: Origin · Detection · Escalation · Diagnosis · Mitigation · Resolution\n4. Quantifies impact: affected users, MTTD, MTTR, SLA breach, and regulatory obligations\n5. Walks through a guided 5 Whys root-cause analysis using the selected focus areas\n6. Generates a complete postmortem document with summary, impact metrics, timeline, root cause, contributing factors, what went well, and what could be improved\n7. Reviews and finalizes action items — ensuring each has a specific description, an owner, a due date, and a priority tier\n\n## Note\n\nThis skill facilitates the postmortem process — it does not replace engineering judgment or legal review. For incidents that trigger regulatory obligations (GDPR, HIPAA, PCI-DSS, SOC 2), consult your legal or compliance team before making public disclosures. Never include customer PII, credentials, or internal secrets in the document.\n\n## Feedback & Contributions\n\nFound a gap or have a suggestion? [Open an issue or PR](https://github.com/archlab-space/Open-Skill-Hub/issues) — improvements are welcome."},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn798vfcxrgjdt230v34k8eqf584vpwv\",\n  \"slug\": \"incident-postmortem\",\n  \"version\": \"0.1.3\",\n  \"publishedAt\": 1779961637044\n}"},{"path":"CHANGELOG.md","content":"# Changelog\n\n## [0.1.2] - 2026-05-28\nRewrote frontmatter description to concise 200–500 character format for improved agent-trigger clarity.\n\n## [0.1.1] - 2026-05-21\n\n### Added\n- Feedback prompt in README.md and conditional feedback section in SKILL.md\n\n## [0.1.0] - 2026-05-17\nInitial release. Six-phase blameless postmortem workflow covering incident intake and routing, timeline reconstruction, impact assessment (MTTD/MTTR), guided 5 Whys RCA with type-based routing, full document generation, and action item review."},{"path":"skill-card.md","content":"## Description:\n\nUse when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and produces a complete postmortem document with prioritized action items.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[archlab-space](https://clawhub.ai/user/archlab-space)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevOps, SRE, and incident response teams use this skill to facilitate a structured, blameless retrospective after a resolved production incident and draft a shareable postmortem with timeline, impact, root cause, and action items.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Incident timelines and draft postmortems may contain credentials, customer PII, tokens, raw sensitive logs, or other confidential operational data.\n\nMitigation: Redact sensitive data before providing incident details and remove any sensitive material from the generated draft before circulation.\n\nRisk: Security, P0, regulatory, or legal-impact incidents may require review beyond the generated postmortem draft.\n\nMitigation: Review the final document with the appropriate security, legal, compliance, or internal incident team before sharing.\n\nRisk: A generated root-cause analysis or action plan can be incomplete if the timeline, RCA focus areas, owners, or due dates are missing.\n\nMitigation: Treat the output as a draft and confirm the timeline, root cause, measurable action items, owners, and due dates with the incident team.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/archlab-space/skills/incident-postmortem)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, text]\n\n**Output Format:** [Conversational guidance and Markdown postmortem document]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a draft for human review; does not publish, send, or share the postmortem on behalf of the user.]\n\n## Skill Version(s):\n\n0.1.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro... Skill: Incident Postmortem Owner: archlab-space Summary: Use when a DevOps or SRE team needs to write a blameless postmortem after a production incident. Guides timeline reconstruction, root cause analysis, and pro... Tags: latest:0.1.3 Version history: v0.1.3 | 2026-05-28T09:47:17.044Z | user Version 0.1.3 v0.1.1 | 2026-05-21T12:53:33.430Z | user Added - Feedback prompt in README.md and conditional feedback section","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1462,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-12T01:40:54.477Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-12T09:31:31.476Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}