Mój trener biegowy AI to repozytorium Git i agent Claude

Kończę trening. Zegarek sam synchronizuje się z aplikacją Strava, jak zwykle. Idę pod prysznic.

Zanim z niego wyjdę, dzieją się trzy rzeczy, a ja nie ruszam palcem. Analiza treningu jest zapisana w moim repozytorium treningowym. Tydzień został przestawiony, z powodem zmiany zanotowanym obok. A pod aktywnością w serwisie Strava jest komentarz mojego trenera, który mówi mi, ile ten trening był wart i co zmienia na piątek.

Ten trener to nie aplikacja, którą napisałem. To repozytorium Git z plikami Markdown, abonament Claude i AgentsRoom, które spina całość. Żadnego napisanego serwera, żadnego rachunku za tokeny, mniej więcej weekend składania.

Całość jest opublikowana jako wzorzec: github.com/AgentsRoomDev/running-performance-coach. Możesz go sklonować i zrobić swoim, uzupełniając miejsca zostawione puste. Ten artykuł tłumaczy kawałek po kawałku, jak to działa, przy założeniu, że słowo „API” już słyszałeś, ale webhooka nigdy nie pisałeś.

Dla kontekstu: biegam od dawna, 2:47 w maratonie, 1:13:59 w półmaratonie, 33:45 na 10 km. Celem bieżącego cyklu jest wrócić poniżej 34 minut na 10 km. To ważne dla dalszej części: generyczny trener, który tłumaczy mi od nowa, czym jest trening progowy, na nic mi się nie przyda, i dokładnie ten problem rozwiązuje ta konstrukcja.

Co dzieje się między końcem biegu a komentarzem

Cały łańcuch to sześć kroków:

1. Zegarek wysyła aktywność do serwisu Strava. To akurat dzieje się już u wszystkich.
2. Co 15 minut mały skrypt Python pyta serwis Strava, czy jest coś nowego.
3. Kiedy znajdzie nowy trening, buduje z niego kartę treningu w Markdown w moim repozytorium: okrążenia, międzyczasy, objętość, tętno. Wyłącznie dane zmierzone.
4. Przepisuje też tytuł i opis aktywności w aplikacji Strava, żeby w moim strumieniu przestało widnieć „Popołudniowy bieg”.
5. Następnie wysyła podpisaną wiadomość do AgentsRoom, które otwiera agenta Claude, mając trening już w ręku.
6. Ten agent wykonuje pracę trenera: czyta, porównuje, pisze analizę, przestawia tydzień, robi commit, wypycha zmiany, komentuje w serwisie Strava i wysyła mi długi raport mailem.

Pierwsze pięć kroków to hydraulika. O szóstym jest ten artykuł.

Dziennik treningowy to repozytorium Git, a nie baza danych

To decyzja, która zmienia wszystko, i zarazem ta, która najbardziej zaskakuje ludzi.

Jeden trening = jeden plik, journal/2026/2026-09-03.md. Jeden tydzień = jeden plik, plan/weeks/2026-W36.md. Jedna zmiana planu = jeden commit, z powodem w opisie. Nie ma bazy danych, nie ma schematu, nie ma migracji, nie ma interfejsu.

Trzy konsekwencje, w kolejności ważności:

Trener może odczytać własną historię. Wie, co zalecił trzy tygodnie temu, i może sprawdzić, czy to zadziałało. Chatbot, któremu opowiadasz swój trening, zaczyna od zera przy każdej rozmowie. Agent, który ma repozytorium, ma pamięć, a ta pamięć jest czytelna dla człowieka.

Swój plan czytam w telefonie, w aplikacji GitHub. Plik README.md w repozytorium nie jest stroną prezentacyjną: to mój pulpit. Umowa spisana w CLAUDE.md mówi o tym wprost, żadne planowanie nie jest skończone, dopóki README go nie odzwierciedla. Efekt: nie mam żadnego interfejsu do utrzymywania, a mimo to mam ekran, który mówi mi, co robię dzisiaj.

Nic nie jest nieodwracalne. Wszystko, co agent pisze, to commit. Mogę go przeczytać, podważyć, cofnąć. To zupełnie co innego niż aplikacja, która decyduje sama u siebie.

Krok 1: Strava budzi mały skrypt

Serwis Strava udostępnia API: sposób, w jaki program może poprosić „daj mi ostatnie aktywności tego zawodnika”. Skrypt strava_sync.py robi dokładnie to i zamienia odpowiedź w kartę treningu.

Ciekawa część to nie wywołanie sieciowe, tylko rekonstrukcja. Zegarek zapisuje surowe okrążenia. Skrypt musi wywnioskować, co to był za trening:

Lap 1  : 4.40 km in 26'07 (5:56/km)   ← rozgrzewka
Lap 2  : 1.00 km in 3'41  (3:41/km)   ← powtórzenie 1
Lap 3  : 0.20 km in 1'59  (9:55/km)   ← przerwa
...                                     → „5 x 1000m r' 2'”

Próbuje każdego podziału postaci „k najszybszych okrążeń to powtórzenia” i zachowuje ten najlepszy, który się broni. Brzmi trywialnie, a nie jest: naiwne grupowanie po prędkości wpada w pułapkę w chwili, gdy rozgrzewka okazuje się szybsza niż przerwa.

Przede wszystkim kształt treningu jest odtwarzany z zegarka, nigdy z planu. Kusi, żeby zrobić odwrotnie (plan mówi 5 x 1000m, więc to zapiszmy) i to jest właśnie błąd: cały sens polega na wykryciu dni, w których zrobiłem coś innego. Kiedy jedno rozjeżdża się z drugim, to właśnie ta rozbieżność jest informacją, i trener ją widzi:

Planned 3 x 8' → przebiegnięte ciągiem

Dwa ostrzeżenia, zanim zaczniesz.

API Strava wymaga od czerwca 2026 płatnego abonamentu deweloperskiego. Bez niego każde wywołanie odpowiada 403 Application Status Inactive. Rozwiązanie zastępcze istnieje i jest przewidziane we wzorcu: wyeksportować plik TCX z zegarka i podać go do import_tcx.py. Wszystko, co następuje po imporcie, działa identycznie.

Limity są hojne, ale realne. W mojej aplikacji 300 zapytań co 15 minut i 3000 dziennie na odczyt. Skrypt zużywa jedno na przebieg w normalnej pracy, czyli 96 dziennie. Do sufitu bardzo daleko, ale to rzecz, którą sprawdza się przed, a nie po.

Krok 2: skrypt budzi agenta, z podpisem

Tu robi się ciekawie.

Webhook to odwrotność pytania. Zamiast pytać co pięć minut, czy jest coś nowego, dajesz programowi adres internetowy, a on wysyła ci wiadomość, kiedy zdarzenie nastąpi. Nie płacisz nic, dopóki nic się nie dzieje.

AgentsRoom udostępnia dokładnie to: wyzwalacz webhook. Tworzysz wyzwalacz w aplikacji, a ona oddaje ci adres URL i sekret. Ktokolwiek wyśle wiadomość JSON pod ten adres, otwiera agenta, z promptem, który napisałeś, i z treścią wiadomości już w niego wstawioną.

Wiadomość, którą wysyła mój skrypt, jest celowo malutka:

{
  "type": "created",
  "title": "03/09 · 5 x 1000m r' 2'",
  "body": "Trening z 03/09/2026 zaimportowany z serwisu Strava.\n\nTrening jakościowy: 5 x 1000m r' 2'\nMiędzyczasy: 3'41 - 3'40 - 3'38 - 3'40 - 3'35\n\nObjętość łącznie: 12.51 km w 1h07'42 (5:25/km), przewyższenie+ 56 m\nZaplanowany trening: RP10-5x1000\n\nKarta treningu: journal/2026/2026-09-03.md\nKarta tygodnia: plan/weeks/2026-W36.md"
}

Zwróć uwagę, czego tam nie ma: treści planu. Webhook przenosi kod zaplanowanego treningu i ścieżkę do kart, nigdy ich zawartość. Agent, który ma repozytorium, sam pójdzie je przeczytać; agent, który go nie ma, nie ma nic wspólnego z moimi wewnętrznymi wytycznymi. To ta sama zasada co przy opisach publikowanych w serwisie Strava.

Podpis i pułapka, która się z nim wiąże

Publiczny adres URL, który otwiera agenta, nie może zostać otwarty dla każdego, kto go znajdzie. Wyzwalacz jest więc podpisany: skrypt liczy odcisk wiadomości przy użyciu wspólnego sekretu (HMAC-SHA256, jeśli ten skrót coś ci mówi) i wysyła go w nagłówku X-AgentsRoom-Signature. Serwer przelicza ten sam odcisk u siebie; jeśli się nie zgadza, odmawia.

Bez podpisu odpowiedź jest krótka:

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

A oto pułapka, która kosztowała mnie jeden wieczór. Podpis obejmuje dokładnie te bajty, które idą w sieć, a nie obiekt w pamięci. Jeśli podpiszesz plik w postaci, w jakiej leży na dysku, a potem pozwolisz innej warstwie ponownie zserializować obiekt (jedna spacja więcej, inna kolejność kluczy, inaczej zakodowany znak diakrytyczny), dostaniesz doskonale poprawny podpis dla wiadomości, której serwer nigdy nie otrzyma. Odrzucenia nie da się zdebugować: po obu stronach wszystko wygląda poprawnie.

Poprawka mieści się w jednym zdaniu: serializuj i podpisuj w tym samym miejscu. We wzorcu robi jedno i drugie funkcja post_json, i nic innego nie ma prawa dotknąć treści wiadomości.

Krok 3: trzy warstwy mówią trenerowi, kim jest, jak się tu pracuje i co ma zrobić teraz

Agent, który trenuje, to nie jeden wielki prompt. To trzy osobne teksty, a ten podział ma znaczenie.

Warstwa 1, persona: kim jest

Prompt systemowy dołączony do agenta w AgentsRoom. Nosi filozofię treningową i jest celowo niezależny od dyscypliny: poprowadziłby każdego.

Twoim zadaniem nie jest po prostu generowanie planów treningowych. Prowadzisz zawodnika w sposób ciągły, analizując jego trening, rozumiejąc jego bieżącą formę i dostosowując kolejne jednostki. […] Mów jak doświadczony trener, a nie jak chatbot motywacyjny.

Mówi też, czego nie robi: nie ocenia treningu wyłącznie po tym, czy zaplanowane tempo zostało utrzymane, wprost nazywa niepewność prognozy wyniku i nie zatwierdza celu tylko dlatego, że zawodnik ma na niego ochotę. Ta ostatnia linijka jest tym, co czyni trenera użytecznym.

Nie musisz jej pisać sam: ta persona jest opublikowana w katalogu agentów AgentsRoom pod nazwą Trener Wydolności Biegowej. Jedno kliknięcie instaluje ją u ciebie, gotową do pracy.

Warstwa 2, CLAUDE.md: jak się tu pracuje

To umowa, czytana na początku każdej sesji. Zawiera układ plików, reguły, które trzymają go w ryzach, zasady treningowe ograniczające każdą propozycję, a przede wszystkim rytuał: dokładną sekwencję do wykonania, kiedy trening zostaje zgłoszony.

Jeden fragment, bo pokazuje poziom precyzji:

Kolejność poświęceń, gdy tydzień się rozjeżdża: najpierw dodatkowe minuty na spokojnych wybieganiach, potem praca siłowa, potem długość długiego wybiegania, potem jeden trening jakościowy. Nigdy cały tydzień.

To tutaj trener przestaje być chatbotem. Nie improwizuje procedury za każdym razem, tylko idzie za tą, którą napisałem raz. Jeśli masz przeczytać tylko jeden plik z repozytorium wzorcowego, przeczytaj ten.

Warstwa 3, prompt wyzwalacza: co zrobić teraz

To wiadomość przekazywana agentowi, kiedy trening ląduje. Dostaje aktywność przez zmienne szablonu: {{event.title}}, {{event.body}}, {{event.url}}. Agent zaczyna więc z treningiem już w ręku, zamiast go szukać.

Oto jego szkielet, taki jak stoi w wyzwalaczu:

Nowy trening zaimportowany z serwisu Strava.

**{{event.title}}** · aktywność {{event.id}}
{{event.url}}

{{event.body}}

---

Jesteś w repozytorium `training-plan`. Przeczytaj najpierw `CLAUDE.md`: to prawo.
Piszesz w moim języku i zwracasz się do mnie bezpośrednio (§3).

Rytuał z §6 obowiązuje, ale jego **krok 1 jest już zrobiony**:
`strava_publish.py` utworzył kartę treningu i ją zacommitował. Wznawiasz od
kroku 2 i idziesz do końca. Trzy rezultaty, w tej kolejności: **analiza w
repozytorium**, **komentarz pod aktywnością w serwisie Strava**, **mail**.

⚠️ **Pracujesz bez nadzoru: nikt nie przeczyta pytania.** Nigdy nie proś o
rozstrzygnięcie: decydujesz, działasz i piszesz w swoim raporcie, co
przesądziłeś i dlaczego.

## 1 · Analiza i korekta planu (rytuał §6, kroki od 2 do 6)

1. Najpierw `git pull --rebase`: karta może pochodzić z serwera.
2. Przeczytaj w tej kolejności: kartę dnia, kartę tygodnia,
   `athlete/zones-and-paces.md` oraz **3 ostatnie karty treningów**:
   treningu nigdy nie ocenia się w oderwaniu.
3. Napisz sekcję `## Analysis`: **najpierw werdykt**, potem sygnały, które go
   niosą, potem to, co się przez niego zmienia.
   ⛔ Jeśli `## Analysis` jest już wypełniona, nie przepisuj jej.
4. Zaktualizuj kartę tygodnia i zapisz **każdą** zmianę planu pod
   `## Adjustments`, wraz z powodem.
5. **Wygeneruj `README.md` od nowa**: to ekran, który czytam w telefonie.
6. Commit i push, jawne ścieżki, ⛔ nigdy `git add -A`.

## 2 · Kudos i komentarz w serwisie Strava
   ⛔ Komentarz w serwisie Strava jest PUBLICZNY: żadnego docelowego tętna, żadnej
   dolegliwości, żadnego wewnętrznego kompromisu, żadnego prognozowanego czasu.

## 3 · Pełny raport mailem

Linijka, która robi najwięcej roboty, to ta w środku: „nikt nie przeczyta pytania”. Agent, który pracuje bez nikogo przed ekranem i prosi o rozstrzygnięcie, nie popełnia błędu, on się po prostu zatrzymuje, a ty dowiadujesz się o tym nazajutrz.

Jaki model i dlaczego milion tokenów to nie próżność

Długi kontekst to nie ozdobnik. Żeby dobrze ocenić jeden trening, trener czyta kartę dnia, kartę tygodnia, tabelę temp odniesienia i trzy poprzednie treningi. Treningu nigdy nie ocenia się w oderwaniu: nagromadzone obciążenie, kolejność dni i otwarte punkty do obserwacji całkowicie zmieniają werdykt. Trzy powtórzenia po 3'38 dzień po dwugodzinnym długim wybieganiu opowiadają zupełnie inną historię niż te same 3'38 po dniu odpoczynku.

Tryb autonomiczny to nie niedbalstwo, tylko konsekwencja: uruchomienie bez nikogo przed ekranem nie ma kogo poprosić o zatwierdzenie git push. A dostęp do przeglądarki jest tym, co pozwala agentowi skomentować w serwisie Strava i wysłać mail, czyli zrobić dwie rzeczy, które nie mają tu wygodnego API.

Co jest zautomatyzowane, a co celowo nie

To decyzja projektowa, z której jestem najbardziej zadowolony, i łatwo ją przeoczyć.

Zadanie importu zapisuje i publikuje, nigdy nie ocenia.

Skrypt, który zacząłby oceniać, produkowałby werdykty bez kontekstu, z logiką zamrożoną w kodzie, którego nikt nie przegląda. Ocena wymaga utrzymania razem obciążenia tygodnia, bieżącej formy i tego, co powiedziano ostatnim razem: to praca trenera, i robi ją agent, mając przed sobą całe akta.

Praktyczna korzyść jest natychmiastowa: kiedy agent nie zadziałał (maszyna wyłączona, API leży), karta i tak istnieje. Nic nie ginie, brakuje tylko komentarza, a wystarczy powtórzyć zdarzenie.

Inny wybór idzie w tę samą stronę: skrypt nie prowadzi pliku stanu, żeby wiedzieć, co już obsłużył. Rozstrzyga opis w serwisie Strava. Pusty, więc pisze; z jego podpisem, więc przechodzi dalej; niepusty i bez podpisu, więc napisałeś go ty i skrypt go nie rusza. Lokalny plik stanu nie powiedziałby nic o tym, co zrobiła inna maszyna; tak dwie maszyny mogą działać równolegle, nie wchodząc sobie w drogę.

Dwie kolejne zasady rozdziału, wyryte w repozytorium i nie do obejścia:

• opis publikowany w serwisie Strava nigdy nie kopiuje treści planu: moja karta tygodnia zawiera docelowe tętna i kompromisy, które nie mają czego szukać w publicznej aktywności;
• opis napisany ręcznie nigdy nie zostaje nadpisany.

Komentarz, który ląduje pod aktywnością

Nie chodzi o samozachwyt. Chodzi o to, żeby werdykt trenera był czytelny z telefonu, pod aktywnością, bez otwierania repozytorium, i żeby tam został, przypięty do treningu, na zawsze.

Komentarz jest więc celowo wąski: emoji z werdyktem, liczba, która go niesie, i to, co zmienia na następny trening. Około 250 znaków.

✅ Pięć powtórzeń po 3'39 średnio przy celu 3'38-3'44, a tętno płaskie przez cały blok. Tabela temp się trzyma. Piątek zostaje spokojny: zapas tego tygodnia został wydany.

Wersja długa, ta z tętnami, punktem do obserwacji, który zgłosiłem, i rozstrzygnięciem co do objętości przyszłego tygodnia, idzie do repozytorium i do maila. Dwa kanały, dwie publiczności, a granicy pilnuje prompt.

Trzy rzeczy, które psują się dopiero na produkcji

Każda z tych linijek istnieje, bo bez niej coś się zepsuło. Są bardziej pouczające niż reszta artykułu.

1. Przypnij przeglądarkę. Mam w Chrome podpięte dwa rozszerzenia Claude. Nic nie gwarantuje, które dostanie agent, a tylko jedno trzyma sesję Strava. Efekt: co drugie uruchomienie agent lądował w złej przeglądarce, wylogowany, niezdolny cokolwiek skomentować. Wybór przeglądarki po identyfikatorze urządzenia nie zachowuje się między sesjami: musi więc być w prompcie, z wyraźnym zakazem pytania użytkownika, którą wybrać. Bez nadzoru pytanie to zakleszczenie.

2. Pole komentarza w aplikacji Strava nie ma maxlength. Nic w przeglądarce nie powstrzyma cię przed napisaniem zbyt długiego tekstu: to serwer odmawia przy wysyłce. Agent, który układa piękny akapit na 600 znaków, wpisuje całość, klika „Opublikuj” i dostaje porażkę, której nie rozumie. Prompt musi więc narzucić zwięzłość przed pisaniem i przewidzieć ten przypadek: jeśli wysyłka się nie uda, skracamy i publikujemy ponownie, nigdy nie tniemy na dwa komentarze.

3. Jeden komentarz trenera na aktywność. Kiedy powtarza się zdarzenie w celach testowych (a na początku robi się to dużo), bez tej zasady agent piętrzy komentarze pod aktywnością już obsłużoną. Prompt każe mu więc przed pisaniem przeczytać zakładkę „Komentarze” i odpuścić, jeśli już tam jest. Ta sama logika po stronie repozytorium: jeśli sekcja ## Analysis jest już wypełniona, nie przepisuje się jej.

Ile to kosztuje

W tej konstrukcji nie ma klucza API rozliczanego za tokeny. To punkt, który uważam za najbardziej niedoceniany: to samo zbudowane na API płatnym od zużycia miałoby licznik kręcący się przy każdym treningu, i prawdopodobnie bym przy tym nie został.

Zbuduj to w ten weekend

Kroki, po kolei. Licz na jeden wieczór, jeśli masz już konto w serwisie Strava i abonament Claude.

1. Sklonuj wzorzec i zrób go swoim.

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

Ustaw swoją kopię jako prywatną. Dziennik treningowy zawiera dane o zdrowiu: tętno, sen, kontuzje. Wzorzec jest publiczny, twoja kopia być nie powinna.

Następnie wypełnij, w tej kolejności: athlete/profile.md (kim jesteś jako biegacz), athlete/records.md (twoje rekordy życiowe), athlete/constraints.md (okna czasowe, które naprawdę masz), athlete/zones-and-paces.md (twoje tempa odniesienia), plan/objective.md (bieg i cel), a potem CLAUDE.md, gdzie podmieniasz każde miejsce {{...}}.

Na koniec otwórz repozytorium swoim agentem Claude i powiedz mu: „przeczytaj CLAUDE.md i athlete/, a potem zbuduj mi pierwszy tydzień”.

2. Podłącz serwis Strava.

cp .env.example .env && chmod 600 .env
python3 scripts/strava_oauth.py     # jedno kliknięcie w przeglądarce, raz
python3 scripts/strava_sync.py --dry-run

--dry-run wypisuje, co zostałoby zapisane, nic nie zapisując. To moment, żeby sprawdzić, czy rekonstrukcja treningów ci odpowiada.

3. Utwórz wyzwalacz w AgentsRoom. W sekcji Triggers, New trigger:

AgentsRoom wystawia adres URL i sekret do podpisu. Wpisz oba do swojego .env:

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

4. Przetestuj, zanim mu zaufasz.

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

To odtwarza trening w wyzwalaczu bez czekania na twoje następne wyjście i bez ruszania stanu zadania automatycznego. Powinieneś zobaczyć ✅ HTTP 202, a w AgentsRoom powinna otworzyć się karta agenta.

5. Uruchamiaj co 15 minut.

bash scripts/systemd/install.sh          # na serwerze Linux

Jednostka oneshot plus timer: żadnego procesu rezydentnego, a przebieg pominięty w czasie, gdy maszyna była wyłączona, zostaje nadrobiony przy następnym starcie.

Jeśli nie masz maszyny działającej bez przerwy, pomiń ten krok: uruchamiaj strava_sync.py ręcznie, kiedy przyjdzie ci ochota, albo po prostu opowiedz agentowi swój trening w rozmowie. Rytuał z CLAUDE.md działa identycznie. Tracisz automatyzację, nie trenera.

Co z tego wynoszę, poza bieganiem

W tej konstrukcji nie ma nic swoistego dla biegania. Pokazuje ona wzorzec do wielokrotnego użytku dla niemal każdej dziedziny, w której gromadzisz dane osobiste i chciałbyś mieć o nich kompetentną opinię.

Trzy części i to wszystko. Repozytorium Git z plikami Markdown jako pamięć czytelna dla maszyny i dla ciebie. Zdarzenie, które budzi agenta, zamiast agenta odpytującego w pętli i palącego tokeny na darmo. Trzy warstwy konfiguracji, które czysto rozdzielają, kim agent jest, jak pracuje u ciebie i co ma zrobić w tej chwili.

Zamień „trening biegowy” na „wyciąg bankowy”, „sesję kodowania”, „pomiar cukru” albo „notatkę z lektury”: mechanizm się nie zmienia.

Najczęstsze pytania

Czy trzeba umieć programować, żeby zbudować trenera biegowego AI?

Trzeba umieć uruchomić polecenie w terminalu i edytować plik tekstowy. Repozytorium wzorcowe jest gotowe do sklonowania, skrypty Python nie używają niczego poza biblioteką standardową (żadnego pip install), a część trenerską konfiguruje się, pisząc zwykłą prozą w plikach Markdown. Prawdziwa praca nie jest techniczna: polega na uczciwym opisaniu, kim jesteś jako biegacz i do czego zmierzasz.

Ile to kosztuje miesięcznie?

Agent działa na abonamencie Claude, który już masz (Pro lub Max): nie ma tu klucza API rozliczanego za tokeny. Do tego dochodzi ewentualnie mała maszyna działająca bez przerwy, która co 15 minut odpytuje serwis Strava, około 5 euro miesięcznie na VPS albo zero na Raspberry Pi. Prywatne repozytorium Git jest darmowe. Zostaje API Strava, które od czerwca 2026 wymaga płatnego abonamentu deweloperskiego.

Dlaczego repozytorium Git, a nie baza danych?

Bo historia staje się czytelna, dla trenera i dla ciebie. Każdy trening to plik Markdown, każda zmiana planu to commit wraz z powodem. Agent może odczytać, co zalecił trzy tygodnie temu, i sprawdzić, czy to zadziałało, a ty czytasz swój plan w telefonie w aplikacji GitHub, nie pisząc ani linijki interfejsu.

Czym jest webhook, po ludzku?

Webhook to usługa, która dzwoni do ciebie, zamiast czekać, aż ty zadzwonisz do niej. Zamiast pytać co pięć minut, czy jest coś nowego, dajesz programowi adres internetowy, a on wysyła ci wiadomość, kiedy zdarzenie nastąpi. Tutaj skrypt, który importuje trening, wysyła tę wiadomość do AgentsRoom, a to w ciągu sekundy otwiera agenta Claude. To także sprawia, że cała konstrukcja jest tania: agent odpytujący w pętli pali tokeny przy każdej turze, a wyzwalacz webhook nie kosztuje nic, dopóki nic się nie dzieje.

Czy to zadziała dla innego sportu niż bieganie?

Tak. Import odtwarza okrążenia z zegarka, a kolarstwo i pływanie też je zapisują. Zmieniają się pliki strategii i katalog treningów, czyli tekst, który przepisujesz po swojemu. Mechanizm (import, webhook, agent, repozytorium) zostaje bez zmian.

Czy agent może się pomylić i zniszczyć mój plan?

Może się pomylić, ale nie może wiele zniszczyć: wszystko, co pisze, to commit Git, który możesz przeczytać, podważyć i cofnąć. Plik CLAUDE.md wprost zabrania mu przepisywania historii, wymyślania danych, których nie dostarczyłeś, zmieniania planu bez zapisania powodu oraz udzielania porad medycznych. Przy podejrzanym bólu odsyła cię do specjalisty.

---

Repozytorium wzorcowe jest tutaj: AgentsRoomDev/running-performance-coach. Sklonuj je, wpisz swoje tempa i masz swojego trenera. Jeśli chcesz zobaczyć element, który budzi agenta, jest opisany na stronie wyzwalacze webhook, a AgentsRoom pobierzesz tutaj.