La mayoría de los equipos obtiene reportes de su asistente de IA igual que de un colega: alguien se acuerda de pedirlos. La respuesta depende de quién preguntó, de qué se acordó de incluir y de cuánta paciencia tuvo el modelo esa tarde. La semana siguiente el formato es otro, los números no se pueden comparar y nadie sabe qué cambió.
Operamos un agente de IA en producción para un grupo universitario y necesitábamos lo contrario: las mismas preguntas, hechas de la misma forma, a la misma hora, con respuestas comparables semana con semana. Esta es la práctica en la que nos quedamos. Es pequeña, y eso es lo importante.
La idea en una frase
Registrar el prompt como archivo en el repositorio, correrlo programado, elegir el modelo y el esfuerzo según el tipo de trabajo que hace el prompt, y publicar el resultado en un enlace estable con las versiones anteriores archivadas detrás.
Cada palabra de esa frase carga peso, así que voy una por una.
Registrar el prompt
Un reporte que vive en la cabeza de alguien no es un reporte, es un hábito que se va con la persona. Cada uno lo guardamos como un archivo prompt-*.md en el repositorio, con un frontmatter corto que declara para qué sirve y cómo corre:
id: prompt-corte-de-trabajo
tipo: reporte
cadencia: martes y jueves, 17:30 hora local
cron: 30 17 * * 2,4
zona_horaria: America/Mexico_City
modelo: Opus
esfuerzo: xhigh
audiencia: el grupo del proyecto, negocio y equipo técnico; lenguaje simple, sin jerga interna
fuentes: Azure DevOps (PRs, builds), Jira (tickets), centro de pruebas (veredictos, bugs), cortes anteriores
salida: notes/cortes/YYYY-MM-DD-corte.md con número de versión
destino: la página estable de Notion, publicada después de que una persona la lee
contrato: el documento que fija intención y formato
dueño: una persona
Debajo del frontmatter va el cuerpo: qué medir, en qué orden y cómo redactar. Dos reglas hacen casi todo el trabajo. Medir, no recordar: cada cifra sale de un sistema vivo y declara su ventana de tiempo; una fuente que no respondió se reporta como tal, nunca como cero. Escribir la nota y detenerse: el prompt nunca publica solo. Una persona lee la nota primero.
Correrlo programado
Dentro de Claude Code, un /loop resuelve lo recurrente dentro de una sesión y una tarea calendarizada resuelve la cadencia real: martes y jueves al final del día, o lunes temprano para el semanal. La tarea abre el archivo del prompt y lo ejecuta tal cual. La salida es un archivo nuevo con el número de versión siguiente. Una versión publicada nunca se edita; se publica la siguiente.
Mientras el equipo no tiene una máquina siempre encendida, una persona dispara la corrida y revisa la nota. Cuando la máquina exista, la corrida y la publicación se vuelven automáticas y la revisión pasa a los comentarios de la página publicada. El prompt no cambia; solo cambia quién aprieta el botón.
Elegir el modelo por el tipo de trabajo
Esta fue la parte que más nos costó decir con claridad. No todo reporte merece el modelo más caro, y algunos merecen más de una pasada. La regla que usamos:
| Tipo de trabajo | Modelo y esfuerzo |
|---|---|
| Acción programática o agéntica: corre pruebas, mide sistemas vivos, escribe notas, publica | Opus en esfuerzo alto o máximo |
| Documentar o inspeccionar sin generar acciones | Sonnet en esfuerzo alto |
| Complejo, con incertidumbre o urgencia | El mejor modelo disponible, en esfuerzo alto |
Un reporte que solo lee y redacta no necesita el modelo más caro. Uno que mide contra sistemas vivos y tiene que decidir qué entra al reporte, sí. Acertar aquí es lo que vuelve la práctica lo bastante barata para correrla dos veces por semana sin pensarlo.
Tres reportes que ya se pagan solos
Lo que nos frena. Martes y viernes. El prompt investiga qué detiene hoy al proyecto, articula cada bloqueo y nombra a quien puede quitarlo. Es el reporte que leen las personas que no leen nada más, porque es corto y cada línea trae un nombre.
El corte de trabajo. Martes y jueves al final del día. Qué aterrizó, qué sigue abierto y quién tiene la siguiente acción, en bloques numerados: merges y revisiones, tickets, un bloque por línea de producto, servicios, las herramientas internas y, al final, qué pedimos y a quién. La plantilla está abajo.
El estado completo. Una vez por semana, listo para el lunes. Un veredicto al frente (¿ya puede ir a producción? y si no, qué frentes se movieron), una tabla de qué corre dónde y desde cuándo, qué cambió en la ventana por repositorio, y el rastro de los hallazgos anteriores con su estado actual. Cuatro páginas, casi todo tablas, cada cifra con su fuente y fecha.
Publicar en un enlace, conservar las versiones
La última pieza es la que cambió cómo lee el equipo. Cada reporte tiene exactamente una página en Notion. Su cuerpo se reemplaza con la versión vigente; una cabecera dice qué versión es, qué ventana cubre, cuándo se actualizó y qué prompt la produjo; y las versiones anteriores quedan debajo como subpáginas nombradas por versión y ventana. El enlace en los marcadores de todos nunca cambia. Notion conserva además su propio historial de página, así que nada se pierde aunque se corrija algo en el lugar.
Junto a las páginas hay una pequeña base de datos que llamamos el registro de rutinas: una fila por rutina, con su tipo, estado (activa, pausada, propuesta, retirada), cadencia y cron, modelo y esfuerzo, fuentes, las rutas de su prompt, contrato y salida, su enlace de destino, la versión vigente, la última y la próxima corrida, el dueño y el ticket. Un monitor puede leer esa tabla para saber qué debería estar corriendo y qué se detuvo en silencio.
Plantillas para copiar
Todo lo de abajo es un archivo Markdown que puedes soltar en un repositorio o importar a Notion:
- El contrato del prompt, el frontmatter y las reglas del cuerpo descritas arriba.
- La plantilla del corte de trabajo, siete bloques y la frase con la que termina cada uno.
- La plantilla del reporte de bloqueos, corta a propósito.
- La plantilla del estado completo, veredicto primero, luego tablas.
- El esquema del registro de rutinas, las columnas de la base de datos y para qué sirve cada una.
El skill, empaquetado para Claude Code
Todo lo de arriba también es un skill de Claude Code, en el formato oficial de skills: un SKILL.md con los pasos para crear un reporte y publicar una versión, un reference.md con la práctica completa, las diez plantillas en inglés y español, y el script publicador.
- Descarga la carpeta del skill (zip; Python de biblioteca estándar).
- Lee el SKILL.md antes de instalarlo.
Se instala copiando la carpeta a tu repositorio en .claude/skills/scheduled-reporting/. Después, /scheduled-reporting <nombre> <cadencia> te lleva por el montaje, y el mismo skill publica las versiones. El publicador necesita un token de integración de Notion con acceso a tu página hub.
Empieza con un reporte. Córrelo a mano dos veces para que el formato se asiente. Después prográmalo, y deja que el registro te diga cuándo se detuvo.