name: incident-response description: > Respuesta estructurada ante incidentes criticos detectados en el sistema. Usa este skill cuando se detecte una alerta urgente, un hallazgo CRITICAL en health-audit, un mensaje de bus con priority=urgent, o cualquier situacion que requiera investigacion y mitigacion inmediata. Tambien aplica cuando se mencionen "servicio caido", "data loss", "incidente", "produccion rota", "alerta critica", "SEV1", "SEV2", "respuesta a incidente", o cualquier escenario que requiera recopilar evidencia, clasificar severidad, y ejecutar mitigaciones automaticas.

Incident Response

Ejecuta una respuesta estructurada ante incidentes criticos: recopila evidencia, clasifica severidad, formula hipotesis de causa raiz, y ejecuta mitigaciones Tier 1 de forma automatica.

Inputs requeridos

Proceso

1. Recopilacion de evidencia (paralelo)

Ejecuta estas 4 tareas simultaneamente para minimizar tiempo de respuesta:

• Logs recientes: ultimos 30 minutos de logs relevantes al servicio afectado.
• Health de servicios: estado actual de todos los endpoints (status code, latencia, disponibilidad).
• Ultimos 3 deploys/commits: git log --oneline -3 para identificar cambios recientes que puedan correlacionar.
• Cron jobs activos: estado de tareas programadas y su ultimo resultado de ejecucion.

2. Construccion de timeline

Ordena cronologicamente todos los eventos recopilados que condujeron al incidente:

• Cada entrada del timeline debe tener timestamp exacto y fuente verificable.
• Incluye: cambios de estado, errores en logs, deploys, ejecuciones de cron, mensajes de bus.
• Minimo 3 data points reales (de logs/eventos, no hipoteticos).

3. Clasificacion de severidad

Reglas:

• Si hay duda entre SEV1 y SEV2, clasificar como SEV1.
• Data loss confirmado o potencial siempre es SEV1.
• Degradacion que afecta revenue es SEV1, no SEV2.

4. Hipotesis de causa raiz

Formula al menos 1 hipotesis de causa raiz con:

• Descripcion clara de la causa propuesta.
• Evidencia que la soporta (log lines especificos, timestamps, correlaciones).
• Nivel de confianza: low, medium, o high.

Si hay multiples hipotesis, listarlas ordenadas por confianza descendente.

5. Auto-ejecucion de mitigaciones Tier 1

Ejecutar automaticamente (sin aprobacion) acciones de bajo riesgo:

• Reiniciar cron jobs fallidos.
• Limpiar locks stale (~/.claw/locks/).
• Reintentar requests fallidos (maximo 1 reintento).
• Registrar cada accion y su resultado.

Limite de tiempo: todas las mitigaciones Tier 1 deben intentarse dentro de 2 minutos de la deteccion.

6. Runbook para acciones Tier 2/3

Para acciones que requieren aprobacion, generar un runbook con:

• Descripcion de la accion.
• Justificacion de por que es necesaria.
• Nivel de riesgo (medium o high).
• Pasos exactos para ejecutar.
• Como verificar que funciono.

Output format

Incident Report

Severity: SEV{1|2|3} Status: {investigating|mitigating|resolved} Detected: {timestamp} Duration: {ongoing o resolved at timestamp}

Timeline

• {timestamp}: {evento} — fuente: {log/deploy/cron/bus}
• {timestamp}: {evento} — fuente: {log/deploy/cron/bus}
• {timestamp}: {evento} — fuente: {log/deploy/cron/bus}

Root Cause

Hypothesis: {descripcion} Evidence: {datos que la soportan — log lines, timestamps, correlaciones} Confidence: {low|medium|high}

Actions Taken (Tier 1 — auto-executed)

• {accion}: {resultado}

Actions Pending (require approval)

• {accion}: {por que es necesaria} — Risk: {low|medium|high}

Notification

{a quien se notifico y cuando}

Done criteria

• El timeline tiene al menos 3 data points de logs/eventos reales (no hipoteticos).
• Hay al menos 1 hipotesis de causa raiz con evidencia concreta.
• Todas las mitigaciones Tier 1 se intentaron dentro de 2 minutos de la deteccion.
• SEV1 disparo notificacion inmediata via Telegram a Hector (via bus a Alma).
• Las acciones pendientes tienen labels de riesgo claros.
• Cada entrada del timeline tiene timestamp exacto y fuente identificada.

Errores comunes a evitar

• No inventes datos para el timeline: si no tienes evidencia, no la incluyas. "Posiblemente fallo a las 14:00" no es un data point.
• No subestimes severidad: si un servicio esta degradado y afecta usuarios, es SEV1 o SEV2, no SEV3.
• No ejecutes acciones Tier 2/3 sin aprobacion: reiniciar un servicio es Tier 1, pero hacer rollback de un deploy es Tier 2.
• No ignores la correlacion temporal: si hubo un deploy 5 minutos antes del incidente, es evidencia relevante aunque no sea la causa.
• No olvides notificar: SEV1 sin notificacion es una falla del proceso, no solo del sistema.