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.