create-delivery-postmortem

Name: create-delivery-postmortem
Author: opendatahub-io

36stars74forks

How to install create-delivery-postmortem?

opendatahub-io/ai-helpers/create-delivery-postmortem

$npx -y skills add opendatahub-io/ai-helpers --skill create-delivery-postmortem

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Post-Mortem Create Skill
2
3	Facilitate writing a structured post-mortem document for release delays and delivery incidents. The
4	skill gathers context from the user, synthesizes narrative sections, facilitates an interactive Five
5	Whys root cause analysis, and produces an executive-ready document.
6
7	## Arguments
8
9	- title (required): Short incident name (e.g., "ROCm RPM Delay")
10	- release (optional): Target release milestone (e.g., "3.5 EA2", "4.0 GA")
11	- priority (optional): critical / high / medium / low
12	- format (optional, default: html): Output format — `html` or `markdown`
13
14	Example: `/create-delivery-postmortem title="ROCm RPM Delay" release="3.5 EA2" priority="high"`
15
16	## Steps
17
18	When invoked:
19
20	### Phase 1: Context Gathering
21
22	1. Prompt for context. Tell the user what input is most valuable, in this order of usefulness:
23
24	1. Slack threads or conversations — paste directly. These are the richest source for building
25	timelines and identifying who knew what and when.
26	2. JIRA ticket IDs — look these up for context (committed dates, status changes, comments).
27	3. Committed delivery dates — when was something promised, and by whom?
28	4. Key people involved — who owned the deliverable, who raised the risk, who responded.
29	5. Meeting notes or email excerpts — especially anything documenting commitments or escalations.
30	6. Free-form narrative — the user's own understanding of what happened.
31
32	Say: "Paste whatever you have — Slack threads, JIRA ticket IDs, notes, narrative. The most useful
33	things are conversations that show when risks were raised and committed delivery dates. Send as
34	many messages as you need. Say 'done' when you've shared everything."
35
36	Accept input across multiple messages until the user signals completion.
37
38	2. Synthesize narrative sections. From the gathered context, draft:
39
40	- Postmortem Summary: Incident name, author (from `git config user.name`, confirm with user),
41	priority, target release.
42	- Executive Summary: One paragraph — what happened, what the impact was, what was learned.
43	Written for a Director-level audience who needs the picture in 30 seconds.
44	- Leadup: Sequence of events leading to the incident. Use specific dates and actors.
45	- Impact: Potential or observed delivery impact. Be specific about what was delayed, by how
46	long, and what downstream was affected.
47	- Detection and Timeline: When the team detected or raised the risk. Name people,
48	communication channels (Slack, email, meeting), and timestamps.
49	- Response: Who responded and what was done at each stage. Include delays or obstacles to
50	responding. Be specific about handoffs.
51	- Recovery: When the incident was resolved. Describe how time-to-mitigation could have been
52	improved.
53
54	3. Present for review. Show the drafted sections to the user. Ask them to correct facts, fill
55	gaps, and adjust framing. Iterate until the user approves all narrative sections before moving to
56	Phase 2.
57
58	### Phase 2: Root Cause Analysis — Interactive Five Whys
59
60	4. Draft the Five Whys chain. Analyze the approved narrative and propose an initial Five Whys
61	chain. Start from the surface-level problem statement and work down. For each "why":
62	- State the question ("Why did X happen?")
63	- Propose the answer
64	- Cite evidence from the context (Slack message, date, committed delivery)
65
66	5. Facilitate interactive refinement. Present the chain and walk through it with the user. At
67	each level, actively push back when:
68
69	- A "why" restates the symptom rather than identifying a cause. ("The RPMs were late" →
70	"The RPMs were delayed" is restating. "The RPMs were late" → "The upstream rebuild took longer
71	than the compressed timeline allowed" is a cause.)
72	- The chain stops at human error ("someone forgot") instead of a systemic gap ("there was no
73	process to ensure..."). Always ask: "Why was it possible for this to be forgotten? What system
74	or process should have caught this?"
75	- A causal link lacks evidence. If the user asserts a cause, ask for specifics: "Was the code
76	freeze communicated somewhere the team should have seen it? Can you point to where?"
77	- The chain branches and one branch is being ignored. If there are multipl

People who liked this also viewed

6 picks

Type

create-delivery-postmortem

36stars74forks

View on GitHub

How to install create-delivery-postmortem?

opendatahub-io/ai-helpers/create-delivery-postmortem

$npx -y skills add opendatahub-io/ai-helpers --skill create-delivery-postmortem

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Post-Mortem Create Skill
2
3	Facilitate writing a structured post-mortem document for release delays and delivery incidents. The
4	skill gathers context from the user, synthesizes narrative sections, facilitates an interactive Five
5	Whys root cause analysis, and produces an executive-ready document.
6
7	## Arguments
8
9	- title (required): Short incident name (e.g., "ROCm RPM Delay")
10	- release (optional): Target release milestone (e.g., "3.5 EA2", "4.0 GA")
11	- priority (optional): critical / high / medium / low
12	- format (optional, default: html): Output format — `html` or `markdown`
13
14	Example: `/create-delivery-postmortem title="ROCm RPM Delay" release="3.5 EA2" priority="high"`
15
16	## Steps
17
18	When invoked:
19
20	### Phase 1: Context Gathering
21
22	1. Prompt for context. Tell the user what input is most valuable, in this order of usefulness:
23
24	1. Slack threads or conversations — paste directly. These are the richest source for building
25	timelines and identifying who knew what and when.
26	2. JIRA ticket IDs — look these up for context (committed dates, status changes, comments).
27	3. Committed delivery dates — when was something promised, and by whom?
28	4. Key people involved — who owned the deliverable, who raised the risk, who responded.
29	5. Meeting notes or email excerpts — especially anything documenting commitments or escalations.
30	6. Free-form narrative — the user's own understanding of what happened.
31
32	Say: "Paste whatever you have — Slack threads, JIRA ticket IDs, notes, narrative. The most useful
33	things are conversations that show when risks were raised and committed delivery dates. Send as
34	many messages as you need. Say 'done' when you've shared everything."
35
36	Accept input across multiple messages until the user signals completion.
37
38	2. Synthesize narrative sections. From the gathered context, draft:
39
40	- Postmortem Summary: Incident name, author (from `git config user.name`, confirm with user),
41	priority, target release.
42	- Executive Summary: One paragraph — what happened, what the impact was, what was learned.
43	Written for a Director-level audience who needs the picture in 30 seconds.
44	- Leadup: Sequence of events leading to the incident. Use specific dates and actors.
45	- Impact: Potential or observed delivery impact. Be specific about what was delayed, by how
46	long, and what downstream was affected.
47	- Detection and Timeline: When the team detected or raised the risk. Name people,
48	communication channels (Slack, email, meeting), and timestamps.
49	- Response: Who responded and what was done at each stage. Include delays or obstacles to
50	responding. Be specific about handoffs.
51	- Recovery: When the incident was resolved. Describe how time-to-mitigation could have been
52	improved.
53
54	3. Present for review. Show the drafted sections to the user. Ask them to correct facts, fill
55	gaps, and adjust framing. Iterate until the user approves all narrative sections before moving to
56	Phase 2.
57
58	### Phase 2: Root Cause Analysis — Interactive Five Whys
59
60	4. Draft the Five Whys chain. Analyze the approved narrative and propose an initial Five Whys
61	chain. Start from the surface-level problem statement and work down. For each "why":
62	- State the question ("Why did X happen?")
63	- Propose the answer
64	- Cite evidence from the context (Slack message, date, committed delivery)
65
66	5. Facilitate interactive refinement. Present the chain and walk through it with the user. At
67	each level, actively push back when:
68
69	- A "why" restates the symptom rather than identifying a cause. ("The RPMs were late" →
70	"The RPMs were delayed" is restating. "The RPMs were late" → "The upstream rebuild took longer
71	than the compressed timeline allowed" is a cause.)
72	- The chain stops at human error ("someone forgot") instead of a systemic gap ("there was no
73	process to ensure..."). Always ask: "Why was it possible for this to be forgotten? What system
74	or process should have caught this?"
75	- A causal link lacks evidence. If the user asserts a cause, ask for specifics: "Was the code
76	freeze communicated somewhere the team should have seen it? Can you point to where?"
77	- The chain branches and one branch is being ignored. If there are multipl

People who liked this also viewed

6 picks

Type