| name | posts-postmortem |
| description | Generate retrospective failure analyses for the worst-performing published posts so the writer and critic learn from misses, not just wins. Reads the bottom-5 posts by impressions from `posts/`, classifies each, and writes one postmortem file per post to `retros/postmortems/<post-date>-<slug>.md`. Use when the user says "run postmortems", "analyze bottom posts", "what failed", "post-mortem the losers", or "refresh failure analyses". Also invoked by `post-cycle` when the postmortem corpus is stale. |
posts-postmortem
This skill produces structured failure analyses for the worst-performing posts in the archive. post-retro covers the recent post you just shipped — this skill covers the bottom of the corpus so the writer and critic know which patterns reliably miss.
Inputs
bun run top-posts --json — the JSON includes the bottom-5 by impressions. Read it to know which posts to analyze.
bun run post-patterns — for median impressions and the existing classification per post.
- The post files themselves, at
posts/YYYY/MM-DD-<slug>.md. Read each one in full.
If bun run top-posts --json does not surface bottom posts directly, fall back to sorting the JSON by impressions and taking the bottom 5 (where impressions is non-null).
Inputs the user may pass
--n N (optional): override the bottom-count, default 5.
- A list of explicit post paths: run postmortems for those specific files instead of auto-picking from impressions.
What each postmortem must answer
For each underperforming post:
- How far below the corpus median did it land?
- Which anti-patterns from
bun run post-patterns does it match (news without firsthand signal, no concrete numbers, question ending without substance, announcement hook that reads like recap)?
- Was the hook accurate to the body or did it overpromise?
- Was the topic family already saturated when the post ran (look at adjacent published posts in the same month)?
- What single concrete thing would have changed the outcome — sharper hook, firsthand signal, different topic family, longer body, named numbers?
Answers must be grounded in the post's actual text. Do not speculate beyond the file and the patterns report.
Output artifact
One markdown file per analyzed post at:
retros/postmortems/<post-date>-<slug>.md
Use the post's date and slug from its filename (posts/2026/05-21-alibaba-launched-qwen-...md → retros/postmortems/2026-05-21-alibaba-launched-qwen-....md).
Frontmatter
---
kind: postmortem
source_post: posts/2026/05-21-alibaba-launched-qwen-...md
topic_family: agents
source_type: news
hook_type: announcement
impressions: 160
likes: 2
comments: 1
shares: 0
corpus_median_at_run: 569
beat_median: false
likely_failure_modes:
- news posts without firsthand signal
- announcement hooks that read like recaps
- hook overpromised, body underdelivered
decision: modify
summary: One-sentence summary tying topic family + failure mode + what to change next time.
generated_at: 2026-05-25T13:30:00.000Z
---
decision reuses the existing RetroDecision enum:
repeat — not applicable here. Postmortems are for misses.
modify — same topic family worth attempting again with a different angle, hook, or source type.
block — stop pitching this topic-family + source-type combo entirely (or until a new artifact justifies it).
likely_failure_modes should pull from the anti-pattern vocabulary in bun run post-patterns where it applies, plus one or two post-specific observations.
Body
3 to 5 short paragraphs. Concrete and grounded. Structure:
- What the post tried to do (1 sentence, derived from its hook and topic).
- Where it landed numerically vs the corpus median.
- The 1 or 2 specific failure modes you identified, named with evidence from the post text.
- The single concrete thing to change next time on this topic family / source type.
Do not write a generic "be more specific" lecture. Name the actual missing element ("no firsthand benchmark," "hook said the model is the agent frontier, body never explained what that meant," "topic family agents had two other posts within 7 days").
Workflow
- Run
bun run top-posts --json and bun run post-patterns.
- Identify the bottom 5 posts (or
--n N) by impressions, excluding posts with null impressions.
- For each:
- Read the post file in full.
- Classify topic family, source type, hook type from the post text (mirrors
bun src/cli/post-patterns.ts heuristics).
- Pick 1 to 3 anti-patterns from the patterns report that this post exhibits.
- Decide
modify vs block.
- Write a one-sentence summary and a 3-to-5-paragraph body.
- Save to
retros/postmortems/<post-date>-<slug>.md.
- Print a one-line index of generated files at the end.
Idempotency
If a postmortem already exists for a post, overwrite it. The bottom-5 set can shift as new posts get scraped, so old postmortems may become stale. Track via generated_at.
Output
Print only the index, one line per file:
retros/postmortems/2026-05-21-alibaba-launched-qwen-3-7-max-yesterday-and-called-it-the-ag.md
retros/postmortems/2026-04-29-it-only-knows-the-world-up-to-1930-no-internet-no-wwii-no-mo.md
...
No preamble. No summary table. The patterns CLI will surface the aggregated failure modes when it loads retros/postmortems/.
Hard rules
- Never analyze a post with
null impressions. Lack of data is not failure.
- Never invent a failure mode that is not supported by the post's text or the patterns report.
- Never produce postmortems for posts already in the top quartile.
- Always reuse the anti-pattern vocabulary from
bun run post-patterns where it applies. Add a post-specific observation only as a second or third bullet.
- Always set
kind: postmortem so the patterns CLI can distinguish these from success retros.
When NOT to use
- The user just published a draft and wants to retro it. Use
post-retro instead.
- The user wants performance scoring of a single named post they already have. Use
post-retro with manual inputs.
- The corpus is smaller than 10 posts. The bottom 5 would dominate the signal. Skip until there is enough corpus.