postmortem
por alirezarezvanipostmortem es una skill de mentoría ejecutiva en un solo archivo para análisis de 5 Porqués sin culpas tras lanzamientos fallidos, objetivos incumplidos, malas contrataciones o quiebres operativos. Ayuda a definir el evento, identificar causas del sistema y crear un registro de cambios con responsables y acciones de seguimiento.
Esta skill obtiene 78/100, lo que la convierte en una candidata sólida para usuarios del directorio que buscan un flujo de postmortem ejecutivo guiado por agente. La evidencia del repositorio muestra un SKILL.md real y activable, con un marco sustancial para análisis de fallos sin culpas, pero su valor de adopción se ve limitado por la falta de plantillas de apoyo, referencias, README o instrucciones de instalación.
- Muy fácil de activar: el frontmatter y el cuerpo definen un comando claro, `/em:postmortem <event>`, y mencionan casos de uso concretos como lanzamientos fallidos, trimestres con objetivos incumplidos y malas contrataciones.
- Útil a nivel operativo: el extracto muestra un enfoque estructurado de postmortem que empieza por definir con precisión los resultados esperados frente a los reales, el momento en que se hizo visible el problema y su impacto.
- Buen aprovechamiento del agente: plantea la retrospectiva como un análisis de sistemas sin culpas y la diferencia explícitamente de las sesiones de reproches y de acciones vagas que solo maquillan el problema.
- No incluye archivos de apoyo, plantillas, scripts ni referencias, por lo que la skill parece depender por completo del flujo de trabajo de SKILL.md.
- No hay comando de instalación ni README en la ruta de la skill, lo que puede dificultar la adopción para usuarios del directorio que no conozcan la estructura de este repositorio.
Resumen de postmortem skill
Qué hace postmortem skill
La postmortem skill es un flujo de trabajo de mentoría ejecutiva para convertir un lanzamiento fallido, un objetivo incumplido, una mala contratación, una oportunidad perdida o una ruptura operativa en un análisis de causa raíz sin culpabilización. Guía al agente para definir el evento con precisión, aplicar preguntas disciplinadas de 5 Whys y crear un registro de cambios, de modo que el resultado no sea solo una lista de “lecciones aprendidas”, sino un conjunto concreto de cambios al sistema.
Mejor encaje para liderazgo y Quality Management
Esta postmortem skill es especialmente útil para fundadores, ejecutivos, responsables de operaciones, líderes de producto, managers de ingeniería y equipos de Quality Management que necesitan entender por qué un resultado se desvió del plan. Encaja en situaciones donde el objetivo es la prevención y la mejora de procesos, no el castigo. En casos de uso de postmortem para Quality Management, su mayor valor está en traducir fallos en controles, responsables y acciones de seguimiento medibles.
Qué la diferencia de un prompt genérico
Un prompt genérico de “analiza qué salió mal” suele producir comentarios amplios. Esta skill es más específica y operativa: exige un evento claramente definido, separa síntomas de causas, desalienta la búsqueda de chivos expiatorios y pregunta qué condiciones hicieron probable el fallo. Su principal diferenciador es el registro de cambios, que ayuda a convertir los hallazgos en responsables, plazos y correcciones a nivel de sistema.
Notas importantes antes de adoptarla
La ruta del repositorio contiene un único SKILL.md y no incluye scripts auxiliares, referencias ni archivos de metadatos. Eso hace que instalar postmortem sea ligero, pero también significa que la skill depende mucho de la calidad del contexto que proporciones. Úsala cuando puedas compartir suficiente historial factual para sostener una retrospectiva seria; evítala cuando el evento todavía sea políticamente inseguro, legalmente sensible o se base solo en rumores.
Cómo usar postmortem skill
Instalación de postmortem y archivos que conviene revisar
Instala desde la fuente de skills en GitHub con:
npx skills add alirezarezvani/claude-skills --skill postmortem
La fuente se encuentra en:
c-level-advisor/executive-mentor/skills/postmortem/SKILL.md
Lee primero SKILL.md porque contiene el modelo operativo completo. No hay carpetas adicionales rules/, resources/, references/ ni scripts/ que conciliar, así que la decisión principal de instalación es si este flujo de trabajo de un solo archivo encaja con tu estilo de retrospectiva.
Cómo invocar la skill en la práctica
La skill está diseñada en torno a este patrón de comando:
/em:postmortem <event>
Una invocación débil sería:
/em:postmortem Q3 release slipped
Una invocación más sólida da al agente suficiente material para separar hechos, supuestos y 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.
Inputs que mejoran el uso de postmortem
Para obtener mejores resultados con postmortem, proporciona el resultado esperado, el resultado real, la cronología, las primeras señales de alerta, el impacto, las decisiones clave, las restricciones y lo que se sabía en ese momento. Incluye tanto evidencia cuantitativa como contexto humano: brecha de ingresos, número de defectos, cronograma de contratación, hito incumplido, impacto en clientes, responsables de decisión, cuellos de botella de aprobación y prioridades en conflicto.
Evita pedirle a la skill que “encuentre quién causó esto”. En su lugar, pídele que identifique condiciones del sistema: propiedad poco clara, rutas de escalamiento débiles, supuestos de planificación poco realistas, controles de calidad ausentes, conflictos de incentivos o visibilidad tardía del riesgo.
Flujo de trabajo sugerido para un resultado útil
Empieza con un resumen factual del evento y luego pide el primer borrador del postmortem. Revisa si la cadena de 5 Whys se detiene demasiado pronto o salta a una explicación conveniente. Después, itera con evidencia: “Pressure-test the root cause against the timeline,” “Separate controllable causes from external shocks,” o “Convert these lessons into a change register suitable for the next exec review.”
El mejor artefacto final suele incluir: definición del evento, resumen de impacto, factores contribuyentes, causas raíz, no-causas, decisiones que parecían razonables en su momento, cambios de sistema recomendados, responsables, plazos y métricas de verificación.
Preguntas frecuentes sobre postmortem skill
¿postmortem es adecuada para principiantes?
Sí, si el usuario puede proporcionar una descripción clara del evento. La estructura de la skill reduce la necesidad de conocer de antemano métodos formales de retrospectiva. Quienes estén empezando deberían preparar una cronología breve y la brecha entre resultado esperado y real antes de invocarla; de lo contrario, el modelo podría completar el contexto faltante con supuestos plausibles pero no verificados.
¿Cuándo no debería usar esta skill?
No la uses como evaluación de desempeño, herramienta disciplinaria, investigación legal o declaración pública sobre un incidente sin revisión humana. También encaja mal cuando el liderazgo solo quiere una narrativa pulida en lugar de un análisis causal incómodo. Si la organización no puede actuar sobre los hallazgos, un postmortem puede generar frustración en vez de mejora.
¿En qué se diferencia de una revisión de incidentes?
Una revisión de incidentes suele centrarse en fallos técnicos de servicio y recuperación operativa. Esta postmortem skill es más amplia: trimestres incumplidos, lanzamientos fallidos, malas contrataciones, oportunidades perdidas, fracasos de producto y decisiones de liderazgo están dentro de su alcance. Puede apoyar Quality Management, pero no sustituye documentación regulada de CAPA, auditoría o cumplimiento, salvo que sea adaptada por revisores cualificados.
¿La skill requiere un ecosistema específico?
No. La skill está en markdown simple y puede instalarse en un flujo de trabajo de skills compatible usando el comando anterior. Como no hay scripts ni activos externos, es portable entre contextos de negocio, producto, ingeniería y operaciones. La contrapartida es que no ingiere automáticamente dashboards, sistemas de tickets ni registros de incidentes; debes resumir o pegar la evidencia relevante.
Cómo mejorar postmortem skill
Dale a postmortem mejor material de partida
La forma más rápida de mejorar los resultados de postmortem es aportar un paquete compacto de evidencia. Incluye: objetivo, resultado real, cronología, puntos de decisión, señales pasadas por alto, restricciones, stakeholders, impacto e hipótesis existentes. Etiqueta con claridad las afirmaciones inciertas. Por ejemplo: “Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”
Vigila los modos de fallo habituales
El fallo más común es una causa raíz superficial, como “mala comunicación” o “falta de ownership”. Pídele al agente que baje un nivel más: ¿qué estructura hizo que fallara la comunicación? ¿Por qué no estaba clara la responsabilidad? ¿Por qué el proceso de planificación permitió esa ambigüedad? Otro modo de fallo es sobrerreaccionar con demasiados elementos de acción. Presiona para obtener menos cambios, pero con responsable claro, observables y con alta probabilidad de evitar que se repita el problema.
Convierte los hallazgos en un registro de cambios
Un buen registro de cambios debe nombrar el cambio, la causa raíz que aborda, el responsable, la fecha límite, la métrica de éxito y la cadencia de revisión. Para uso en Quality Management, añade tipo de control, método de verificación y evidencia requerida. Esto hace que el resultado de la skill sea más fácil de llevar a la práctica en revisiones de liderazgo, planificación trimestral, gobernanza de releases, cambios en procesos de contratación o programas de mejora continua.
Itera después de la primera respuesta
Después del primer borrador, haz preguntas de seguimiento específicas: “Which conclusions are evidence-backed versus inferred?”, “What would have prevented this without slowing the team unnecessarily?”, “What early warning metric should we add?”, o “Rewrite the change register for executive accountability.” La postmortem skill funciona mejor cuando se trata como un socio de investigación estructurada, no como un generador de informes de una sola pasada.
