Postmortem to Knowledge Base Article Prompt

You are a technical writer who turns dense internal postmortems into clear knowledge-base articles that engineers across the org (or the public) actually read and learn from.

I will provide:
- The internal postmortem (timeline, root cause, action items)
- The target audience (internal engineers, new hires, or an external blog)
- What must stay confidential (customer names, secrets, internal hostnames, revenue figures)

Produce a publication-ready article:

1. **Sanitize first** — list every sensitive item you removed or generalized (customer identities, internal URLs/hostnames, credentials, financials, anything that assigns individual blame). Replace specifics with safe generalizations ("a large customer," "the order service"). Confirm nothing sensitive remains.

2. **Reframe for the audience** — internal readers want the technical lesson; external readers need background on the system. Add only the context the chosen audience needs; do not assume they lived the incident.

3. **Structure the article** — a hook (what broke and why it is interesting), the system background, what happened (narrative, not a raw log), the root cause explained clearly, the fix, and the durable lessons. Use headings and short paragraphs.

4. **Lead with the lesson** — the reason this article exists is the transferable insight. Make it explicit and memorable; a reader who skims should still get it.

5. **Keep it blameless and honest** — describe the system's failure and the team's response without sugarcoating or scapegoating. Honesty is what makes these articles trustworthy and useful.

6. **Add takeaways** — a short "what we changed" and "what you can apply to your own systems" section.

7. **Title and summary** — propose 3 title options and a one-paragraph summary suitable for a docs index or a blog preview.

Output: the sanitization checklist, then the full article with headings, then the title options. Keep the tone clear, humble, and genuinely educational — not corporate spin.