I’m a heavy user - been testing Section 11 with my own workout data and training plan. The protocol is working really well in practice but needs some tweaking - more fix-ups coming soon 
Happy to keep contributing, especially on the development side: Python/backend work (sync.py improvements, metrics calculations, API integrations, etc.). Let me know where help would be most useful.
Appreciate it, your fixes have already improved things.
What sports are you primarily training?
Beyond that, follow what interests you. If something feels off against your own data, that’s usually a good place to start.
I’m training for gravel races primarily, road occasionally. After last season I started to explore AI tools more, but haven’t found what I needed and decided to build my own on Intervals platform - this way I found your protocol during research. It works pretty good but still have some issues with:
In the meantime I’m also trying to extend capabilities of Intervals MCP server, this is my fork of @Marc work but eventually I plan to merge it with upstream (WIP):
@mrpear Thanks, gravel/road is a great test bed, and nice work on the MCP fork.
The date/time and the remaining sleep-scale interpretation issues sound like model grounding/context drift rather than bad data. The protocol includes generated_at/data_freshness + scale definitions, but models can still drift depending on setup and chat length/history.
The sleep scale mapping in the protocol/templates is fixed (your PR). If it’s still being interpreted incorrectly, it’s likely the model drifting rather than the mapping.
For all three items: concrete examples help (report snippet + what the model got wrong). GitHub Issues work best for that, easier to track than forum posts.
Re the MCP fork: definitely relevant. I’m working on an MCP path for Section 11, too; just need to finish a couple of related pieces first.
If you’re on Claude web: try a fresh chat and reattach the key report/context files—long-running chats/projects can drift.
(For reference: I’m mostly using an agentic Claude setup lately, and it’s been very reliable.)
I’m using Claude CLI mainly, the context drifting you mentioned might be the case - thanks!
Section 11 update (2026-02-26)
NEW: SETUP_ASSISTANT.md — easier onboarding.
Paste it into any AI (ChatGPT/Claude/Grok/Gemini) and it walks you through the full setup step-by-step
Also in this release
session_template audit traceability.Section 11 update (2026-02-28)
FIX: sync.py v3.6.1 — Hard day counter now falls back to HR zones when power zones aren’t available, so non-power sessions no longer get undercounted as “easy,” which could skew phase detection. Conservative HR ladder (Z4+ ≥ 10 min, Z5+ ≥ 5 min). Daily tier rows now include intensity_basis (power/hr/mixed/null) for traceability.
Also in this release:
Hi and thank s a lot for this great project. I loved Intervals.icu already and am using it extensivly. I just started using Section11 with OpenClaw. One question, that came up: is it planned to allow the agent to write planned workouts to the calendar (upon user confirmation)? I really loved the ability of having the next X days of workouts being written automatically using another skill. The pipe Section11 → Intervals → Zwift would be complete 
Thanks
Yes, writing planned workouts to the Intervals.icu calendar is on the roadmap.
Do you use Section11 Agentic? (Code/Cowork/OpenClaw, etc.) or via web/phone chat?
OpenClaw on my MiniComputer (Ubuntu) and communication mainly through Telegram channel
@Martin_Schmelzer
Great setup
Section 11 update (2026-03-03)
NEW: sync.py v3.6.4 — Planned workout summaries. Interval sessions are now compressed into one-line shapes (e.g. 5×4m @106–120% / 3m Z1) instead of dumping raw steps. Two parsers (explicit repeats + flat alternating detection) with strict guards; fallback keeps raw description. Planned workouts are tiered: full detail days 0–7, skeleton + summary days 8–42. Includes workout_summary_stats coverage telemetry.
NEW: examples/agentic — Calendar push. push.py + push-workout.yml writes planned workouts to your Intervals.icu calendar (GitHub Actions dispatch or local CLI).
Also in this release:
duration_formatted, sleep_formatted, total_training_formatted (XhYm)*_formattedI set up everything yesterday with via Google Gemini (the “easy” option). Kudos for the installation support, even I managed to get everything running.
After doing one of the recommended workouts yesterday I did some queries today regarding recovery. While doing that I noticed that Gemini does not use the metrics that are being provided by the synched json files. RHR and HRV were off, resulting in an incorrect recovery index and hence training advice. Are there any known issues with Gemini or anything I need to ensure in order to have everything run as intended?
Try asking it to quote the exact RHR and HRV values from your sync file; that’ll tell you quickly whether it’s reading or guessing.
A couple of things to check if it’s guessing:
First, make sure you’re using the raw URL for your latest.json link (e.g. https://raw.githubusercontent.com/.../latest.json), not the GitHub blob URL. The blob version returns an HTML page, not the actual JSON data.
Second, try downloading the official section-11 repo as a zip from GitHub and uploading it into your Gem or chat.
Ask Gemini or another AI to troubleshoot your setup.
Thank you.
I did enable the github extension in Gemini and made the repo available to the Gem as a data source. This seems to have done the trick, at least all the metrics add up now. Will keep testing this.
Have you considered making the full datastream for power / HR / Cadence for the last workout (or the last 3 workouts) available? Or at least the stats on interval level? I had a completely hallucinated exchange with Gemini on how the cadence dropped in the last 2 intervals pointing towards a red light and enforcing a recovery regimen for the next 48 hours. I think having this exchange based on real data might be of value.
That’s a lot of data. I will test it.
You are right. The interval data should be enough to get any kind of insights (“get activity intervals”). Also, this is only of use for the most recent activities. Just an idea
@CrankAddict Thanks!
I have an issue now. Updated to the latest version and went for a ride outside. Somehow the sync does not work properly. The ride shows up in latest.json with type “Unknown” and all data fields are nulled. On intervals.icu everything looks normal.
Any thought? It has been 3 hours since the ride was finished and uploaded to Strava.
Please download the latest sync.py version 3.7
Edit: What sport does it shows as in Intervals.icu?
I copied the new version of sync.py into my repository and rerun the workflow. No success yet.
“recent_activities”: [
{
“id”: “17602708889”,
“date”: “2026-03-04T15:31:45”,
“type”: “Unknown”,
“name”: “”,
“duration_hours”: 0.0,
“distance_km”: 0.0,
“tss”: null,
“intensity_factor”: null,
“avg_power”: null,
“normalized_power”: null,
“avg_hr”: null,
“max_hr”: null,
“avg_cadence”: null,
“avg_speed”: null,
“max_speed”: null,
“avg_pace”: null,
“avg_temp”: null,
“weather”: null,
“humidity”: null,
“wind_speed”: null,
“work_kj”: null,
“calories”: null,
“carbs_used”: null,
“carbs_ingested”: null,
“variability_index”: null,
“decoupling”: null,
“efficiency_factor”: null,
“elevation_m”: null,
“feel”: null,
“rpe”: null,
“zone_distribution”: null
}
In Intervals.icu the activity shows up as a “Ride”, with everything in order.
How did this data get into Intervals.icu — direct from Garmin/Wahoo, or via Strava?