Mi entrenador de running es un repositorio Git y un agente Claude

Termino mi sesión. Mi reloj se sincroniza solo con Strava, como siempre. Me voy a la ducha.

Cuando salgo, tres cosas han ocurrido sin que yo tocara nada. El análisis de la sesión está escrito en mi repositorio de entrenamiento. La semana ha sido reajustada, con el motivo del cambio anotado al lado. Y bajo la actividad de Strava hay un comentario de mi entrenador, que me dice cuánto vale la sesión y qué cambia para el viernes.

Ese entrenador no es una aplicación que yo haya desarrollado. Es un repositorio Git de archivos Markdown, una suscripción a Claude y AgentsRoom sujetándolo todo. Ningún servidor escrito, ninguna factura por token, más o menos un fin de semana de montaje.

Todo está publicado como plantilla: github.com/AgentsRoomDev/running-performance-coach. Puedes clonarlo y hacerlo tuyo rellenando los huecos. Este artículo explica cómo funciona, pieza por pieza, dando por hecho que has oído la palabra "API" pero nunca has escrito un webhook.

Para situarnos: llevo mucho tiempo corriendo, 2h47 en maratón, 1h13:59 en media y 33:45 en 10 km. El objetivo del ciclo actual es volver a bajar de 34 minutos en 10 km. Eso importa para lo que viene: un entrenador genérico que me vuelva a explicar qué es una sesión de umbral no me sirve de nada, y ese es exactamente el problema que resuelve este montaje.

Lo que pasa entre el final de mi carrera y el comentario

La cadena completa son seis pasos:

1. Mi reloj envía la actividad a Strava. Esa parte ya ocurre para todo el mundo.
2. Cada 15 minutos, un pequeño script Python le pregunta a Strava si hay algo nuevo.
3. Cuando encuentra una sesión nueva, fabrica una ficha de sesión Markdown en mi repositorio: vueltas, parciales, volumen, frecuencia cardiaca. Solo datos medidos.
4. También reescribe el título y la descripción de la actividad en Strava, para que mi feed deje de poner "Carrera por la tarde".
5. Después envía un mensaje firmado a AgentsRoom, que abre un agente Claude con la sesión ya en la mano.
6. Ese agente hace el trabajo de entrenador: lee, compara, escribe el análisis, ajusta la semana, hace commit, hace push, comenta en Strava y me manda el informe largo por correo.

Los cinco primeros pasos son fontanería. El sexto es de lo que va este artículo.

El cuaderno de entrenamiento es un repositorio Git, no una base de datos

Esta es la decisión que lo cambia todo, y también la que más sorprende a la gente.

Una sesión = un archivo, journal/2026/2026-09-03.md. Una semana = un archivo, plan/weeks/2026-W36.md. Un cambio de plan = un commit, con su motivo en el mensaje. No hay base de datos, ni esquema, ni migración, ni interfaz.

Tres consecuencias, por orden de importancia:

El entrenador puede releer su propia historia. Sabe lo que prescribió hace tres semanas y puede comprobar si funcionó. Un chatbot al que le cuentas tu sesión arranca de cero en cada conversación. Un agente que tiene un repositorio tiene memoria, y esa memoria la puede leer un humano.

Leo mi plan en el móvil, en la app de GitHub. El README.md del repositorio no es una página de presentación: es mi panel de control. El contrato escrito en CLAUDE.md es explícito al respecto, ninguna planificación está terminada mientras el README no la refleje. El resultado: no tengo ninguna interfaz que mantener y, aun así, tengo una pantalla que me dice qué toca hoy.

Nada es irreversible. Todo lo que el agente escribe es un commit. Puedo leerlo, discutirlo, revertirlo. Eso es muy distinto de una aplicación que decide por su cuenta.

Paso 1: Strava despierta a un pequeño script

Strava expone una API: una forma, para un programa, de pedir "dame las actividades recientes de este atleta". El script strava_sync.py hace exactamente eso y convierte la respuesta en una ficha de sesión.

La parte interesante no es la llamada de red, es la reconstrucción. Un reloj registra vueltas en bruto. El script tiene que deducir qué sesión era:

Lap 1  : 4.40 km in 26'07 (5:56/km)   ← calentamiento
Lap 2  : 1.00 km in 3'41  (3:41/km)   ← repetición 1
Lap 3  : 0.20 km in 1'59  (9:55/km)   ← recuperación
...                                     → "5 x 1000m r' 2'"

Prueba todos los cortes de la forma "las k vueltas más rápidas son las repeticiones" y se queda con el mejor que se sostiene. Suena trivial y no lo es: un agrupamiento ingenuo por velocidad cae en la trampa en cuanto un calentamiento es más rápido que una recuperación.

Sobre todo, la forma de la sesión se reconstruye desde el reloj, nunca desde el plan. Es tentador hacer lo contrario (el plan dice 5 x 1000m, pues se escribe eso) y es exactamente el error: toda la gracia está en detectar los días en los que hice otra cosa. Cuando los dos no coinciden, esa discrepancia es la información, y el entrenador la ve:

Previsto 3 x 8' → corrido en continuo

Dos avisos antes de que empieces.

La API de Strava exige una suscripción de desarrollador de pago desde junio de 2026. Sin ella, cada llamada responde 403 Application Status Inactive. La alternativa existe y viene prevista en la plantilla: exportar un archivo TCX desde tu reloj y pasárselo a import_tcx.py. Todo lo que está aguas abajo de la importación funciona igual.

Las cuotas son amplias, pero reales. En mi aplicación, 300 peticiones cada 15 minutos y 3.000 al día en lectura. El script consume una por pasada en régimen estable, o sea 96 al día. Estamos lejísimos del techo, pero es de esas cosas que se comprueban antes, no después.

Paso 2: el script despierta al agente, con una firma

Aquí es donde la cosa se pone interesante.

Un webhook es lo contrario de una pregunta. En vez de preguntar cada cinco minutos si hay algo nuevo, le das una dirección web a un programa y es él quien te envía un mensaje cuando ocurre el evento. No pagas nada mientras no pase nada.

AgentsRoom expone exactamente eso: un disparador webhook. Creas un disparador en la aplicación y ella te devuelve una URL y un secreto. Cualquiera que envíe un mensaje JSON a esa URL abre un agente, con el prompt que has escrito y el contenido del mensaje ya inyectado dentro.

El mensaje que envía mi script es deliberadamente minúsculo:

{
  "type": "created",
  "title": "03/09 · 5 x 1000m r' 2'",
  "body": "Sesión del 03/09/2026 importada desde Strava.\n\nSesión de calidad: 5 x 1000m r' 2'\nSplits: 3'41 - 3'40 - 3'38 - 3'40 - 3'35\n\nVolumen total: 12.51 km en 1h07'42 (5:25/km), D+ 56 m\nSesión prevista: RP10-5x1000\n\nFicha de sesión: journal/2026/2026-09-03.md\nFicha de semana: plan/weeks/2026-W36.md"
}

Fíjate en lo que no está ahí: el texto del plan. El webhook transporta el código de la sesión prevista y la ruta de las fichas, nunca su contenido. Un agente que tiene el repositorio irá a leerlas él mismo; un agente que no lo tiene no pinta nada recibiendo mis instrucciones internas. Es la misma regla que para las descripciones publicadas en Strava.

La firma, y la trampa que viene con ella

Una URL pública que abre un agente no puede quedarse abierta al primero que la encuentre. Así que el disparador va firmado: el script calcula una huella del mensaje con el secreto compartido (un HMAC-SHA256, si el término te dice algo) y la envía en la cabecera X-AgentsRoom-Signature. El servidor recalcula la misma huella por su lado; si no coinciden, rechaza.

Sin firma, la respuesta es tajante:

{"error":"REJECTED","message":"Signature missing."}

Y aquí viene la trampa, que me costó una tarde entera. La firma cubre los bytes exactos que salen por la red, no el objeto en memoria. Si firmas un archivo tal y como está en el disco y luego dejas que otra capa vuelva a serializar el objeto (un espacio de más, un orden de claves distinto, un acento escapado de otra manera), obtienes una firma perfectamente válida para un mensaje que el servidor no recibirá jamás. El rechazo es indepurable: todo parece correcto por los dos lados.

El arreglo cabe en una frase: se serializa y se firma en el mismo sitio. En la plantilla, la función post_json hace las dos cosas, y nada más tiene derecho a tocar el cuerpo del mensaje.

Paso 3: tres capas le dicen al entrenador quién es, cómo funcionan las cosas aquí y qué hacer ahora mismo

Un agente que entrena no es un prompt gigante. Son tres textos separados, y la separación importa.

Capa 1, la persona: quién es

Un prompt de sistema asociado al agente en AgentsRoom. Lleva la filosofía de entrenamiento y es deliberadamente genérico respecto al deporte: entrenaría a cualquiera.

Tu trabajo no es simplemente generar planes de entrenamiento. Entrenas al atleta de forma continua, analizando su entrenamiento, entendiendo su forma actual, adaptando las sesiones que vienen. […] Habla como un entrenador con experiencia, no como un chatbot motivacional.

También dice lo que no hace: no juzgar una sesión únicamente por si se mantuvo el ritmo objetivo, ser explícito sobre la incertidumbre de una predicción de marca y no validar un objetivo solo porque al atleta le apetezca. Esa última línea es la que hace útil al entrenador.

No tienes que escribirla tú: esta persona está publicada en el catálogo de agentes de AgentsRoom con el nombre Entrenador de Rendimiento en Carrera. Un clic la instala, lista para usar.

Capa 2, CLAUDE.md: cómo funcionan las cosas aquí

Este es el contrato, que se lee al principio de cada sesión. Contiene la estructura de archivos, las reglas que la mantienen coherente, los principios de entrenamiento que condicionan cualquier propuesta y, sobre todo, el ritual: la secuencia exacta que hay que desplegar cuando se reporta una sesión.

Un extracto, porque muestra el nivel de precisión:

Orden de sacrificio cuando la semana descarrila: primero los minutos de más en los rodajes, luego el trabajo de fuerza, luego la longitud de la tirada larga, luego una sesión de calidad. Nunca la semana entera.

Aquí es donde el entrenador deja de ser un chatbot. No improvisa un procedimiento cada vez, sigue el que escribí una sola vez. Si solo vas a leer un archivo del repositorio plantilla, lee ese.

Capa 3, el prompt del disparador: qué hacer ahora mismo

Es el mensaje que se le entrega al agente cuando aterriza una sesión. Recibe la actividad mediante variables de plantilla: {{event.title}}, {{event.body}}, {{event.url}}. Así el agente arranca con la sesión ya en la mano, en vez de tener que ir a buscarla.

Este es su esqueleto, tal y como está en el disparador:

Nueva sesión importada desde Strava.

**{{event.title}}** · actividad {{event.id}}
{{event.url}}

{{event.body}}

---

Estás en el repositorio `training-plan`. Lee `CLAUDE.md` primero: es la ley.
Escribes en mi idioma y me tuteas en todo momento (§3).

El ritual del §6 se aplica, pero su **paso 1 ya está hecho**: `strava_publish.py`
creó la ficha de sesión y la commiteó. Retomas en el paso 2 y llegas hasta el
final. Tres entregables, en este orden: **el análisis en el repositorio**,
**el comentario bajo la actividad de Strava**, **el correo**.

⚠️ **Estás ejecutándote sin supervisión: nadie leerá una pregunta.** No pidas
nunca un arbitraje: decides, actúas y dices en tu informe qué has zanjado y
por qué.

## 1 · Analizar y ajustar el plan (ritual §6, pasos 2 a 6)

1. `git pull --rebase` antes que nada: la ficha puede venir del servidor.
2. Lee, en este orden: la ficha de hoy, la ficha de la semana,
   `athlete/zones-and-paces.md`, y **las 3 últimas fichas de sesión**:
   una sesión nunca se juzga sola.
3. Escribe la sección `## Analysis`: **el veredicto primero**, luego las
   señales que lo sostienen, luego lo que cambia.
   ⛔ Si `## Analysis` ya está rellenada, no la reescribas.
4. Actualiza la ficha de la semana y deja constancia de **todo** cambio de
   plan bajo `## Adjustments`, con su motivo.
5. **Regenera el `README.md`**: es la pantalla que leo en el móvil.
6. Commit y push, rutas explícitas, ⛔ nunca `git add -A`.

## 2 · Kudos y comentario en Strava
   ⛔ Un comentario de Strava es PÚBLICO: nada de frecuencia cardiaca objetivo,
   nada de molestias, ningún arbitraje interno, ningún tiempo previsto.

## 3 · El informe completo por correo

La línea que más trabajo hace es la del medio: "nadie leerá una pregunta". Un agente que se ejecuta sin nadie delante de la pantalla y que pide un arbitraje no comete un error, simplemente se para, y te enteras al día siguiente.

Qué modelo, y por qué un millón de tokens no es un capricho

El contexto largo no es una coquetería. Para juzgar una sesión como es debido, el entrenador lee la ficha del día, la ficha de la semana, la tabla de ritmos de referencia y las tres sesiones anteriores. Una sesión nunca se juzga sola: la carga acumulada, el encadenamiento de los días y los puntos de vigilancia en curso cambian el veredicto por completo. Tres repeticiones a 3:38 al día siguiente de una tirada larga de dos horas no cuentan la misma historia que esos mismos 3:38 después de un día de descanso.

El modo autónomo no es dejadez, es una consecuencia: una ejecución sin nadie delante de la pantalla no tiene a nadie que apruebe un git push. Y el acceso al navegador es lo que permite al agente ir a comentar en Strava y enviar el correo, dos cosas que aquí no tienen una API cómoda.

Lo que está automatizado, y lo que deliberadamente no lo está

Esta es la decisión de diseño con la que estoy más contento, y es fácil que pase desapercibida.

El trabajo de importación registra y publica, nunca juzga.

Un script que se pusiera a juzgar produciría veredictos sin contexto, con una lógica congelada en código que nadie relee. Juzgar exige sostener a la vez la carga de la semana, la forma del momento y lo que se dijo la última vez: eso es trabajo de entrenador, y lo hace el agente, con todo el expediente delante.

El beneficio práctico es inmediato: cuando el agente no ha llegado a ejecutarse (máquina apagada, API caída), la ficha existe igualmente. No se pierde nada, solo falta el comentario, y basta con volver a lanzar el evento.

Otra decisión va en el mismo sentido: el script no guarda ningún archivo de estado para saber lo que ya ha tratado. Es la descripción en Strava la que da fe. Vacía, escribe; con su firma, pasa de largo; no vacía y sin firma, la has escrito tú y no la toca. Un archivo de estado local no habría podido decir nada de lo que hizo otra máquina; así, dos máquinas pueden funcionar en paralelo sin pisarse.

Dos reglas de separación más, grabadas en el repositorio y que no hay que sortear:

• la descripción publicada en Strava nunca copia el texto del plan: mi ficha de semana contiene frecuencias cardiacas objetivo y arbitrajes que no pintan nada en una actividad pública;
• una descripción escrita a mano nunca se sobrescribe.

El comentario que aterriza bajo la actividad

La gracia no es la autofelicitación. Es que el veredicto del entrenador se pueda leer desde el móvil, bajo la actividad, sin abrir el repositorio, y que se quede ahí, pegado a la sesión, para siempre.

Por eso el comentario es deliberadamente estrecho: un emoji de veredicto, el número que lo sostiene y lo que cambia para la próxima sesión. Unos 250 caracteres.

✅ Cinco repeticiones a 3'39 de media para un objetivo de 3'38-3'44, y el pulso plano en todo el bloque. La tabla de ritmos se sostiene. El viernes sigue en rodaje: te has gastado el margen de la semana.

La versión larga, la que lleva las frecuencias cardiacas, el punto de vigilancia que señalé y el arbitraje sobre el volumen de la semana que viene, se va al repositorio y al correo. Dos canales, dos públicos, y es el prompt el que sostiene la frontera.

Tres cosas que solo se rompen en producción

Cada una de estas líneas existe porque algo se rompió sin ella. Son más instructivas que el resto del artículo.

1. Fijar el navegador. Tengo dos extensiones de Claude conectadas en Chrome. Nada garantiza cuál le toca al agente, y solo una lleva la sesión de Strava. El resultado: una ejecución de cada dos, el agente acababa en el navegador equivocado, sin sesión iniciada, incapaz de comentar nada. Seleccionar el navegador por identificador de dispositivo no se conserva de una sesión a otra: por lo tanto tiene que estar en el prompt, con la prohibición explícita de ir a preguntarle al usuario cuál elegir. En modo automático, una pregunta es un bloqueo.

2. El campo de comentario de Strava no tiene maxlength. Nada, en el navegador, impide escribir demasiado largo: es el servidor el que rechaza al enviar. Un agente que redacta un bonito párrafo de 600 caracteres lo teclea entero, hace clic en "Publicar" y se lleva un fallo que no entiende. Así que el prompt tiene que imponer la brevedad antes de redactar, y prever el caso: si el envío falla, se acorta y se vuelve a publicar, nunca se parte en dos comentarios.

3. Un comentario de entrenador por actividad. Cuando vuelves a lanzar un evento para probar (cosa que haces mucho al principio), sin esta regla el agente apila comentarios en una actividad ya tratada. Por eso el prompt le hace leer la pestaña "Comentarios" antes de escribir, y pasar turno si ya está ahí. Misma lógica del lado del repositorio: si la sección ## Analysis ya está rellenada, no se reescribe.

Lo que cuesta esto

No hay ninguna clave de API facturada por token en este montaje. Es el punto que me parece más subestimado: lo mismo construido sobre una API de pago por uso tendría un contador girando en cada sesión, y probablemente no lo habría mantenido.

Móntalo este fin de semana

Los pasos, en orden. Cuenta con una tarde si ya tienes una cuenta de Strava y una suscripción a Claude.

1. Clonar la plantilla y hacerla tuya.

git clone https://github.com/AgentsRoomDev/running-performance-coach.git my-coach
cd my-coach
rm -rf .git && git init

Haz que tu copia sea privada. Un cuaderno de entrenamiento contiene datos de salud: frecuencia cardiaca, sueño, lesiones. La plantilla es pública, tu copia no debería serlo.

Después rellena, en este orden: athlete/profile.md (quién eres como corredor), athlete/records.md (tus marcas), athlete/constraints.md (los huecos de los que dispones de verdad), athlete/zones-and-paces.md (tus ritmos de referencia), plan/objective.md (la carrera y el objetivo), y luego CLAUDE.md, donde sustituyes cada hueco {{...}}.

Por último, abre el repositorio con tu agente Claude y dile: "lee CLAUDE.md y athlete/, y luego constrúyeme la primera semana."

2. Conectar Strava.

cp .env.example .env && chmod 600 .env
python3 scripts/strava_oauth.py     # un clic en el navegador, una sola vez
python3 scripts/strava_sync.py --dry-run

El --dry-run muestra lo que se escribiría sin escribir nada. Es el momento de comprobar que la reconstrucción de las sesiones te convence.

3. Crear el disparador en AgentsRoom. En Triggers, New trigger:

AgentsRoom fabrica una URL y un secreto de firma. Pon los dos en tu .env:

WEBHOOK_URL=https://agentsroom.dev/api/triggers/t_xxxxxxxxxxxx
WEBHOOK_SECRET=whsec_xxxxxxxxxxxxxxxxxxxxxxxx

4. Probarlo antes de fiarte de él.

python3 scripts/webhook_replay.py scripts/examples/webhook-session.json --dry-run
python3 scripts/webhook_replay.py scripts/examples/webhook-session.json

Esto vuelve a lanzar una sesión en el disparador sin esperar a tu próxima salida y sin tocar el estado del trabajo automático. Deberías ver ✅ HTTP 202, y debería abrirse una pestaña de agente en AgentsRoom.

5. Hacerlo funcionar cada 15 minutos.

bash scripts/systemd/install.sh          # en un servidor Linux

Una unidad oneshot más un temporizador: ningún proceso residente, y una pasada perdida mientras la máquina estaba apagada se recupera en el siguiente arranque.

Si no tienes una máquina encendida en permanencia, sáltate este paso: lanza strava_sync.py a mano cuando te apetezca, o simplemente cuéntale tu sesión al agente en una conversación. El ritual de CLAUDE.md funciona igual. Pierdes la automatización, no el entrenador.

Lo que me llevo de esto, más allá de correr

Este montaje no tiene nada de específico del running. Lo que enseña es un patrón reutilizable para casi cualquier ámbito en el que acumules datos personales y te gustaría una opinión competente sobre ellos.

Tres piezas, y ya está. Un repositorio Git de archivos Markdown como memoria legible por la máquina y por ti. Un evento que despierta a un agente en lugar de un agente que consulta en bucle y quema tokens para nada. Tres capas de configuración que separan con limpieza quién es el agente, cómo trabaja en tu casa y qué debe hacer en este preciso instante.

Cambia "sesión de carrera" por "extracto bancario", "sesión de código", "medición de glucemia" o "nota de lectura": la mecánica no cambia.

Preguntas frecuentes

¿Hay que saber programar para montarse un entrenador de running con IA?

Hay que saber lanzar un comando en una terminal y editar un archivo de texto. El repositorio plantilla está listo para clonar, los scripts Python no usan más que la biblioteca estándar (ningún pip install), y la parte de entrenamiento se configura escribiendo prosa normal en archivos Markdown. El trabajo de verdad no es técnico: es describir con honestidad quién eres como corredor y qué estás buscando.

¿Cuánto cuesta al mes?

El agente funciona con la suscripción a Claude que ya tienes (Pro o Max): no hay ninguna clave de API facturada por token. Encima de eso, quizá quieras una pequeña máquina encendida en permanencia para consultar Strava cada 15 minutos, unos 5 euros al mes en un VPS, o cero en una Raspberry Pi. El repositorio Git privado es gratis. Queda la API de Strava, que exige una suscripción de desarrollador de pago desde junio de 2026.

¿Por qué un repositorio Git y no una base de datos?

Porque el historial se vuelve legible, por el entrenador y por ti. Cada sesión es un archivo Markdown, cada cambio de plan es un commit con su motivo. El agente puede releer lo que prescribió hace tres semanas y comprobar si funcionó, y tú lees tu plan en el móvil desde la app de GitHub, sin escribir una línea de interfaz.

¿Qué es un webhook, dicho en fácil?

Un webhook es un servicio que te llama a ti en lugar de que tú lo llames a él. En vez de preguntar cada cinco minutos si hay algo nuevo, le das una dirección web a un programa y es él quien te envía un mensaje cuando ocurre el evento. Aquí, el script que importa la sesión envía ese mensaje a AgentsRoom, que abre un agente Claude en el mismo segundo. Es también lo que hace barato el montaje: un agente que consulta en bucle quema tokens en cada vuelta, un disparador webhook no cuesta nada mientras no pase nada.

¿Funciona esto para un deporte que no sea correr?

Sí. La importación reconstruye las vueltas del reloj, y el ciclismo y la natación también registran vueltas. Lo que cambia son los archivos de estrategia y el catálogo de sesiones, que son texto que reescribes. La mecánica (importación, webhook, agente, repositorio) no se mueve.

¿Puede equivocarse el agente y destrozarme el plan?

Puede equivocarse, pero no puede destrozar gran cosa: todo lo que escribe es un commit de Git que puedes leer, discutir y revertir. El archivo CLAUDE.md le prohíbe explícitamente reescribir el historial, inventar datos que no le has dado, cambiar el plan sin dejar constancia del motivo y dar consejo médico. Un dolor sospechoso, y te manda a un profesional.

---

El repositorio plantilla está aquí: AgentsRoomDev/running-performance-coach. Clónalo, rellena tus ritmos y ya tienes tu entrenador. Si quieres ver la pieza que despierta al agente, está descrita en la página de disparadores webhook, y AgentsRoom se descarga aquí.