postmortem-writing

Visão geral da skill postmortem-writing

O que a postmortem-writing faz

A skill postmortem-writing ajuda um agente a produzir postmortems de incidentes estruturados e sem culpabilização, incluindo as partes que as equipes normalmente esquecem sob pressão: uma linha do tempo clara, análise de causa raiz, fatores contribuintes, impacto e ações de acompanhamento concretas. Ela foi pensada para a redação de relatórios após indisponibilidades, degradação de serviço, quase-incidentes, problemas de dados ou outros incidentes que merecem aprendizado organizacional — e não apenas um resumo solto.

Quem deve instalar a postmortem-writing

Esta skill é especialmente indicada para:

• equipes de SRE, DevOps, plataforma e resposta a incidentes
• gerentes de engenharia que precisam de relatórios de incidente consistentes
• pessoas responsáveis por entregáveis internos de report writing após outages
• equipes que querem migrar de retrospectivas centradas em culpa para uma abordagem de systems thinking

Se o seu principal trabalho é transformar anotações confusas de incidentes em um postmortem realmente útil, postmortem-writing é mais direcionada do que um prompt genérico de escrita.

O trabalho real que ela resolve

A maioria dos usuários não precisa de ajuda para “escrever um documento” de forma abstrata. Precisa de ajuda para transformar logs, threads de chat, alertas e lembranças parciais em um relatório que:

• explique o que aconteceu em linguagem clara
• preserve a cronologia
• separe causa raiz de fatores contribuintes
• evite culpar indivíduos
• termine com ações que possam realmente ser acompanhadas

Esse é o valor prático da skill postmortem-writing.

O que diferencia esta skill de um prompt comum

O principal diferencial não é automação sofisticada. É a estrutura editorial e a disciplina de revisão de incidentes. O material de origem enfatiza:

• framing sem culpabilização
• gatilhos explícitos para definir quando um postmortem é justificável
• um fluxo de trabalho guiado primeiro pela linha do tempo
• análise de causa raiz em vez de sintomas superficiais
• action items como produto final, não como detalhe de última hora

Isso faz da postmortem-writing skill uma opção útil quando você quer consistência e linguagem mais segura, e não apenas um texto mais polido.

O que saber antes de adotar

Esta skill é centrada em documentação. As evidências no repositório mostram apenas SKILL.md, sem scripts auxiliares, schemas ou arquivos de referência. Isso significa que a postmortem-writing install é simples, mas a qualidade da saída depende bastante dos insumos de incidente que você fornecer. Se você espera coleta automática de evidências ou criação de tickets, esta skill não faz isso sozinha.

Como usar a skill postmortem-writing

Contexto de instalação da postmortem-writing

Instale a partir do repositório pai de skills:

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

Como a skill está em plugins/incident-response/skills/postmortem-writing, o que você instala é um fluxo de escrita com camada de orientação — não uma plataforma completa de incidentes.

Leia este arquivo primeiro

Comece por:

• SKILL.md

Não há resources/, rules/ ou scripts de apoio expostos para esta skill, então o caminho mais rápido para entender o repositório é simplesmente ler SKILL.md do início ao fim. Isso importa aqui porque o valor está na orientação de processo e no enquadramento, não em código.

Melhores momentos para acionar a postmortem-writing

Use postmortem-writing usage quando você já souber que um incidente merece um relatório formal, especialmente em casos como:

• incidentes SEV1 ou SEV2
• indisponibilidades voltadas ao cliente que durem mais do que uma oscilação trivial
• perda de dados ou problemas de segurança
• quase-incidentes com alto potencial de gravidade
• falhas inéditas ou intervenção operacional incomum

Se o evento foi pequeno e não exige aprendizado nem remediação, uma nota curta de incidente pode ser suficiente.

De que entradas a skill precisa

A skill funciona melhor quando você fornece material bruto do incidente, e não apenas “escreva um postmortem”. Entradas úteis incluem:

• resumo do incidente
• horários de início e fim
• impacto para clientes ou sistemas
• linha do tempo dos eventos principais
• método de detecção
• passos de mitigação
• causa raiz suspeita
• fatores contribuintes conhecidos
• questões ainda em aberto
• ações de acompanhamento já discutidas

Quanto mais precisa for a cronologia, melhor tende a ser o relatório final.

Como transformar um pedido vago em um prompt forte

Prompt fraco:

• “Write a postmortem for yesterday’s outage.”

Prompt forte:

• “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.”

Por que isso é melhor:

• define o escopo do incidente
• pede framing sem culpabilização
• solicita seções importantes que costumam faltar
• permite incerteza em vez de certeza inventada

Um template prático de prompt

Use uma estrutura de prompt como esta:

• Tipo de incidente: outage, degradation, security event, data incident, near-miss
• Severidade: nível SEV ou equivalente
• Janela de tempo: início, detecção, mitigação, resolução
• Impacto: usuários, receita, requests, dados, operações internas
• Evidências: logs, alerts, chat notes, trechos de tickets
• Causa suspeita: o que falhou e por quê
• Fatores contribuintes: tooling, process, load, config, staffing, dependencies
• Saída desejada: executive summary, timeline, RCA, lessons learned, action items
• Restrição de tom: blameless, factual, no named-person blame
• Desconhecidos: liste-os explicitamente

Essa é a maneira mais rápida de melhorar postmortem-writing for Report Writing.

Fluxo de trabalho sugerido para incidentes reais

Um fluxo viável é:

1. Reunir os fatos brutos a partir das notas do incidente e das evidências do sistema.
2. Pedir à skill um primeiro rascunho estruturado.
3. Revisar a linha do tempo em busca de erros de sequência.
4. Refinar a diferença entre causa raiz e fatores contribuintes.
5. Remover formulações orientadas à culpa.
6. Adicionar action items com responsáveis e datas fora do rascunho, se necessário.
7. Usar o relatório final na reunião de postmortem.

Essa sequência reflete como as equipes realmente escrevem após um incidente: primeiro os fatos, depois a interpretação, por último a remediação.

Como obter linhas do tempo melhores com postmortem-writing

A qualidade da linha do tempo normalmente determina se o documento parece confiável. Forneça à skill bullets com timestamp, como:

• 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

Sem isso, até mesmo um bom postmortem-writing guide não consegue reconstruir a causalidade com confiança.

Como pedir uma análise de causa raiz melhor

Não peça apenas “a causa raiz”. Peça:

• causa imediata
• fatores sistêmicos mais profundos
• por que as salvaguardas falharam
• por que a detecção ou o escalonamento atrasou
• o que tornou a falha possível

Isso evita que a saída se reduza a algo como “houve um deploy ruim”, que em geral é superficial demais para ser útil.

Como manter o texto sem culpabilização

A skill coloca explicitamente a cultura blameless no centro. Reforce isso no prompt:

• peça foco nas condições do sistema, não em culpa individual
• solicite linguagem neutra
• peça que ações humanas sejam separadas do contexto organizacional e técnico

Por exemplo, prefira:

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

O que esta skill não oferece

A postmortem-writing skill aparentemente não inclui:

• coleta automatizada de dados
• extração da timeline de incidentes a partir de ferramentas
• sincronização com tickets
• lógica de classificação de severidade além de orientação geral
• templates específicos da sua organização prontos para uso

Planeje fornecer seu próprio contexto e adaptar a saída ao programa de incidentes da sua equipe.

FAQ da skill postmortem-writing

A postmortem-writing é melhor do que um prompt comum de LLM?

Na maioria dos casos, sim — se o seu principal problema for estrutura e disciplina. Um prompt comum consegue gerar um postmortem, mas frequentemente deixa de fora os gatilhos do incidente, o framing sem culpabilização ou a distinção entre causa raiz e fatores contribuintes. postmortem-writing dá ao agente um padrão de operação mais claro.

Ela é adequada para iniciantes?

Sim. É amigável para iniciantes porque é fortemente guiada por orientações e não exige tooling customizado. Ainda assim, iniciantes continuam precisando trazer o registro factual do incidente. A skill melhora a qualidade da escrita e a estrutura de revisão; ela não substitui a investigação do incidente.

Quando não devo usar postmortem-writing?

Evite usar quando:

• o evento não justifica um postmortem completo
• você precisa de um incident commander em tempo real, não de um redator
• ainda faltam fatos básicos e o debugging continua em andamento
• sua organização exige um template proprietário rígido que esta skill não consegue atender sem adaptação pesada

A postmortem-writing serve apenas para outages de engenharia?

Não. Ela se alinha melhor a incidentes técnicos, mas a estrutura também funciona para incidentes de segurança, problemas de dados, falhas operacionais e quase-incidentes graves, desde que você consiga fornecer uma timeline, o impacto e as ações corretivas.

Posso usar postmortem-writing para executive summaries?

Sim, mas não pare por aí. Em geral, executivos precisam de um resumo curto, enquanto quem respondeu ao incidente precisa da timeline completa e do plano de ação. Peça à skill para produzir tanto um resumo conciso quanto o relatório completo.

A skill ajuda com action items?

Sim, indiretamente. A orientação de origem enfatiza itens de acompanhamento acionáveis. Você terá resultados melhores se pedir ações agrupadas por categoria, como prevenção, detecção, resposta e melhoria de processo.

Como melhorar a skill postmortem-writing

Dê à postmortem-writing evidências melhores, não apenas instruções melhores

A maior alavanca de qualidade está na fidelidade das entradas. Cole:

• timestamps
• métricas de impacto ao cliente
• nomes de alerts
• passos de mitigação
• known unknowns

Evidência rica supera meta-instruções elaboradas.

Separe fatos de interpretação

Um modo comum de falha é misturar suposições na linha do tempo. Forneça dois blocos:

• fatos confirmados
• hipóteses ou questões em aberto

Isso ajuda o postmortem-writing usage a se manter preciso, sem deixar de explicitar incertezas.

Peça explicitamente as seções que estiverem faltando

Se o primeiro rascunho estiver genérico demais, solicite as seções ausentes pelo nome:

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

Pedidos de revisão concretos melhoram os resultados mais rápido do que “make it better”.

Evite action items superficiais

Postmortems fracos terminam com ações vagas como “improve monitoring”. Peça à skill para tornar cada ação:

• específica
• atribuível
• ligada a um modo de falha
• mensurável ou testável

Por exemplo:

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  é melhor do que:
• “Improve alerting”

Fique atento quando a culpabilização voltar a aparecer

Mesmo com uma skill blameless, o material de origem vindo de chats ou notas pode conter linguagem excessivamente orientada à culpa. Revise o texto procurando formulações que foquem demais em uma pessoa, em vez de condições de sistema, incentivos, tooling, lacunas de revisão ou contexto operacional.

Itere em duas passadas para obter saída de maior qualidade

Um padrão confiável é:

1. primeira passada para a estrutura factual
2. segunda passada para análise e ações

Isso evita forçar o modelo a inventar um raciocínio polido antes que a cronologia esteja estável.

Adapte a saída ao nível de maturidade de postmortem da sua equipe

Se sua equipe ainda está no início, peça ao postmortem-writing um formato simples com timeline, impacto, causas e ações. Se a equipe já for madura, peça seções mais profundas, como lacunas de detecção, eficácia do escalonamento, trade-offs de recuperação e aprendizados sistêmicos. A mesma skill pode atender aos dois cenários, mas só se você definir a profundidade esperada.

Melhore os resultados de report writing após o primeiro rascunho

Para obter resultados mais fortes com postmortem-writing for Report Writing, faça uma revisão final com base em quatro perguntas:

• Uma pessoa nova na equipe entenderia o que aconteceu?
• A linha do tempo está precisa o suficiente para auditoria?
• A análise explica por que as defesas falharam?
• As ações são concretas o suficiente para reduzir recorrência?

Se alguma resposta for não, revise o prompt com foco nessa lacuna em vez de apenas rodar novamente às cegas.