I’ve been working on a structured protocol that makes AI endurance coaching consistent, reliable, and moveable, that works with any AI/LLM and is free.
Sharing it here since it builds on ideas from this community.
Section 11 — a deterministic protocol that forces AI systems to fetch your Intervals.icu data, follow evidence-based frameworks, and give auditable recommendations.
What it does: * Auto-fetches your training data via JSON mirror (Also manual option) * Structured response format: session details → training load context → interpretation * Works across ChatGPT, Claude, Grok, Mistral (tested)
What’s included: * SECTION_11.md — The complete protocol (11 A/B/C) * DOSSIER_TEMPLATE.md — Your athlete profile template * sync.py — Script to sync Intervals.icu → GitHub JSON * Setup guides for auto-sync and manual export
Quick start: 1. Fork the repo 2. Add your Intervals.icu API key as GitHub secret 3. Enable the sync workflow 4. Copy instructions into ChatGPT/Claude Project 5. Ask “How was today’s workout?”
Bug fix in sync.py: Fixed an issue where CTL/ATL/TSB values were showing projected numbers (including planned workouts) instead of your actual current fitness state. The script now calculates your true baseline by fetching yesterday’s values and applying the correct PMC decay formula.
OpenClaw (ClawdBot, MoltBot) compatibility: If you’re using OpenClaw (the viral open-source AI agent), Section 11 works well with it. The combination of OpenClaw’s persistent memory + autonomous execution + Section 11’s structured validation makes for a surprisingly capable coaching setup.
Phase Detection Criteria — deterministic triggers for Base/Build/Peak/Taper/Recovery/Overreached
Zone Distribution Metrics per Seiler — Grey Zone % (Z3, minimize this) and Quality Intensity % (Z4+, the work that matters), plus hard days/week for high-volume athletes where time-in-zone gets misleading
Benchmark Index — FTP tracking with seasonal context
Durability Sub-Metrics, W′ Balance, Plan Adherence Monitoring, extended validation schema
All additive — nothing existing was changed.
Output Format & Report Templates (v11.3)
Rewrote the Communication Style section and added Output Format Guidelines so AI coaches produce consistent, scannable reports:
Post-workout: structured line-by-line per session (not bullets) — power, HR, zone breakdowns, Grey Zone %, Quality Z4+%, decoupling, VI, TSS actual vs planned. Weekly totals block (Polarization, CTL, ATL, TSB, ACWR, hours, TSS). Coach note at the end
Updated to support the new metrics — Grey Zone %, Quality Intensity %, Polarisation Index, Benchmark Index, and phase detection are now calculated and included in the JSON output. Also added FTP history tracking (ftp_history.json) for indoor/outdoor FTP changes over time, used by Benchmark Index.
Repo & Docs
Overhauled the README and SETUP’s, Should be easier to get started now.
I really wish I had started with this. My engine is now extremely competent and complex, but I have done A LOT of redirection and bug fixing on the way. This would have helped a lot.
Thanks I had a quick look at your repo and some MD files. Is there any opportunity to make some YT videos to show it in action? It would be helpful for anyone like me trying to learn AI tools and how to apply to endurance training.
Update: sync.py v3.3.0 — Longitudinal History + Update Notifications
Two additions to the data pipeline:
Longitudinal History (history.json)
The sync script now generates a second JSON file with your full training history, tiered by granularity:
Daily — last 90 days
Weekly — last 180 days
Monthly — up to 3 years
Includes period summaries, FTP timeline, and data gap detection. Generated automatically on first run, regenerates when outdated. Give both latest.json and history.json to your AI coach and it can do proper trend analysis — CTL progression, seasonal patterns, volume periodization over years. You can always create a full daily history json, of any length with json-manual.
Update Notifications
The sync workflow now checks for updates automatically. When a updated/new file is released, a GitHub Issue is created in your data repo with a summary of changes. No automatic update, just a notification.
Docs
Updated all READMEs and setup guides to reflect the new files. Also added a DATA_REPO_README.md template in examples/json-auto-sync/ — copy it into your data repo for a working sync badge and auto-updating timestamp.
If you’re already running the auto-sync, grab the latest sync.py and auto-sync.yml from the repo and re-run to generate the new versions/files.
Smart Fitness Metrics — CTL/ATL/TSB now use decayed values when planned workouts aren’t completed yet, so no more inflated numbers. eFTP, W’, P-max pulled directly from the API.
Hard Day Classification — Zone ladder per Seiler/Foster: higher zones need less time to qualify (z3+ ≥ 30min down to z7 ≥ 1min). Phase detection now uses both time-in-zone and hard day count — fixes false “Base” for high-volume athletes.
Multi-Sport Monotony — Cross-training was inflating monotony scores. Now auto-detects primary sport and alerts trigger on per-sport monotony instead of total.
Seiler TID + Polarization Index — Proper 3-zone classification (Polarized/Pyramidal/Threshold/HIIT/Base) with Treff PI calculation. sync.py now calculates correctly from raw zones. Dual all-sport + primary-sport.
Report Templates — All four updated with TID classification, Recovery Index, and monotony context. Per-session “Session profile” label catches when planned endurance rides go pyramidal.
Docs, SETUP guides, and OpenClaw skill also updated.
New capability metrics — aggregate views of data that were previously only available per session.
Aggregate Durability — Tracks HR–Power decoupling trends across your steady-state sessions (7d vs 28d rolling windows). Spots declining endurance, alerts fire automatically when trends regress.
Dual-Timeframe TID — Compares your last 7 days of intensity distribution against your 28-day baseline. Catches grey zone drift and acute depolarization.
Both feed into the AI coach’s alert system and report templates at every level (pre-workout through block reports).
I got that sorted now, VSC with WSL locally and Git access. It would help if some videos would be created to show practical use of your tool and what can be done with real athele data.
No videos planned — Section 11 is a text-first protocol, not a GUI tool or walkthrough product. The README and setup docs already provide step-by-step instructions plus a simple test command to verify your environment.
The project assumes you’re comfortable with GitHub, markdown, and basic tooling. If that fits, the existing documentation should be sufficient.
If you encounter a specific issue, post the exact error and what you’ve tried. I’ll fix mistakes or clarify the docs as needed. General tooling tutorials or video requests are out of scope.
Thanks, great work.
I had one problem: I got an error when sync runs: In line 2519 there is an key error ‘type’. After commenting out this line everything works.
Question: Weighttraing workouts are not synced. Do you plan to add this or other workout types?
The KeyError is fixed. I also improved the anonymization logic so indoor/stationary activities (weight training, SkiErg, swim, etc.) retain their original names instead of being blanked.
On weight training: if you mean having those sessions appear in the activity list with duration/load, that should now work. If you’re looking for strength-specific analysis or modeling, that’s not planned at this stage.
Thanks @CrankAddict for sharing this. After reading the readme, I have a few questions:
I see how it analyze past and present data and gives you recommendations. Do these recommendations include specific training sessions for upcoming days? If so, do they have intervals workout text format?
If it’s fetching data every 15 minutes (if configured via GitHub repo), and if you ask the LLM early in the morning, how do you make sure you already have today’s data available? In Garmin, the flow is something like: you wake up, accept the morning report, it goes to intervals, GitHub fetch every 15 min.
Again, very cool stuff. Looking to have some time to play with it!
Section 11 doesn’t generate workout files or push sessions to your calendar. It provides the analysis layer (load, trends, readiness context, alerts) that gives an AI coach structured input. What the recommendations look like depends on your prompts and training history.
A proper workout generator is a separate and non-trivial problem. It’s something I’m exploring conceptually, but nothing is planned or ready to release.
The sync pulls whatever Intervals.icu has available at runtime. If your Garmin data hasn’t landed yet, the AI works off the latest completed state.
The 15-minute schedule is configurable. You can trigger a manual sync at any time or automate a fresh sync with an AI workflow before generating reports or recommendations.
Each report includes a data-freshness timestamp. The main README can display one as well if configured per the setup guide.
Thanks for the response. I’m checking now the sync script and I see parts that expect cycling data. What if our primary sport is running?
You know, in running we have power data also, but is not reliable as having a power meter pedal in the bike.
The core metrics (CTL/ATL/TSB, ACWR, HRV, readiness, zone distribution) are sport-agnostic. They operate on whatever Intervals.icu provides — TSS, HR, duration, pace — so running activities sync and analyze normally.
Some Tier 3 metrics are cycling-oriented (FTP benchmarks, normalized power, VI, durability via decoupling). Those assume reliable power-meter data.
For running, HR- and pace-based analysis carry most of the signal. If power data is missing or unreliable, those cycling-specific fields simply remain empty — they don’t affect the core load/readiness logic.
Section 11 is currently more bike-centric in its advanced metrics. Running-specific extensions are possible, but not a primary focus at this stage. Contributions are welcome.
I will try to find some time to contribute, thanks. Right now I just played for small time.
Things I discovered so far:
Some settings like LTHR and maxHR, are from cycling settings, that are different from running settings. These two are very important to be correct, depending on the activity.
Not related to the project, but Gemini Gems fails a lot reading the correct dates for activities in the latest.json. Example: it says “you have a intensity session tomorrow…”, but actually it is the day after tomorrow.
Gemini Gem don’t allow to access public URLs, so the files have to be passed manually. I have to try other agent, but Gemini was super easy to set.
Gemini can be a bit inconsistent and depends on what access is enabled on your account.
A few things to try:
Import the repo via GitHub integration: In Gemini web chat, click the + icon → Import code, paste the repo URL, and authorize. This also works for Gems.
Enable the GitHub extension: Go to gemini.google.com → Settings → Extensions (Connected Apps) and make sure GitHub is turned on.
If it’s a private repo, you’ll need to authorize your GitHub account when prompted.
You can also try referencing the repo directly in chat using @GitHub.
I’ll update the README to clarify the Gemini setup.
Your AI coach now knows race day is coming — and adjusts accordingly.
Race-Week Protocol (D-7 to D-0) — Tag your events as RACE_A/B/C in Intervals.icu and the system builds a day-by-day taper plan automatically. Daily load targets (% of CTL), opener scheduling at D-2, carb loading triggers for events over 90 min, and a go/no-go checklist on race morning. Backed by Mujika, Bosquet, and Altini’s HRV research.
Three-layer race awareness — 90-day calendar shows upcoming races in every report. Taper onset alerts fire at D-14 for A races. Full race-week protocol activates at D-7 for A and B races. C races are training races — no taper.
TSB projection — Projects your race-day freshness using PMC decay with zero assumed load. Flags automatically if you’re tracking below target range and suggests additional rest.
Also includes “taper tantrums” guidance (D-4 to D-2 feeling flat is normal, not lost fitness) and explicit rules that HRV and sleep never recommend DNS — only illness or injury can.
First community PR merged — @mrpear fixed the sleep quality scale across the protocol and all report templates to match the Intervals.icu API (1-4 inverted, not 1-5). Decision logic updated, too.
—