create-delivery-postmortem

name	create-delivery-postmortem
description	Use when a release delay, missed deadline, or delivery incident needs a structured post-mortem. Facilitates context gathering, timeline synthesis, and interactive Five Whys root cause analysis. Produces an executive-ready document in HTML or Markdown.
allowed-tools	Read Write Bash(git config:*) Bash(open:*) Bash(xdg-open:*) AskUserQuestion
user-invocable	true
argument-hint	title=<title> release=<release> priority=<priority> format=<html|markdown>
metadata	{"author":"AIPCC","version":"1.0","tags":["postmortem","release","root-cause-analysis","five-whys"]}

Post-Mortem Create Skill

Facilitate writing a structured post-mortem document for release delays and delivery incidents. The skill gathers context from the user, synthesizes narrative sections, facilitates an interactive Five Whys root cause analysis, and produces an executive-ready document.

Arguments

• title (required): Short incident name (e.g., "ROCm RPM Delay")
• release (optional): Target release milestone (e.g., "3.5 EA2", "4.0 GA")
• priority (optional): critical / high / medium / low
• format (optional, default: html): Output format — html or markdown

Example: /create-delivery-postmortem title="ROCm RPM Delay" release="3.5 EA2" priority="high"

Steps

When invoked:

Phase 1: Context Gathering

1. Prompt for context. Tell the user what input is most valuable, in this order of usefulness:

   1. Slack threads or conversations — paste directly. These are the richest source for building timelines and identifying who knew what and when.
   2. JIRA ticket IDs — look these up for context (committed dates, status changes, comments).
   3. Committed delivery dates — when was something promised, and by whom?
   4. Key people involved — who owned the deliverable, who raised the risk, who responded.
   5. Meeting notes or email excerpts — especially anything documenting commitments or escalations.
   6. Free-form narrative — the user's own understanding of what happened.

   Say: "Paste whatever you have — Slack threads, JIRA ticket IDs, notes, narrative. The most useful things are conversations that show when risks were raised and committed delivery dates. Send as many messages as you need. Say 'done' when you've shared everything."

   Accept input across multiple messages until the user signals completion.

2. Synthesize narrative sections. From the gathered context, draft:

   • Postmortem Summary: Incident name, author (from git config user.name, confirm with user), priority, target release.
   • Executive Summary: One paragraph — what happened, what the impact was, what was learned. Written for a Director-level audience who needs the picture in 30 seconds.
   • Leadup: Sequence of events leading to the incident. Use specific dates and actors.
   • Impact: Potential or observed delivery impact. Be specific about what was delayed, by how long, and what downstream was affected.
   • Detection and Timeline: When the team detected or raised the risk. Name people, communication channels (Slack, email, meeting), and timestamps.
   • Response: Who responded and what was done at each stage. Include delays or obstacles to responding. Be specific about handoffs.
   • Recovery: When the incident was resolved. Describe how time-to-mitigation could have been improved.

3. Present for review. Show the drafted sections to the user. Ask them to correct facts, fill gaps, and adjust framing. Iterate until the user approves all narrative sections before moving to Phase 2.

Phase 2: Root Cause Analysis — Interactive Five Whys

4. Draft the Five Whys chain. Analyze the approved narrative and propose an initial Five Whys chain. Start from the surface-level problem statement and work down. For each "why":

   • State the question ("Why did X happen?")
   • Propose the answer
   • Cite evidence from the context (Slack message, date, committed delivery)

5. Facilitate interactive refinement. Present the chain and walk through it with the user. At each level, actively push back when:

   • A "why" restates the symptom rather than identifying a cause. ("The RPMs were late" → "The RPMs were delayed" is restating. "The RPMs were late" → "The upstream rebuild took longer than the compressed timeline allowed" is a cause.)
   • The chain stops at human error ("someone forgot") instead of a systemic gap ("there was no process to ensure..."). Always ask: "Why was it possible for this to be forgotten? What system or process should have caught this?"
   • A causal link lacks evidence. If the user asserts a cause, ask for specifics: "Was the code freeze communicated somewhere the team should have seen it? Can you point to where?"
   • The chain branches and one branch is being ignored. If there are multiple contributing causes, note all branches and explore each.

   Prompt for additional context where the chain is thin. Ask specific questions, not generic ones.

6. Converge on root cause. The Five Whys must land on something systemic and actionable — a process gap, communication breakdown, or missing feedback loop. If the proposed root cause is not actionable (e.g., "vendors are slow"), push deeper: "What could we have done earlier to detect or mitigate the vendor delay?"

   Five Whys principles to enforce:

   • Start from a clear, specific problem statement — not a vague complaint.
   • Each "why" must be a direct cause — not a restatement, correlation, or blame assignment.
   • Don't stop at human error — dig into why the system allowed or failed to prevent the error.
   • Follow all significant branches — if there are multiple contributing causes, explore each.
   • Stop when you reach something systemic and actionable — a process, communication, or structural gap that can be fixed.
   • Cite evidence — each causal link should reference specific events, dates, or communications.
   • Five is a guideline, not a rule — stop when you hit root cause, whether at 3 or 7.

7. Related incidents (optional, but prompt for it). Ask the user: "Has anything like this happened before? If so, what was done about it, and why did it happen again despite that mitigation?"

Phase 3: Output Generation

10. Read the HTML template. Read template.html from the skill directory (same directory as this SKILL.md file).

11. Generate the document. Replace each {{PLACEHOLDER}} in the template with the approved content. Follow these rules:

    • All content sections must use proper HTML tags (<p>, <ul>, <li>, <ol>, etc.).
    • {{TITLE}}: The incident title from the title argument.
    • {{AUTHOR}}: The author name confirmed with the user.
    • {{DATE}}: Today's date in YYYY-MM-DD format.
    • {{RELEASE_META}}: If release was provided: <span><span class="label">Release:</span> {release}</span>. Otherwise, empty string.
    • {{PRIORITY_META}}: If priority was provided: <span><span class="label">Priority:</span> <span class="priority-badge priority-{priority}">{priority}</span></span>. Otherwise, empty string.
    • {{EXECUTIVE_SUMMARY}}: The executive summary paragraph wrapped in <p> tags.
    • {{LEADUP}}, {{IMPACT}}, {{DETECTION_TIMELINE}}, {{RESPONSE}}, {{RECOVERY}}: Each section's content using appropriate HTML. Use <p> for paragraphs, <ul>/<li> for lists, <ol>/<li> for ordered sequences.
    • {{FIVE_WHYS}}: Render each why as a <div class="why-step"> containing:
      • <div class="why-number"> with "W1", "W2", etc.
      • <div class="why-content"> containing:
        • <div class="why-question"> with the "Why?" question
        • <div class="why-answer"> with the answer
        • <div class="why-evidence"> with the supporting evidence (if any) The last why-step is styled differently (red border) automatically by the CSS to highlight the root cause level.
    • {{ROOT_CAUSE}}: The final root cause statement wrapped in tags.

Output

After generating the post-mortem:

• Report the output file path
• Offer to open in browser
• Offer to make final changes
• Do NOT commit to git, create branches, or assume any repo workflow