Qué hace este prompt
Le pegas notas desordenadas con fechas dispersas y el LLM te devuelve una cronología limpia, ordenada, con timestamps normalizados a una zona horaria común, y señalando lagunas e inconsistencias.
Es la herramienta de síntesis temporal por excelencia para investigación: transforma caos en línea de tiempo utilizable en minutos.
Cuándo usarlo
- Reconstruir la secuencia de un incidente a partir de logs dispersos
- Convertir un chat de WhatsApp largo en cronología de decisiones
- Ordenar notas de campo tomadas sin orden estricto
- Preparar timeline para informe periodístico
- Correlacionar eventos en distintas zonas horarias
El prompt
Eres un analista de datos especializado en cronologías. Convierte las notas siguientes en una cronología estructurada.
Requisitos de salida:
1. Ordena todos los eventos cronológicamente (más antiguo → más reciente)
2. Normaliza timestamps al formato ISO 8601 (YYYY-MM-DD HH:MM UTC)
3. Si el evento original venía en otra zona horaria, indícalo entre paréntesis: "2024-03-15 14:00 UTC (16:00 CEST)"
4. Cada evento en una línea: TIMESTAMP → descripción breve del evento
5. Al final añade:
- "Rango total": desde X hasta Y (duración)
- "Actores implicados": lista de personas/entidades mencionadas
- "Lagunas detectadas": periodos vacíos anómalos (>24h sin eventos si el resto es más denso)
- "Inconsistencias": contradicciones detectadas (fecha que no encaja con secuencia narrativa)
Reglas:
- Zona por defecto: UTC (o la zona que te pida el usuario)
- Fechas relativas ("ayer", "hace 3 días"): tradúcelas asumiendo referencia = fecha más reciente del texto
- Si una fecha es ambigua (03/04/2024 = 3 abril o 4 marzo), marca con [?]
- No inventes eventos que no aparecen literalmente
- No inventes precisión que no está: si solo dice "en marzo", pon "2024-03-?? HH:MM UTC"
NOTAS ORIGINALES:
<<<
[PEGA_AQUI_TUS_NOTAS_DESORDENADAS]
>>> Ejemplo real
Recibí el email de Sofía sobre el proyecto el jueves a las 14:00. Un día antes, había hablado con David por teléfono a las 10 de la mañana. El lunes de esa semana (11 de marzo de 2024) empezamos la fase de análisis. Sofía envió el borrador el viernes 15 pero tuvo que reenviarlo el sábado porque el primero se corrompió.
Cronología (referencia: marzo 2024, zona UTC salvo indicación): 2024-03-11 ??:?? UTC → Inicio de la fase de análisis del proyecto 2024-03-13 09:00 UTC (aprox. 10:00 CET) → Llamada telefónica con David 2024-03-14 13:00 UTC (14:00 CET) → Email recibido de Sofía sobre el proyecto 2024-03-15 ??:?? UTC → Sofía envía el borrador (primer envío) 2024-03-16 ??:?? UTC → Sofía reenvía el borrador (el primero se corrompió) Rango total: 5 días (11 al 16 de marzo 2024) Actores: Sofía (envío borrador), David (llamada), usuario (recepción) Lagunas detectadas: gap de 2 días entre 11-mar (inicio análisis) y 13-mar (llamada David) Inconsistencias: ninguna aparente
Variantes útiles
- En formato Mermaid o timeline JS: añade "Devuelve también un bloque Mermaid con la sintaxis timeline". Útil para pegar en Notion u Obsidian con diagrama visual.
- Filtrado por actor: cambia "Ordena todos los eventos" por "Ordena solo los eventos donde interviene [NOMBRE]".
- Agrupado por día: para cronologías largas, cambia a "Agrupa por día como cabecera y lista eventos dentro".
Cuándo NO usarlo
- Cuando la precisión de segundos es crítica (forense digital). El LLM redondea. Para milisegundos exactos usa scripts que parseen los timestamps del log crudo.
- Logs de servidor con miles de líneas. Para bulk parsing usa awk/sed/journalctl. Los LLMs son para síntesis narrativa, no para procesar millones de líneas idénticas.
- Casos legales con implicaciones penales. Cualquier cronología presentada como prueba debe generarse con herramientas auditables y reproducibles, no con un LLM.