postmortem
por alirezarezvanipostmortem é uma skill de mentor executivo em arquivo único para análise 5 Whys sem culpabilização após lançamentos malsucedidos, metas não atingidas, más contratações ou falhas operacionais. Ela ajuda a definir o evento, encontrar causas sistêmicas e criar um registro de mudanças com responsáveis e ações de acompanhamento.
Esta skill recebe 78/100, o que a torna uma boa candidata para usuários do diretório que buscam um fluxo de postmortem executivo guiado por agente. As evidências do repositório mostram um SKILL.md real e acionável, com uma estrutura robusta para análise de falhas sem culpabilização, mas o valor de adoção é limitado pela ausência de templates de apoio, referências, README ou instruções de instalação.
- Altamente acionável: o frontmatter e o corpo definem um comando claro, `/em:postmortem <event>`, e citam casos de uso concretos, como lançamentos malsucedidos, trimestres com metas não batidas e más contratações.
- Útil para a operação: o trecho mostra uma abordagem estruturada de postmortem que começa pela definição precisa dos resultados esperados versus os resultados reais, do momento em que o problema ficou visível e do impacto.
- Bom uso com agentes: enquadra a retrospectiva como análise sistêmica sem culpabilização e a diferencia explicitamente de sessões de apontar culpados e de planos de ação vagos que apenas maquiam o problema.
- Não há arquivos de apoio, templates, scripts ou referências incluídos, então a skill parece depender inteiramente do fluxo descrito em SKILL.md.
- Não há comando de instalação nem README no caminho da skill, o que pode tornar a adoção menos clara para usuários do diretório fora desta estrutura de repositório.
Visão geral do postmortem skill
O que o postmortem skill faz
O postmortem skill é um fluxo de trabalho de mentoria executiva para transformar um lançamento malsucedido, uma meta não atingida, uma contratação ruim, um negócio perdido ou uma falha operacional em uma análise de causa raiz sem culpabilização. Ele orienta o agente por uma definição precisa do evento, uma sequência disciplinada de perguntas no modelo 5-Whys e um registro de mudanças, para que o resultado não seja apenas “lições aprendidas”, mas um conjunto concreto de mudanças sistêmicas.
Melhor uso para liderança e Quality Management
Este postmortem skill é mais útil para fundadores, executivos, operadores, líderes de produto, gerentes de engenharia e equipes de Quality Management que precisam entender por que um resultado saiu diferente do planejado. Ele se encaixa em situações nas quais o objetivo é prevenção e melhoria de processo, não punição. Em casos de uso de postmortem para Quality Management, o maior valor está em traduzir falhas em controles, responsáveis e ações de acompanhamento mensuráveis.
O que o diferencia de um prompt genérico
Um prompt genérico do tipo “analise o que deu errado” costuma gerar comentários amplos. Este skill é mais focado e operacional: ele força uma definição clara do evento, separa sintomas de causas, desencoraja a busca por bodes expiatórios e pergunta quais condições tornaram a falha mais provável. Seu principal diferencial é o registro de mudanças, que ajuda a converter aprendizados em responsáveis, prazos e correções no nível do sistema.
Observações importantes antes de adotar
O caminho do repositório contém um único SKILL.md e não inclui scripts auxiliares, referências nem arquivos de metadados. Isso torna a instalação do postmortem leve, mas também significa que o skill depende muito da qualidade do contexto que você fornece. Use-o quando puder compartilhar histórico factual suficiente para sustentar uma retrospectiva séria; evite quando o evento ainda for politicamente inseguro, juridicamente sensível ou baseado apenas em rumores.
Como usar o postmortem skill
Instalação do postmortem e arquivos a inspecionar
Instale a partir da fonte do skill no GitHub com:
npx skills add alirezarezvani/claude-skills --skill postmortem
O arquivo-fonte fica em:
c-level-advisor/executive-mentor/skills/postmortem/SKILL.md
Leia SKILL.md primeiro, porque ele contém o modelo operacional completo. Não há pastas extras rules/, resources/, references/ ou scripts/ para conciliar; portanto, sua principal decisão de instalação é avaliar se esse fluxo de trabalho em arquivo único combina com seu estilo de retrospectiva.
Como chamar o skill na prática
O skill foi desenhado em torno do padrão de comando:
/em:postmortem <event>
Uma chamada fraca seria:
/em:postmortem Q3 release slipped
Uma chamada mais forte dá ao agente material suficiente para separar fatos, premissas e causas:
/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.
Entradas que melhoram o uso do postmortem
Para obter o melhor uso do postmortem, informe o resultado esperado, o resultado real, a linha do tempo, os primeiros sinais de alerta, o impacto, as principais decisões, as restrições e o que era sabido naquele momento. Inclua tanto evidências quantitativas quanto contexto humano: lacuna de receita, número de defeitos, cronograma de contratação, marco perdido, impacto em clientes, responsáveis por decisões, gargalos de aprovação e prioridades concorrentes.
Evite pedir ao skill para “descobrir quem causou isso”. Em vez disso, peça que ele identifique condições sistêmicas: responsabilidades pouco claras, caminhos de escalonamento frágeis, premissas de planejamento irreais, quality gates ausentes, conflitos de incentivo ou baixa visibilidade tardia de riscos.
Fluxo de trabalho sugerido para um resultado útil
Comece com um resumo factual do evento e, então, peça o primeiro rascunho do postmortem. Revise se a cadeia de 5-Whys para cedo demais ou salta para uma explicação conveniente. Depois, itere com evidências: “Pressure-test the root cause against the timeline,” “Separate controllable causes from external shocks,” ou “Convert these lessons into a change register suitable for the next exec review.”
O melhor artefato final geralmente inclui: definição do evento, resumo de impacto, fatores contribuintes, causas raiz, não causas, decisões que pareciam razoáveis no momento, mudanças sistêmicas recomendadas, responsáveis, prazos e métricas de verificação.
FAQ do postmortem skill
O postmortem é adequado para iniciantes?
Sim, desde que o usuário consiga fornecer uma descrição clara do evento. A estrutura do skill reduz a necessidade de conhecer previamente métodos formais de retrospectiva. Iniciantes devem preparar uma linha do tempo curta e a diferença entre resultado esperado e real antes de acioná-lo; caso contrário, o modelo pode preencher lacunas de contexto com hipóteses plausíveis, mas não verificadas.
Quando eu não devo usar este skill?
Não o use como avaliação de desempenho, ferramenta disciplinar, investigação jurídica ou declaração pública sobre incidente sem revisão humana. Ele também não é uma boa opção quando a liderança quer apenas uma narrativa polida, em vez de uma análise causal desconfortável. Se a organização não puder agir sobre as descobertas, um postmortem pode gerar frustração em vez de melhoria.
Em que ele é diferente de uma revisão de incidente?
Uma revisão de incidente costuma se concentrar em falhas técnicas de serviço e recuperação operacional. Este postmortem skill é mais amplo: trimestres perdidos, lançamentos malsucedidos, contratações ruins, negócios perdidos, fracassos de produto e decisões de liderança estão todos dentro do escopo. Ele pode apoiar Quality Management, mas não substitui documentação regulada de CAPA, auditoria ou compliance, a menos que seja adaptado por revisores qualificados.
O skill exige um ecossistema específico?
Não. O skill é markdown simples e pode ser instalado em um fluxo de trabalho de skills compatível usando o comando acima. Como não há scripts nem ativos externos, ele é portátil entre contextos de negócio, produto, engenharia e operações. A contrapartida é que ele não ingere automaticamente dashboards, sistemas de tickets ou logs de incidentes; você precisa resumir ou colar as evidências relevantes.
Como melhorar o postmortem skill
Dê matéria-prima melhor ao postmortem
A forma mais rápida de melhorar os resultados do postmortem é fornecer um pacote compacto de evidências. Inclua: objetivo, resultado real, linha do tempo, pontos de decisão, sinais ignorados, restrições, stakeholders, impacto e hipóteses existentes. Marque claramente afirmações incertas. Por exemplo: “Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”
Fique atento aos modos de falha mais comuns
A falha mais comum é chegar a uma causa raiz superficial, como “comunicação ruim” ou “falta de ownership”. Peça ao agente para descer mais um nível: que estrutura fez a comunicação falhar? Por que a responsabilidade estava pouco clara? Por que o processo de planejamento permitiu essa ambiguidade? Outro modo de falha é corrigir em excesso com itens de ação demais. Pressione por menos mudanças, mas que tenham responsável, sejam observáveis e tenham boa chance de prevenir recorrência.
Transforme descobertas em um registro de mudanças
Um bom registro de mudanças deve nomear a mudança, a causa raiz que ela endereça, o responsável, a data de conclusão, a métrica de sucesso e a cadência de revisão. Para uso em Quality Management, acrescente tipo de controle, método de verificação e evidência exigida. Isso torna a saída do skill mais fácil de operacionalizar em revisões de liderança, planejamento trimestral, governança de releases, mudanças no processo de contratação ou programas de melhoria contínua.
Itere depois da primeira resposta
Depois do primeiro rascunho, faça perguntas de acompanhamento direcionadas: “Which conclusions are evidence-backed versus inferred?”, “What would have prevented this without slowing the team unnecessarily?”, “What early warning metric should we add?”, ou “Rewrite the change register for executive accountability.” O postmortem skill funciona melhor quando tratado como um parceiro de investigação estruturada, não como um gerador de relatório de uma única rodada.
