project-retrospective

Name: project-retrospective
Author: jamditis

336stars57forks

How to install project-retrospective?

jamditis/claude-skills-journalism/project-retrospective

$npx -y skills add jamditis/claude-skills-journalism --skill project-retrospective

Installs into the current project.

Summary

Generate LESSONS.md retrospective files that capture institutional knowledge, especially failures. Use when closing out journalism projects, investigations, events, or publications. Includes templates for research projects, event post-mortems, editorial tools, and publications.

Files · 1

View on GitHub

SKILL.md

1	# Project retrospective writer
2
3	Create LESSONS.md files that capture institutional knowledge, especially failures. Think like a journalist writing about your own project — be specific, be honest, name the actual mistakes.
4
5	## Frame the retrospective: blame-aware, not pure-blameless
6
7	The 2024–2026 consensus in incident-analysis writing (PagerDuty, J. Paul Reed, Lorin Hochstein) is that pure blamelessness is neurobiologically unrealistic — humans default to blame. Healthier framing: acknowledge the blame bias exists and counter it deliberately. Source: https://postmortems.pagerduty.com/culture/blameless/
8
9	Cognitive biases to counter explicitly:
10	- Fundamental attribution error — blaming individuals for failures the system permitted
11	- Confirmation bias — looking for evidence that confirms a pre-formed narrative
12	- Hindsight bias — judging past decisions by knowledge that wasn't available at the time
13	- Negativity bias — over-weighting what went wrong vs. what worked
14
15	The voice rule isn't "no blame" — it's "name the system that permitted the human action, not just the action."
16
17	## Drop the single-root-cause framing
18
19	Allspaw's canonical critique (still the dominant view in 2024–2026) calls Five Whys / single-root-cause analysis "seductively satisfying and compellingly simple — but false." It locks analysts into a linear causal chain that terminates in individual blame. Source: https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/
20
21	Use "how" narratives instead, gathering on four prompts:
22	- Cues — what signals were available, who saw them when?
23	- Interpretation — how did people make sense of those signals?
24	- Goals — what were people trying to accomplish?
25	- Taking action — what did they do, and what did they expect to happen?
26
27	The retrospective's job is to surface contributing factors, not declare a root cause.
28
29	## When to run a retrospective
30
31	Pre-define triggers before incidents happen, not after. Google SRE specifies criteria: user-visible downtime past a threshold, any data loss, on-call rollbacks, monitoring failures requiring manual discovery, stakeholder request. Source: https://sre.google/sre-book/postmortem-culture/
32
33	Translated to journalism:
34
35	\| Trigger \| Examples \|
36	\|---\|---\|
37	\| Live-event failure \| Live-blog downtime during election night, breaking-news embed breakage, paywall regression mid-investigation \|
38	\| Editorial process failure \| Missed correction window, source-management breach, fact-check process bypass \|
39	\| Tool failure affecting subscribers \| CMS migration regression, paywall logic affecting >X% of readers \|
40	\| Stakeholder request \| Editor / publisher / source explicitly asking "what happened?" \|
41
42	Pre-defined triggers prevent retrospective theater on routine work and ensure they happen on real failures.
43
44	## Timing: aim for under one week
45
46	Google's good-vs-bad postmortem comparison cites a "four months later" example as a quality failure because contributors' memories had decayed. Source: https://sre.google/workbook/postmortem-culture/
47
48	Recommended cadence:
49
50	\| Project type \| Target window \|
51	\|---\|---\|
52	\| Live-event retro (election night, breaking news) \| Same-day debrief, written within 48h \|
53	\| Tool / CMS incident \| Within one week \|
54	\| Investigation or publication launch \| Within one month of project close \|
55	\| Annual review of ongoing initiative \| Once per year, scoped to discrete decision points \|
56
57	The empirical floor is "fresh in contributors' minds." Past one week and the narrative gets reconstructed rather than remembered.
58
59	## For event-type retros, use AAR structure
60
61	The US Army's After Action Review (FM 7-0 Appendix K) was designed for facilitated post-event debriefs and fits live-news realities better than a project-close template. Source: https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf
62
63	Four prompts:
64	1. What was supposed to happen?
65	2. What did happen?
66	3. What was right or wrong about the difference?
67	4. How do we perform to standard next time?
68
69	Run AAR immediately after the event with all participants — election night newsroom team, live-blog runners, breaking-news desk. Use `event.md` template for this; project-close templates are wrong for live-event retros.
70
71	## The critical section: "The real problem"
72
73	This is the most valuable part of any retrospective. It answers:
74
75	> "What did we THINK we were building vs. what was ACTUALLY needed?"
76
77	Strong example:
78	> We built an admin dashboard for editors when they actually needed a Slack bot. They live in Slack — forcing them to open a web app was friction they'd never accept. The dashboard has 2 monthly active users; the Slack

People who liked this also viewed

6 picks

Type

project-retrospective

336stars57forks

View on GitHub

How to install project-retrospective?

jamditis/claude-skills-journalism/project-retrospective

$npx -y skills add jamditis/claude-skills-journalism --skill project-retrospective

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Project retrospective writer
2
3	Create LESSONS.md files that capture institutional knowledge, especially failures. Think like a journalist writing about your own project — be specific, be honest, name the actual mistakes.
4
5	## Frame the retrospective: blame-aware, not pure-blameless
6
7	The 2024–2026 consensus in incident-analysis writing (PagerDuty, J. Paul Reed, Lorin Hochstein) is that pure blamelessness is neurobiologically unrealistic — humans default to blame. Healthier framing: acknowledge the blame bias exists and counter it deliberately. Source: https://postmortems.pagerduty.com/culture/blameless/
8
9	Cognitive biases to counter explicitly:
10	- Fundamental attribution error — blaming individuals for failures the system permitted
11	- Confirmation bias — looking for evidence that confirms a pre-formed narrative
12	- Hindsight bias — judging past decisions by knowledge that wasn't available at the time
13	- Negativity bias — over-weighting what went wrong vs. what worked
14
15	The voice rule isn't "no blame" — it's "name the system that permitted the human action, not just the action."
16
17	## Drop the single-root-cause framing
18
19	Allspaw's canonical critique (still the dominant view in 2024–2026) calls Five Whys / single-root-cause analysis "seductively satisfying and compellingly simple — but false." It locks analysts into a linear causal chain that terminates in individual blame. Source: https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/
20
21	Use "how" narratives instead, gathering on four prompts:
22	- Cues — what signals were available, who saw them when?
23	- Interpretation — how did people make sense of those signals?
24	- Goals — what were people trying to accomplish?
25	- Taking action — what did they do, and what did they expect to happen?
26
27	The retrospective's job is to surface contributing factors, not declare a root cause.
28
29	## When to run a retrospective
30
31	Pre-define triggers before incidents happen, not after. Google SRE specifies criteria: user-visible downtime past a threshold, any data loss, on-call rollbacks, monitoring failures requiring manual discovery, stakeholder request. Source: https://sre.google/sre-book/postmortem-culture/
32
33	Translated to journalism:
34
35	\| Trigger \| Examples \|
36	\|---\|---\|
37	\| Live-event failure \| Live-blog downtime during election night, breaking-news embed breakage, paywall regression mid-investigation \|
38	\| Editorial process failure \| Missed correction window, source-management breach, fact-check process bypass \|
39	\| Tool failure affecting subscribers \| CMS migration regression, paywall logic affecting >X% of readers \|
40	\| Stakeholder request \| Editor / publisher / source explicitly asking "what happened?" \|
41
42	Pre-defined triggers prevent retrospective theater on routine work and ensure they happen on real failures.
43
44	## Timing: aim for under one week
45
46	Google's good-vs-bad postmortem comparison cites a "four months later" example as a quality failure because contributors' memories had decayed. Source: https://sre.google/workbook/postmortem-culture/
47
48	Recommended cadence:
49
50	\| Project type \| Target window \|
51	\|---\|---\|
52	\| Live-event retro (election night, breaking news) \| Same-day debrief, written within 48h \|
53	\| Tool / CMS incident \| Within one week \|
54	\| Investigation or publication launch \| Within one month of project close \|
55	\| Annual review of ongoing initiative \| Once per year, scoped to discrete decision points \|
56
57	The empirical floor is "fresh in contributors' minds." Past one week and the narrative gets reconstructed rather than remembered.
58
59	## For event-type retros, use AAR structure
60
61	The US Army's After Action Review (FM 7-0 Appendix K) was designed for facilitated post-event debriefs and fits live-news realities better than a project-close template. Source: https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf
62
63	Four prompts:
64	1. What was supposed to happen?
65	2. What did happen?
66	3. What was right or wrong about the difference?
67	4. How do we perform to standard next time?
68
69	Run AAR immediately after the event with all participants — election night newsroom team, live-blog runners, breaking-news desk. Use `event.md` template for this; project-close templates are wrong for live-event retros.
70
71	## The critical section: "The real problem"
72
73	This is the most valuable part of any retrospective. It answers:
74
75	> "What did we THINK we were building vs. what was ACTUALLY needed?"
76
77	Strong example:
78	> We built an admin dashboard for editors when they actually needed a Slack bot. They live in Slack — forcing them to open a web app was friction they'd never accept. The dashboard has 2 monthly active users; the Slack

People who liked this also viewed

6 picks

Type