Un prompt de postmortem sin culpas que no se queda en el primer error humano

La mayoría de los postmortems mueren en el primer error humano. Alguien corrió la migración equivocada, el doc dice "causa raíz: el ingeniero aplicó el cambio en prod", aparece una acción que dice "tener más cuidado con los ambientes" y todos siguen con sus vidas, hasta que el mismísimo incidente vuelve a pasar, porque en el sistema no cambió nada. Un postmortem sin culpas no va de ser amable. Va de no parar el análisis en la persona más obvia y de no entregar un arreglo que solo funciona si los humanos nunca vuelven a equivocarse. Este recurso es un prompt para copiar y pegar que hace cumplir las dos cosas. Al final te llevas la plantilla completa, cómo adaptarla a la forma en que tu equipo revisa los incidentes, las variables que vale la pena ajustar, cuatro variantes para distintos tipos de incidente y las formas concretas en que falla, para que las cojas antes de que terminen produciendo un reporte malo.

01 · El prompt

Aquí está completo. Pégalo en Claude Code, en un prompt guardado o en el chat, y luego pega tu línea de tiempo cruda al final, donde te lo indica.

You are drafting a BLAMELESS postmortem from the raw incident timeline below.

NON-NEGOTIABLE RULES
- Blameless means: describe systems, decisions, and conditions — never name
  an individual as "the cause". "An on-call engineer ran X" is fine as a fact;
  "the engineer caused the outage" is not. The system that let X reach prod
  is the cause.
- Keep every timestamp from the input VERBATIM and reason from the ordering.
  Do NOT compress or paraphrase the timeline into a summary.
- Root Cause: ask "why did that happen?" repeatedly (at least 5 times) until
  you reach a PROCESS or SYSTEM gap, not a person and not "human error".
  "Human error" is never an acceptable root cause — keep going.

SECTIONS (in this order)
1. Summary — 2-3 sentences: what broke, when, for how long.
2. Impact — who was affected and HOW MUCH (users, requests, revenue, data),
   in concrete numbers if the timeline gives them. If a number is unknown,
   write "unknown" — do NOT invent it.
3. Timeline — the verbatim timestamps, each with what happened and what was
   known at that moment (not what we know now in hindsight).
4. Root Cause — the system/process gap reached via the why-chain above.
   Show the chain briefly so the reasoning is auditable.
5. Contributing Factors — conditions that made it worse or slower to detect
   (alert gaps, missing runbook, unclear ownership, recent changes).
6. What Went Well — the controls and decisions that limited the blast radius.
7. Action Items — see the gate below.

ACTION-ITEM GATE (apply to every item)
- Each action item must be: SPECIFIC, OWNED (a role or team), and a SYSTEM
  change — a guardrail, an automated check, a default, a permission boundary,
  a test, an alert. Add a rough priority (P1/P2/P3).
- REJECT any action item that is "be more careful", "add a reminder",
  "more training", "double-check next time", or anything that relies on a
  human being more vigilant. If you catch yourself writing one, replace it
  with the guardrail that would make the vigilance unnecessary.

OUTPUT
- Output the postmortem as Markdown with the section headings above.
- No preamble, no "Here is...". If the timeline is too thin to find a real
  root cause, say exactly what additional facts you need and stop.

RAW TIMELINE:
<paste timestamped events: time, what happened, what was observed>

Esa es la pieza central. Todo lo de abajo es para que se ajuste a tu equipo y para saber cuándo no confiar en ella.

02 · Por qué estas dos cláusulas sostienen todo el prompt

Dos instrucciones hacen casi todo el trabajo. El resto es estructura.

La primera es la cadena de porqués hasta la falla de sistema. Si lo dejas solo, el modelo, igual que un humano cansado, se queda en la causa inmediata, porque la causa inmediata es lo más fácil de ver. "El deploy falló porque el ingeniero se saltó el paso de staging." Cierto, e inútil. La instrucción de preguntar "por qué" al menos cinco veces lo obliga a seguir: ¿por qué era siquiera posible saltarse staging? Porque el script de deploy no verifica el ambiente destino. ¿Por qué no lo verifica? Porque ese chequeo nunca se agregó. Ahora sí tienes una causa raíz que de verdad puedes arreglar con código, y no una frase echándole la culpa a una persona.

La segunda es el filtro de acciones. Esta es la línea que justifica el prompt entero: descarta el "tener más cuidado", el "agregar un recordatorio" y el "más capacitación". Estar atento no es un control. Un control es algo que aguanta aunque el humano esté cansado, distraído o recién llegado. Si tu única defensa contra borrar prod es acordarte de no hacerlo, no tienes defensa. El filtro fuerza cada acción a tener forma de barrera: un límite de permisos, un chequeo automático, un default que falla del lado seguro.

03 · Cómo adaptarlo a tu equipo

El prompt funciona tal cual, pero hay tres ajustes que lo hacen calzar con cómo tu organización revisa de verdad los incidentes.

Primero, el conjunto de secciones. Las siete secciones de aquí son un buen punto de partida, pero si tu equipo usa una plantilla fija (hay quienes ponen "Detección", "Respuesta" y "Recuperación" como secciones aparte, o exigen un bloque de "Lecciones Aprendidas"), reemplaza la lista de SECTIONS por la tuya, tal cual. El modelo sigue una estructura explícita mucho mejor que una implícita.

Segundo, las unidades de impacto. La línea "users, requests, revenue, data" le dice al modelo qué cuantificar. Cámbiala por las métricas con las que de verdad miden tus incidentes: tasa de error, latencia p99, tenants afectados, minutos de SLA quemados. Si llevas un error budget, agrega "state how much error budget this consumed". La cláusula "write 'unknown', do NOT invent it" es la que más importa aquí: un número de impacto inventado es peor que admitir que no lo sabes.

Tercero, el vocabulario de ownership. "OWNED (a role or team)" mantiene las acciones asignables. Si asignas por nombre de equipo, dile que use los nombres reales de tus equipos. Si usas un sistema de tickets, agrega "format each action item so it can be pasted as a ticket: title, owner, priority".

Dónde correrlo

• Justo después del incidente, como primer borrador. Es lo más honesto. La memoria y los logs del canal están más frescos en las horas posteriores a la resolución; redacta ahora, afina en la reunión de revisión.
• Como comando de Claude Code. Un "/postmortem" que lee una línea de tiempo pegada o exportada e imprime el borrador. Lo más rápido para el on-call al que le toca escribirlo.
• Nunca como la última palabra. El borrador es un insumo de la revisión, no su resultado. La gente que estuvo ahí va a notar algún factor que contribuyó y que el modelo no tenía forma de conocer.

04 · Las variables que puedes ajustar

Piensa en el prompt como un puñado de perillas. Estas son las que vale la pena mover.

1. Cantidad de porqués. "At least 5" es la profundidad clásica de los cinco porqués y un buen mínimo. Para una falla distribuida enredada, súbela; para un typo de config de una línea, la cadena puede tocar fondo de forma legítima en tres. Déjala así, en vez de forzar un quinto porqué inventado.
2. Conjunto de secciones. Que coincida exacto con la plantilla de tu equipo, como ya dijimos. Es el cambio de mayor impacto si tu organización tiene un formato fijo.
3. Métricas de impacto. Hazlas tuyas: minutos de SLA, tenants afectados, error budget, dólares. Y conserva la cláusula que evita que invente.
4. Tono de la línea de tiempo. Agrega "preserve the operator's words from the channel where useful" si quieres conservar la voz humana de la respuesta, o "neutral past tense throughout" si tu plantilla exige un pasado neutral.
5. Protección contra el hindsight. La cláusula "what was known at that moment (not what we know now in hindsight)" vale la pena dejarla tal cual: es lo que evita que la línea de tiempo se lea como si todos hubieran tenido que verlo venir. Refuérzala si tus revisiones tienden a caer en el sesgo retrospectivo.

05 · Variantes

Cuatro reescrituras listas para usar según el tipo de incidente. Cada una ajusta una parte del prompt base.

Incidente de seguridad. Cuando el incidente es una brecha, una exposición o un abuso, lo de no buscar culpables se mantiene y el filtro de acciones se vuelve más exigente. Agrega a las RULES:

This is a SECURITY incident. Add two sections after Root Cause:
- "Containment & Eradication" — what stopped the bleeding and removed access.
- "Detection Gap" — why this wasn't caught sooner; what signal was missing.
Action items must include at least one DETECTION improvement and one
PREVENTION control. Do not name the attacker's specific exploit steps in
operational detail; describe the class of weakness and the fix.

Degradación que sienten los usuarios. Cuando los usuarios lo notaron y alguien tiene que comunicarlo hacia afuera, agrega:

Add a "Customer Communication" section: what was said, when, and through
which channel, versus when the impact actually started. Flag any gap
between impact-start and first customer comms as a contributing factor,
and add an action item to close that gap with a system (status-page
automation, an alert that pages comms), never with "remember to post".

Near-miss (todavía sin impacto). Para el incidente que casi pasa, atajado antes de que los usuarios lo notaran. Lo valioso es aprender sin la presión del daño real:

This is a NEAR-MISS: the failure was caught before customer impact.
Skip "Impact" (state "no customer impact — caught at <step>"). Emphasize
"What Went Well" (the control that caught it) and treat the root cause
with the SAME rigor as a full incident — a near-miss is a free lesson,
not a non-event. Action items: harden the control that caught it AND fix
the gap that nearly let it through.

Falla distribuida entre varios servicios. Cuando el incidente cruzó varios servicios y ninguna línea de tiempo por sí sola cuenta la historia completa, pásale los logs combinados y usa:

This incident spanned multiple services. In the Timeline, tag each event
with the service it occurred in. In Root Cause, distinguish the TRIGGER
(the first failing component) from the AMPLIFIERS (retries, missing
backpressure, cascading timeouts) that turned a local fault into a
system-wide one. Action items must address at least one amplifier, not
only the trigger — fixing the trigger alone leaves the blast radius intact.

06 · Detalles a cuidar y concesiones

Los modos de falla, dichos sin maquillaje, para que un mal borrador no se te cuele en el registro.

• Va a comprimir la línea de tiempo si lo dejas. Es la falla más común y la que rompe el análisis sin que lo notes: el modelo resume "pasaron varios deploys" y pierde el orden de los hechos, que es la causa. La regla "keep timestamps verbatim" pelea contra esto, pero en una línea de tiempo larga revisa que cada marca de tiempo original haya sobrevivido en el borrador antes de confiar en la causa raíz.
• Una línea de tiempo pobre produce una causa raíz segura pero hueca. Si le pasas cinco líneas vagas, igual te va a soltar una causa raíz de aspecto prolijo, pero será pura adivinanza. La cláusula "say what facts you need and stop" existe para evitar esto; respétala. Línea de tiempo basura entra, ficción creíble sale.
• No puede saber lo que no le contaste. El modelo solo ve la línea de tiempo que pegas. El factor que más pesó, como que el on-call estaba además atendiendo un segundo incidente o que el runbook llevaba tres versiones desactualizado, no va a aparecer a menos que esté en el input. La reunión de revisión es donde los humanos agregan lo que el log no pudo.
• Lo de no buscar culpables puede pasarse de vago. Si lo empujas demasiado hacia "nada de individuos", la prosa puede volverse tan abstracta que deja de servir ("un sistema permitió un cambio"). Sin culpas significa no culpar a una persona, no no contar qué pasó. Conserva el hecho "un ingeniero on-call corrió X"; quita solo el juicio de valor.

Sobre la elección del modelo: un postmortem es razonar sobre un conjunto ordenado de eventos para dar con una causa que no salta a la vista, así que vale un modelo capaz y algo de presupuesto de thinking. No lo corras en la gama más barata. Si llamas a la API directo en vez de usar Claude Code, claude-sonnet-4-6 con un presupuesto de thinking moderado es el punto justo; échale mano a claude-opus-4-8 en una falla distribuida de verdad enredada, donde la cadena de porqués es profunda. Activa el adaptive thinking aquí. A diferencia de un mensaje de commit, sí quieres que se tome su tiempo con el orden de los hechos antes de comprometerse con una causa raíz.

Un buen prompt de postmortem no va a escribir la verdad por ti. La gente que estuvo ahí todavía tiene que hacerlo. Lo que hace es cerrarle la puerta a los dos finales perezosos que hacen que los incidentes se repitan: quedarse en el primer error humano y entregar un arreglo que solo funciona si nadie vuelve a equivocarse. Móntalo como un comando de primer borrador, mantén una revisión humana después y deja que el filtro haga su único y testarudo trabajo.