postmortem-writing

Présentation de la compétence postmortem-writing

Ce que fait postmortem-writing

La compétence postmortem-writing aide un agent à produire des postmortems d’incident structurés et non culpabilisants, avec les éléments que les équipes oublient souvent sous pression : une chronologie claire, une analyse de la cause racine, les facteurs contributifs, l’impact et des actions de suivi concrètes. Elle est pensée pour la rédaction de rapports après des pannes, des dégradations de service, des quasi-incidents, des problèmes de données ou d’autres événements qui méritent un apprentissage organisationnel plutôt qu’un simple résumé approximatif.

À qui s’adresse postmortem-writing

Cette compétence est particulièrement adaptée à :

• les équipes SRE, DevOps, plateforme et réponse à incident
• les responsables engineering qui ont besoin de rapports d’incident cohérents
• les personnes chargées de rédiger des livrables internes après une panne
• les équipes qui veulent passer de rétrospectives centrées sur la faute à une approche orientée systèmes

Si votre besoin principal est de transformer des notes d’incident désordonnées en un postmortem exploitable, postmortem-writing est plus ciblé qu’un simple prompt générique de rédaction.

Le vrai besoin couvert

La plupart des utilisateurs n’ont pas simplement besoin d’aide pour « rédiger un document » de manière abstraite. Ils ont besoin d’aide pour transformer des logs, des fils de discussion, des alertes et des souvenirs partiels en un rapport qui :

• explique clairement ce qui s’est passé
• respecte la chronologie
• distingue la cause racine des facteurs contributifs
• évite de désigner des individus comme responsables
• se termine par des actions réellement suivables

C’est là toute la valeur pratique de la compétence postmortem-writing.

Ce qui distingue cette compétence d’un prompt classique

Le principal différenciateur n’est pas une automatisation sophistiquée. C’est sa structure éditoriale et sa discipline de revue d’incident. Le contenu source met l’accent sur :

• un cadrage non culpabilisant
• des déclencheurs explicites pour savoir quand un postmortem s’impose
• un workflow centré d’abord sur la chronologie
• une analyse de la cause racine plutôt que des symptômes de surface
• des actions correctives conçues comme le livrable final, et non comme un ajout de dernière minute

Cela rend la postmortem-writing skill utile quand vous cherchez de la cohérence et une formulation plus sûre, pas seulement un texte bien tourné.

Ce qu’il faut savoir avant de l’adopter

Cette compétence est avant tout centrée sur la documentation. Les éléments du dépôt montrent uniquement SKILL.md, sans scripts d’aide, schémas ni fichiers de référence. Cela signifie que l’installation de postmortem-writing est simple, mais que la qualité de sortie dépend fortement des informations d’incident que vous fournissez. Si vous attendez une collecte automatique de preuves ou la création de tickets, cette compétence ne le fera pas à elle seule.

Comment utiliser la compétence postmortem-writing

Contexte d’installation de postmortem-writing

Installez-la depuis le dépôt parent des skills :

npx skills add https://github.com/wshobson/agents --skill postmortem-writing

Comme la compétence se trouve dans plugins/incident-response/skills/postmortem-writing, vous installez un workflow de rédaction et une couche de guidance, pas une plateforme complète de gestion d’incident.

Commencez par lire ce fichier

Commencez par :

• SKILL.md

Aucun resources/, rules/ ou script de support n’est exposé pour cette compétence ; le chemin le plus rapide pour comprendre le dépôt consiste donc simplement à lire SKILL.md du début à la fin. C’est important ici, car la valeur se trouve dans la méthode et le cadrage, pas dans du code.

Les meilleurs moments pour invoquer postmortem-writing

Utilisez postmortem-writing usage quand vous savez déjà qu’un incident mérite un compte rendu formel, en particulier pour :

• les incidents SEV1 ou SEV2
• les interruptions visibles côté client au-delà d’un simple incident mineur
• les pertes de données ou problèmes de sécurité
• les quasi-incidents à fort potentiel de gravité
• les défaillances inédites ou les interventions opérateur inhabituelles

Si l’événement était mineur et qu’aucun apprentissage ni aucune remédiation ne sont nécessaires, une note d’incident courte peut suffire.

Les entrées dont la compétence a besoin

La compétence fonctionne bien mieux si vous fournissez la matière brute de l’incident, et pas seulement « rédige un postmortem ». Les entrées utiles incluent :

• un résumé de l’incident
• les heures de début et de fin
• l’impact client ou système
• la chronologie des événements clés
• le mode de détection
• les étapes de mitigation
• la cause racine suspectée
• les facteurs contributifs connus
• les questions non résolues
• les actions de suivi déjà évoquées

Plus votre chronologie est précise, meilleur sera le rapport final.

Transformer une demande vague en prompt solide

Prompt faible :

• « Write a postmortem for yesterday’s outage. »

Prompt solide :

• “Use the postmortem-writing skill to draft a blameless postmortem for a 47-minute API outage on 2025-02-10. Include a minute-by-minute timeline, impact summary, root cause, contributing factors, what detection missed, and action items grouped by prevention, detection, and response. Mark uncertainties clearly instead of inventing details.”

Pourquoi c’est meilleur :

• le périmètre de l’incident est défini
• le cadrage non culpabilisant est explicitement demandé
• les sections importantes mais souvent absentes sont précisées
• l’incertitude est autorisée au lieu d’encourager une certitude inventée

Un modèle de prompt pratique

Utilisez une structure de prompt comme celle-ci :

• Type d’incident : outage, degradation, security event, data incident, near-miss
• Gravité : niveau SEV ou équivalent
• Fenêtre temporelle : début, détection, mitigation, résolution
• Impact : utilisateurs, revenus, requêtes, données, opérations internes
• Preuves : logs, alertes, notes de chat, extraits de ticket
• Cause suspectée : ce qui a échoué et pourquoi
• Facteurs contributifs : outillage, processus, charge, config, staffing, dépendances
• Sortie souhaitée : executive summary, timeline, RCA, lessons learned, action items
• Contrainte de ton : blameless, factual, no named-person blame
• Inconnues : les lister explicitement

C’est le moyen le plus rapide d’améliorer postmortem-writing for Report Writing.

Workflow recommandé pour des incidents réels

Un déroulé efficace ressemble à ceci :

1. Rassembler les faits bruts à partir des notes d’incident et des éléments système.
2. Demander à la compétence un premier brouillon structuré.
3. Relire la chronologie pour corriger les erreurs d’enchaînement.
4. Mieux distinguer cause racine et facteurs contributifs.
5. Supprimer les formulations orientées vers la faute.
6. Ajouter, si nécessaire, des actions avec responsables et échéances en dehors du brouillon.
7. Utiliser le rapport final pendant la réunion de postmortem.

Cette séquence correspond à la manière dont les équipes rédigent réellement après un incident : d’abord les faits, ensuite l’interprétation, enfin la remédiation.

Comment obtenir de meilleures chronologies avec postmortem-writing

La qualité de la chronologie détermine souvent si le document paraît fiable ou non. Donnez à la compétence des puces horodatées comme :

• 09:14 UTC: latency alert fired
• 09:16 UTC: on-call acknowledged
• 09:21 UTC: deploy rollback started
• 09:37 UTC: error rate returned to baseline

Sans cela, même un bon postmortem-writing guide ne peut pas reconstituer de manière fiable la causalité.

Comment demander une meilleure analyse de cause racine

Ne demandez pas seulement « la cause racine ». Demandez :

• la cause immédiate
• les facteurs systémiques plus profonds
• pourquoi les garde-fous ont échoué
• pourquoi la détection ou l’escalade a été tardive
• ce qui a rendu cette défaillance possible

Cela évite que la sortie se résume à « un mauvais déploiement a eu lieu », ce qui est en général bien trop superficiel pour être utile.

Comment garder un compte rendu non culpabilisant

La compétence place explicitement la culture blameless au centre. Renforcez ce point dans votre prompt :

• demandez-lui de se concentrer sur les conditions système, pas sur la faute individuelle
• demandez une formulation neutre
• demandez à distinguer les actions humaines du contexte organisationnel et technique

Par exemple, préférez :

• “The deployment process allowed an unsafe config change to reach production”
  à :
• “An engineer pushed the wrong setting”

Ce que cette compétence ne fournit pas

La postmortem-writing skill ne semble pas inclure :

• la collecte automatisée de données
• l’extraction de chronologie depuis vos outils
• la synchronisation des tickets
• une logique de classification de gravité au-delà de recommandations générales
• des modèles spécifiques à votre organisation prêts à l’emploi

Prévoyez donc d’apporter votre propre contexte et d’adapter la sortie à votre programme de gestion d’incident.

FAQ sur la compétence postmortem-writing

postmortem-writing est-elle meilleure qu’un prompt LLM classique ?

En général oui, si votre principal problème est la structure et la discipline. Un prompt classique peut générer un postmortem, mais il oublie souvent les déclencheurs d’incident, le cadrage non culpabilisant ou la distinction entre cause racine et facteurs contributifs. postmortem-writing donne à l’agent un cadre de travail plus net.

Cette compétence convient-elle aux débutants ?

Oui. Elle est accessible aux débutants parce qu’elle repose surtout sur de la guidance et ne demande pas d’outillage personnalisé. En revanche, les débutants doivent quand même fournir un relevé factuel de l’incident. La compétence améliore la qualité de rédaction et la structure de revue ; elle ne remplace pas l’enquête d’incident.

Quand ne faut-il pas utiliser postmortem-writing ?

Évitez-la quand :

• l’événement ne justifie pas un postmortem complet
• vous avez besoin d’un incident commander en temps réel, pas d’un rédacteur
• vous manquez encore des faits de base et êtes toujours en phase active de debug
• votre organisation impose un template propriétaire strict que cette compétence ne peut pas reproduire sans forte adaptation

postmortem-writing fonctionne-t-elle uniquement pour des pannes d’ingénierie ?

Non. Elle est mieux alignée avec les incidents techniques, mais le cadre convient aussi aux incidents de sécurité, aux problèmes de données, aux défaillances opérationnelles et aux quasi-incidents sérieux, à condition de pouvoir fournir une chronologie, un impact et des actions correctives.

Puis-je utiliser postmortem-writing pour des synthèses exécutives ?

Oui, mais il ne faut pas s’arrêter là. Les dirigeants ont généralement besoin d’un résumé court, tandis que les équipes de réponse ont besoin de la chronologie complète et du plan d’action. Demandez à la compétence de produire à la fois une synthèse concise et le rapport complet.

La compétence aide-t-elle pour les actions de suivi ?

Oui, indirectement. Les indications source insistent sur des actions de suivi réellement exploitables. Vous obtiendrez de meilleurs résultats si vous demandez des actions regroupées par catégorie, par exemple prévention, détection, réponse et amélioration de processus.

Comment améliorer la compétence postmortem-writing

Donnez à postmortem-writing de meilleures preuves, pas seulement de meilleures instructions

Le levier principal de qualité, c’est la fidélité des entrées. Collez notamment :

• les horodatages
• les métriques d’impact client
• les noms d’alerte
• les étapes de mitigation
• les inconnues déjà identifiées

Des éléments factuels riches valent mieux que des méta-instructions élaborées.

Séparer les faits de l’interprétation

Un mode d’échec fréquent consiste à mélanger les hypothèses à la chronologie. Fournissez deux blocs :

• faits confirmés
• hypothèses ou questions ouvertes

Cela aide postmortem-writing usage à rester précis tout en faisant apparaître les incertitudes.

Demander explicitement les sections manquantes

Si votre premier brouillon est trop générique, demandez les sections manquantes par leur nom :

• “Add a ‘What went well’ section”
• “Separate contributing factors from root cause”
• “Rewrite action items so each is specific and testable”

Des demandes de révision concrètes améliorent les résultats plus vite qu’un simple « améliore ça ».

Éviter des actions de suivi trop superficielles

Les postmortems faibles se terminent souvent par des actions vagues comme « améliorer le monitoring ». Demandez à la compétence de rendre chaque action :

• spécifique
• attribuable
• liée à un mode de défaillance
• mesurable ou testable

Par exemple :

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  est préférable à :
• “Improve alerting”

Surveiller le retour d’un ton culpabilisant

Même avec une compétence pensée pour le blameless, les échanges ou notes source peuvent contenir un langage accusatoire. Relisez les formulations qui concentrent trop l’attention sur une personne au lieu des conditions système, des incitations, de l’outillage, des lacunes de revue ou du contexte opérationnel.

Itérer en deux passes pour une meilleure sortie

Un schéma fiable consiste à procéder ainsi :

1. première passe pour la structure factuelle
2. deuxième passe pour l’analyse et les actions

Cela évite de pousser le modèle à inventer un raisonnement bien présenté avant que la chronologie soit stabilisée.

Adapter la sortie au niveau de maturité postmortem de votre équipe

Si votre équipe débute, demandez à postmortem-writing un format simple avec chronologie, impact, causes et actions. Si votre équipe est plus mature, demandez des sections plus approfondies comme les lacunes de détection, l’efficacité de l’escalade, les arbitrages de reprise et les enseignements systémiques. La même compétence peut couvrir les deux cas, mais seulement si vous précisez le niveau de profondeur attendu.

Améliorer les résultats de rédaction de rapport après le premier brouillon

Pour obtenir de meilleurs résultats avec postmortem-writing for Report Writing, faites une relecture finale à partir de quatre questions :

• Un nouveau membre de l’équipe comprendrait-il ce qui s’est passé ?
• La chronologie est-elle assez précise pour être auditée ?
• L’analyse explique-t-elle pourquoi les défenses ont échoué ?
• Les actions sont-elles assez concrètes pour réduire le risque de récurrence ?

Si la réponse est non à l’une d’elles, révisez le prompt sur ce point précis au lieu de relancer aveuglément.