postmortem
von alirezarezvanipostmortem ist ein einzeiliger Executive-Mentor-Skill für blameless 5-Whys-Analysen nach gescheiterten Launches, verfehlten Zielen, Fehlbesetzungen oder operativen Störungen. Er hilft dabei, das Ereignis sauber zu definieren, systemische Ursachen zu finden und ein Änderungsregister mit Verantwortlichen und Follow-up-Maßnahmen zu erstellen.
Dieser Skill erreicht 78/100 Punkte und ist damit ein solider Kandidat für Directory-Nutzer, die einen agentengeführten Executive-Postmortem-Workflow suchen. Die Repository-Nachweise zeigen eine echte, auslösbare SKILL.md mit einem umfangreichen Framework für blameless Fehleranalyse. Der Nutzwert für die Einführung wird jedoch dadurch begrenzt, dass unterstützende Vorlagen, Referenzen, README oder Installationshinweise fehlen.
- Sehr gut auslösbar: Frontmatter und Inhalt definieren mit `/em:postmortem <event>` einen klaren Befehl und nennen konkrete Anwendungsfälle wie failed launches, missed quarters und bad hires.
- Operativ nützlich: Der Auszug zeigt einen strukturierten Postmortem-Ansatz, der damit beginnt, erwartete und tatsächliche Ergebnisse, den Zeitpunkt der Sichtbarkeit und die Auswirkungen präzise zu bestimmen.
- Gute Agenten-Eignung: Die Retrospektive wird als blameless Systems Analysis gerahmt und ausdrücklich von Schuldzuweisungen sowie vagen, beschönigenden Maßnahmenlisten abgegrenzt.
- Es gibt keine ergänzenden Dateien, Vorlagen, Skripte oder Referenzen. Der Skill scheint daher vollständig auf dem Workflow in SKILL.md zu beruhen.
- Am Skill-Pfad sind weder Installationsbefehl noch README vorhanden. Für Directory-Nutzer außerhalb dieser Repository-Struktur kann die Einführung dadurch weniger eindeutig sein.
Überblick über den postmortem skill
Was der postmortem skill leistet
Der postmortem skill ist ein Executive-Mentor-Workflow, der einen gescheiterten Launch, ein verfehltes Ziel, eine Fehlbesetzung, einen verlorenen Deal oder einen operativen Zusammenbruch in eine sachliche Root-Cause-Analyse ohne Schuldzuweisungen überführt. Er führt den Agenten durch eine präzise Ereignisdefinition, disziplinierte 5-Whys-Fragen und ein Change Register, sodass am Ende nicht nur „Lessons Learned“ stehen, sondern konkrete Änderungen am System.
Am besten geeignet für Führung und Quality Management
Dieser postmortem skill ist besonders nützlich für Gründer, Executives, Operators, Product Leaders, Engineering Manager und Quality-Management-Teams, die verstehen müssen, warum ein Ergebnis vom Plan abgewichen ist. Er passt zu Situationen, in denen Prävention und Prozessverbesserung im Vordergrund stehen, nicht Bestrafung. Für postmortem für Quality Management liegt der größte Nutzen darin, Fehler in Kontrollen, Verantwortliche und messbare Follow-up-Maßnahmen zu übersetzen.
Was ihn von einem generischen Prompt unterscheidet
Ein generischer Prompt wie „analysiere, was schiefgelaufen ist“ liefert oft breite Einschätzungen. Dieser Skill ist enger gefasst und stärker operativ ausgerichtet: Er drängt auf ein klar definiertes Ereignis, trennt Symptome von Ursachen, wirkt Schuldzuweisungen entgegen und fragt danach, welche Bedingungen den Fehler wahrscheinlicher gemacht haben. Sein wichtigstes Unterscheidungsmerkmal ist das Change Register, das hilft, Erkenntnisse in Verantwortlichkeiten, Fristen und systemische Korrekturen zu überführen.
Wichtige Hinweise zur Einführung
Der Repository-Pfad enthält eine einzelne SKILL.md und keine Helper-Skripte, Referenzen oder Metadaten-Dateien. Dadurch ist die Installation von postmortem leichtgewichtig, zugleich hängt die Qualität des Skills stark vom Kontext ab, den du bereitstellst. Nutze ihn, wenn du genug belastbare Vorgeschichte teilen kannst, um eine ernsthafte Retrospektive zu ermöglichen. Vermeide ihn, wenn das Ereignis politisch noch zu heikel, rechtlich sensibel oder nur auf Gerüchten basiert.
So nutzt du den postmortem skill
postmortem installieren und relevante Dateien prüfen
Installiere den Skill aus der GitHub-Quelle mit:
npx skills add alirezarezvani/claude-skills --skill postmortem
Die Quelle liegt hier:
c-level-advisor/executive-mentor/skills/postmortem/SKILL.md
Lies zuerst SKILL.md, weil sie das vollständige Arbeitsmodell enthält. Es gibt keine zusätzlichen rules/, resources/, references/ oder scripts/-Ordner, die abgeglichen werden müssten. Deine wichtigste Installationsentscheidung ist daher, ob dieser Ein-Datei-Workflow zu deinem Retrospektiven-Stil passt.
Den Skill in der Praxis aufrufen
Der Skill ist auf folgendes Command Pattern ausgelegt:
/em:postmortem <event>
Ein schwacher Aufruf wäre:
/em:postmortem Q3 release slipped
Ein stärkerer Aufruf gibt dem Agenten genug Material, um Fakten, Annahmen und Ursachen voneinander zu trennen:
/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.
Eingaben, die die postmortem-Nutzung verbessern
Für die beste postmortem-Nutzung solltest du das erwartete Ergebnis, das tatsächliche Ergebnis, die Timeline, erste Warnsignale, Auswirkungen, zentrale Entscheidungen, Einschränkungen und den damaligen Wissensstand bereitstellen. Kombiniere quantitative Evidenz mit menschlichem Kontext: Umsatzlücke, Defect Count, Hiring-Timeline, verfehlter Meilenstein, Kundenauswirkungen, Decision Owner, Freigabe-Engpässe und konkurrierende Prioritäten.
Bitte den Skill nicht darum, „herauszufinden, wer schuld war“. Bitte ihn stattdessen, Systembedingungen zu identifizieren: unklare Zuständigkeiten, schwache Eskalationswege, unrealistische Planungsannahmen, fehlende Quality Gates, Zielkonflikte bei Anreizen oder zu spät sichtbare Risiken.
Empfohlener Ablauf für ein brauchbares Ergebnis
Beginne mit einem faktenbasierten Event Brief und bitte dann um den ersten Postmortem-Entwurf. Prüfe, ob die 5-Whys-Kette zu früh stoppt oder vorschnell zu einer bequemen Erklärung springt. Iteriere anschließend mit Evidenz: „Pressure-test the root cause against the timeline“, „Separate controllable causes from external shocks“ oder „Convert these lessons into a change register suitable for the next exec review.“
Das beste finale Artefakt enthält in der Regel: Ereignisdefinition, Impact-Zusammenfassung, beitragende Faktoren, Root Causes, Nicht-Ursachen, Entscheidungen, die zum damaligen Zeitpunkt nachvollziehbar wirkten, empfohlene Systemänderungen, Verantwortliche, Fristen und Verifikationsmetriken.
FAQ zum postmortem skill
Ist postmortem für Einsteiger geeignet?
Ja, wenn der Nutzer eine klare Ereignisbeschreibung liefern kann. Die Struktur des Skills reduziert die Notwendigkeit, formale Retrospektiven-Methoden schon vorher zu kennen. Einsteiger sollten vor dem Aufruf eine kurze Timeline und die Lücke zwischen Ziel und Ergebnis vorbereiten; andernfalls kann das Modell fehlenden Kontext mit plausiblen, aber nicht verifizierten Annahmen füllen.
Wann sollte ich diesen Skill nicht verwenden?
Verwende ihn nicht als Performance Review, Disziplinarmaßnahme, rechtliche Untersuchung oder öffentliche Incident-Erklärung ohne menschliche Prüfung. Er ist auch ungeeignet, wenn die Führung nur eine geglättete Erzählung möchte statt einer unbequemen Ursachenanalyse. Wenn die Organisation aus den Erkenntnissen keine Maßnahmen ableiten kann, kann ein Postmortem eher Frustration erzeugen als Verbesserung.
Worin unterscheidet er sich von einem Incident Review?
Ein Incident Review konzentriert sich häufig auf technische Service-Ausfälle und operative Wiederherstellung. Dieser postmortem skill ist breiter angelegt: verfehlte Quartalsziele, gescheiterte Launches, Fehlbesetzungen, verlorene Deals, Produktflops und Führungsentscheidungen liegen alle im Scope. Er kann Quality Management unterstützen, ersetzt aber keine regulierte CAPA-, Audit- oder Compliance-Dokumentation, sofern er nicht von qualifizierten Prüfern angepasst wird.
Benötigt der Skill ein bestimmtes Ökosystem?
Nein. Der Skill besteht aus einfachem Markdown und kann mit dem oben genannten Command in einen kompatiblen Skills-Workflow installiert werden. Da es keine Skripte oder externen Assets gibt, ist er über Business-, Produkt-, Engineering- und Operations-Kontexte hinweg portabel. Der Trade-off: Er zieht Dashboards, Ticket-Systeme oder Incident Logs nicht automatisch ein; du musst die relevante Evidenz zusammenfassen oder einfügen.
So verbesserst du den postmortem skill
Gib dem postmortem besseres Ausgangsmaterial
Der schnellste Weg zu besseren postmortem-Ergebnissen ist ein kompaktes Evidenzpaket. Füge ein: Ziel, tatsächliches Ergebnis, Timeline, Entscheidungspunkte, übersehene Signale, Einschränkungen, Stakeholder, Auswirkungen und bestehende Hypothesen. Kennzeichne unsichere Aussagen klar. Zum Beispiel: „Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.“
Achte auf typische Fehlermuster
Der häufigste Fehler ist eine oberflächliche Root Cause wie „schlechte Kommunikation“ oder „fehlende Ownership“. Bitte den Agenten, eine Ebene tiefer zu gehen: Welche Struktur hat Kommunikation scheitern lassen? Warum war Ownership unklar? Warum hat der Planungsprozess diese Unklarheit zugelassen? Ein weiteres Fehlermuster ist Überkorrektur mit zu vielen Action Items. Dränge auf weniger Änderungen, die klar verantwortet, beobachtbar und geeignet sind, eine Wiederholung zu verhindern.
Erkenntnisse in ein Change Register überführen
Ein starkes Change Register sollte die Änderung benennen, die adressierte Root Cause, den Owner, das Fälligkeitsdatum, die Erfolgsmetrik und den Review-Rhythmus. Für Quality-Management-Anwendungsfälle ergänze Kontrolltyp, Verifikationsmethode und erforderliche Evidenz. Dadurch lässt sich der Output des Skills leichter in Leadership Reviews, Quartalsplanung, Release Governance, Änderungen am Hiring-Prozess oder Continuous-Improvement-Programme überführen.
Nach der ersten Antwort iterieren
Stelle nach dem ersten Entwurf gezielte Rückfragen: „Which conclusions are evidence-backed versus inferred?“, „What would have prevented this without slowing the team unnecessarily?“, „What early warning metric should we add?“ oder „Rewrite the change register for executive accountability.“ Der postmortem skill funktioniert am besten, wenn er als strukturierter Untersuchungspartner behandelt wird, nicht als einmaliger Report-Generator.