incident-postmortem

Skill de Postmortem de Incidente

Este skill produce un documento completo de postmortem de incidente que sigue el formato estándar de la industria. El resultado aplica un enfoque sin culpables en todo el documento — brechas del sistema sobre fallos individuales — e impulsa hacia ítems de acción específicos y cerrables en lugar de compromisos de proceso vagos.

¿No es exactamente esto? Usa agent-incident-postmortem cuando un agente de IA causó el incidente (uso desenfrenado de herramientas, una alucinación enviada).

Propone Acciones

Los ítems de acción no tienen que quedarse en la página: pásalos a action-runner, que los vista previa (dry-run, valorados por riesgo), ejecuta solo lo que apruebas a través del MCP de acción conectado, y registra lo que se hizo en el brain. Típico: crear un issue de seguimiento por ítem de acción (🟡), asignado a su propietario con una fecha de vencimiento. Este skill propone; action-runner controla y ejecuta — nunca en silencio.

Dónde se ubica esto — convertir un incidente en soluciones

Tercero en la columna vertebral de respuesta ante incidentes: /slo-error-budget (marco) → /debugging-log-analyser → incident-postmortem → /oncall-runbook. Recibe el diagnóstico de causa raíz de /debugging-log-analyser (léelo en lugar de re-diagnosticar) y entrega a /oncall-runbook los factores contribuyentes e ítems de acción priorizados — y el presupuesto de error de /slo-error-budget decide cuán urgentes son esas acciones. Sin culpables, causa raíz vs factores contribuyentes e ítem de acción se definen una sola vez en docs/craft/incident-response.md; ser sin culpables es la regla que carga el peso.

El bucle

Un postmortem falla en el momento en que asigna culpa — los datos honestos se secan y cada incidente futuro es reportado insuficientemente. La Fase 1 establece ese marco; todo depende de ello.

1. Establece el enfoque sin culpables primero. Establece claramente que esto examina el sistema que permitió que una persona competente tome esa acción, nunca la persona. Esto no es educación — es la precondición para la cronología veraz que el resto del skill necesita. Hecho cuando: el enfoque es explícito y ninguna oración en el documento culpa a un individuo; los fallos se atribuyen a brechas del sistema.
2. Construye la cronología a partir de evidencia. Reconstruye inicio → detección → mitigación → resolución con timestamps reales (del diagnóstico y logs, no de la memoria). Detección, mitigación y resolución son eventos distintos — rastrea cada uno. Hecho cuando: la cronología tiene timestamps reales y separa detección/mitigación/ resolución, y el impacto está cuantificado (usuarios, duración, alcance).
3. Encuentra la causa raíz Y los factores contribuyentes. La causa raíz es una sola cosa; los factores contribuyentes son lo que permitió que llegue a los usuarios y persista (la alerta perdida, el canary saltado, el runbook poco claro). Un postmortem con causa raíz y sin factores contribuyentes no ha buscado lo suficientemente. Hecho cuando: al menos se nombren los factores contribuyentes que cargan peso, cada uno apuntando a una brecha del sistema que es reparable.
4. Impulsa hacia ítems de acción con propietario y fecha — gobernados por el presupuesto. Convierte factores en ítems de acción específicos, cada uno con propietario y fecha; los ítems vagas como "mejorar monitoreo" se deterioran. Priorízalos contra el presupuesto de error (gastado → ahora; saludable → pronto). Hecho cuando: cada ítem de acción tiene propietario y fecha, y /oncall-runbook podría convertir los aprendizajes de detección/mitigación en una entrada sin re-analizar el incidente.