A pattern for building a personal cycling coach using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
The core idea
Most cyclists' experience with training technology looks like this: you finish a ride, your head unit uploads to Strava or Garmin Connect, and you see a dashboard — TSS, normalized power, a map, maybe a fitness/freshness chart. TrainingPeaks adds structured workout prescriptions. Intervals.icu adds analytics. These tools are good at showing you data. But showing data is not coaching. A dashboard doesn't remember that your left knee flares up after long Z2 rides, doesn't notice that you consistently fade in the third interval of VO2max sets, doesn't know you're vegetarian, and doesn't adjust next week's plan because you had a terrible night's sleep. A human coach does all of this — but human coaches are expensive, have limited bandwidth, and can't monitor your data 24/7.
The idea here is different. Instead of a dashboard or a chat session that starts fresh every time, the LLM acts as a persistent cycling coach that maintains a structured knowledge base about you — your physiology, your goals, your training history, your event calendar, your nutrition, your recovery patterns. It connects to your fitness platforms via MCP servers, so it can pull your latest ride data, analyze it in context of your training plan, and adjust what comes next. It pushes action items — workouts, meals, grocery lists — to your task manager so the plan actually gets executed.
This is the key difference from a generic LLM conversation about training: the knowledge base is a persistent, compounding artifact. Your FTP progression is already tracked. Your response to sweet-spot vs. threshold work is already documented. The connection between your sleep quality and next-day performance is already noted. Every workout analysis, every plan revision, every source you feed the coach makes the picture richer. The coach improves because it remembers everything — not because the model got better, but because the knowledge base got deeper.
Three things work together. Data flows in from your fitness platforms via MCP servers — activities, metrics, health data, training history. Knowledge accumulates in an Obsidian wiki the LLM maintains — training plans, workout analyses, event goals, reference material, an evolving picture of you as an athlete. Action items flow out to your task manager — today's workout, this week's meals, Saturday's grocery run. The LLM sits at the center, connecting live data to accumulated knowledge to concrete next steps.
Architecture
There are four layers:
Data sources — live fitness and health data from connected platforms, accessed via MCP servers. The athlete chooses which services they use. Each MCP server exposes tools for querying activities, metrics, and history. A few options:
- Strava MCP — activities, stats, segments, routes, heart rate and power data, personal records. Probably the most universal starting point for cyclists.
- TrainingPeaks MCP — workout management, performance analysis, athlete settings, health metrics, equipment tracking, events, training plan libraries. The most comprehensive for structured training.
- Garmin MCP — activities, health metrics (steps, heart rate, sleep, stress, respiration, HRV), training status, devices, gear, weight, nutrition. The broadest health data beyond just cycling.
- Wahoo MCP — workouts, routes, training plans, power zones. Leaner, focused on the essentials.
- Health and wellness MCPs — Apple Health, Oura, Whoop, or similar for sleep quality, HRV, readiness scores, stress trends. These feed the supporting pillars (recovery, sleep, stress) if the athlete has the devices and wants to connect them.
- Or a different MCP server provided by the user.
You don't need all of these. Most cyclists use one or two platforms as their primary ecosystem. One MCP connection is enough to start. Add more data sources as the coach matures and you discover what data is actually useful for your coaching decisions.
The knowledge base — a directory of LLM-maintained markdown files in an Obsidian vault. Training plans, workout analyses, event pages, reference material, an evolving overview of the athlete. The LLM owns this layer entirely — it creates pages, updates them after workouts, maintains cross-references, and keeps everything consistent. The athlete reads it in Obsidian; the LLM writes and maintains it. This is the coach's memory.
The schema — a document (e.g. CLAUDE.md for Claude Code) that tells the LLM how to coach. Training methodology preferences, zone definitions, how to structure plans, what metrics to prioritize in workout analysis, how to handle missed workouts, when to push harder vs. back off. This is the key configuration file — it's what makes the LLM a disciplined coach with a philosophy rather than a generic chatbot that knows about cycling. You and the LLM co-evolve this over time as you figure out what coaching style works for you.
Task output — actionable items pushed to a task manager. Training plans aren't useful if they stay in a wiki — they need to become concrete tasks with due dates. The coach pushes daily workouts, meal plans, and grocery lists to Todoist via the official Todoist MCP server, so the athlete's day is organized and the plan actually gets followed. Other task managers with MCP integrations would work too — Todoist is the recommended default.
Knowledge organization
The project root is an Obsidian vault. The knowledge base is organized into dedicated directories for high-volume content types, a general wiki for everything else, and immutable source material:
Source material (sources/) — immutable reference material. Books, PDFs, articles, research papers about training methodology, nutrition science, supplementation, biomechanics, recovery protocols. Binary files (images, PDFs) go in sources/assets/. The athlete drops files here; the LLM reads and integrates them but never modifies them. This is where coaching knowledge comes from — not just what the LLM already knows, but specific material the athlete wants the coach to learn from. Examples: chapters from Training and Racing with a Power Meter, a paper on polarized training adaptations, an article about periodized nutrition, a supplement protocol from a sports nutritionist. The more specific the sources, the more tailored the coaching becomes.
Training plans (plans/) — structured, periodized plans. A training plan includes time on the bike (structured intervals, endurance rides, recovery spins), gym and strength work (supporting exercises for cycling performance), and meal guidance (nutrition aligned with training load). Plans are organized by time horizon — macrocycles covering months of periodization, mesocycles covering training blocks, and weekly schedules with specific sessions. Plans are living documents: the coach updates them based on how the athlete responds to training, whether workouts are being completed, and how recovery metrics look.
Workout analyses (analyses/) — saved analysis of individual workouts or training blocks. Each analysis captures what was prescribed, what was actually executed, key metrics (normalized power, intensity factor, TSS, heart rate drift, power distribution, time in zone, RPE), how the execution compared to targets, and coaching notes. This is what makes the coach's feedback improve over time. The 50th workout analysis is dramatically more valuable than the 5th — by then the coach has a written record of how you respond to threshold work, how your performance correlates with sleep, whether you tend to start intervals too hard, how long it takes you to absorb a training load increase. Patterns emerge that no single-session LLM interaction could discover.
Events (events/) — specific events the athlete is training for. Races, gran fondos, charity rides, personal challenges like a first century or a target time on a local climb. Each event page includes the date, distance and elevation profile, goals (finish time, placing, just finish, have fun), and a link to the training plan built for it. Events drive periodization — the coach works backward from event dates to structure base building, build phases, sharpening, and tapering. Multiple events get priority-ranked (A-race vs. B-race vs. tune-up), and training periodization reflects those priorities. Without events, training can still be structured around general fitness, but events give the plan a focal point and a timeline.
Reviews (reviews/) — weekly or periodic training reviews. Each review compares planned vs. actual training load, assesses compliance, tracks fitness trends (CTL/ATL/TSB), flags concerns, and recommends adjustments for the coming period. Reviews are the coach stepping back from individual workouts to look at the bigger picture.
Wiki (wiki/) — LLM-maintained pages for lower-frequency content types (meal plans, source summaries, entity pages, concept pages, deep-dive analyses, comparisons) plus infrastructure files. All pages use YAML frontmatter, [[wikilinks]] for cross-references, and a type prefix for consistent naming (e.g., wiki/mp-2026-w16.md for a meal plan, wiki/s-polarized-training.md for a source summary). A workout analysis, for example, carries frontmatter with date, sport, TSS, normalized power, intensity factor, heart rate data, RPE, and a link to the prescribed workout — enabling Dataview tables that track training load over time.
Three infrastructure files in wiki/ keep the knowledge base navigable:
index.md — a catalog of everything in the knowledge base, organized by page type. Each page listed with a wikilink, a one-line summary, and the date. The LLM reads this first when it needs to find something. At moderate scale (a season's worth of analyses, a handful of plans) the index is sufficient for navigation.
log.md — a chronological record of what happened and when. Workout analyses, plan updates, source ingestions, reviews. Each entry starts with a parseable prefix: ## [2025-03-15] analyze | Saturday Group Ride. Operations: ingest, query, lint, update, create, analyze, plan, review. The log gives both the LLM and the athlete a timeline of the coaching relationship.
overview.md — the coach's current assessment of the athlete. Current form, fitness, and fatigue. Recent trends. Upcoming events and how training is tracking toward them. Active concerns (overreaching, missed workouts, nutrition gaps). Think of it as what a human coach would say if you asked "where am I at right now?" This page gets updated frequently — after workout analyses, after reviews, after significant plan changes.
Operations
Ingest sources. The athlete adds reference material to sources/ — a book chapter on periodization, an article about fueling for long rides, a research paper on caffeine timing. The LLM reads it, discusses key takeaways with the athlete, writes a summary page (wiki/s-<slug>.md), and integrates relevant concepts into the knowledge base. If the source material challenges or refines the current coaching approach, the schema may get updated too. For example, ingesting material on polarized training when the current plan follows a sweet-spot approach might trigger a conversation about methodology and potentially a plan revision.
Analyze workouts. This is the core coaching loop. The coach pulls recent activity data from the connected MCP server(s), reads the prescription from the current training plan, and writes an analysis page comparing the two. What went well, what deviated, what the metrics suggest, and whether adjustments are needed. The analysis considers context from the knowledge base — how this workout fits into the current training block, how the athlete has responded to similar sessions before, whether recovery metrics suggest the athlete was fresh or fatigued. After writing the analysis, the coach updates the overview if the athlete's picture has changed meaningfully.
Plan training. The coach builds or updates training plans based on the athlete's current fitness (pulled from MCP data), upcoming events, recent workout analyses, the training methodology defined in the schema, and reference material from ingested sources. Plans include bike workouts, gym/strength sessions, and meal guidance tied to training load. When a plan is ready, the coach pushes individual workouts and meals as tasks to Todoist. Plans should be revisable — if the athlete misses workouts, gets sick, or shows signs of overreaching, the plan adapts rather than marching forward blindly.
Keeping plans in sync. Training plans exist in three places: the knowledge base (plans/), TrainingPeaks (structured workouts on the calendar), and Todoist (weekly task output). These must stay in sync. When the coach adjusts a plan — moving a workout, changing an interval structure, accommodating travel — all three systems must be updated: the wiki plan page, the TrainingPeaks workout, and any affected Todoist tasks. The wiki plan page is the source of truth for the coaching rationale (why this workout, how it fits the periodization); TrainingPeaks is the source of truth for the structured workout the athlete executes; Todoist is the action layer for the current week. If they diverge, the athlete gets conflicting signals. The coach should verify consistency after any plan change.
Manage events. The athlete tells the coach about an upcoming event — a race in October, a gran fondo in June. The coach creates an event page with date, profile, goals, and then works backward to build or adjust training plans. Multiple events get priority-ranked (A-race vs. B-race vs. tune-up), and training periodization reflects those priorities. As events approach, the coach should flag tapering, race-day nutrition, equipment checks, and logistics as appropriate.
Push tasks. The coach pushes actionable items to TraningPeaks (for workouts, if available) or Todoist or equivalent (for the rest): today's structured ride with interval descriptions, this week's gym sessions, meal plans for the next few days, a weekend grocery list. This bridges planning and execution. Claude Code skills (slash commands) provide consistent formatting — /plan-meals to generate and push meal tasks, /grocery-list to aggregate a week's groceries into an organized shopping list. The athlete's Todoist project structure and labeling preferences get captured in the schema once discovered and applied consistently from then on.
Review. Periodically — weekly, bi-weekly, or on request — the coach does a comprehensive review. Read recent analyses, pull fitness trends from MCP data, compare actual training load to planned load, check how the athlete is tracking toward events. Update the overview page. Suggest plan adjustments. Flag concerns: overtraining risk if CTL is ramping too fast, stagnation if there's been no progression in key metrics, inconsistency if workouts are regularly missed or cut short. The review is the equivalent of a weekly call with a human coach — stepping back from individual workouts to look at the bigger picture.
Supporting pillars
The primary focus is on-the-bike training, but cycling performance doesn't happen in a vacuum. The coach tracks and integrates several supporting dimensions, all in service of making the athlete faster and more resilient on the bike:
Nutrition and supplementation. Meal planning tied to training load — higher carbohydrate intake on hard days, recovery-focused meals after long rides, appropriate fueling for rides over 90 minutes. Supplement protocols if the athlete uses them (caffeine timing, creatine, vitamin D, iron for at-risk athletes). The coach draws on ingested sources for evidence-based recommendations and adapts to the athlete's dietary preferences and restrictions.
Sleep and recovery. If the athlete connects a wearable (Oura, Garmin, Apple Watch, Whoop) via an MCP server, the coach can factor sleep quality, HRV trends, and readiness scores into training decisions. A bad night's sleep might mean converting a threshold session to endurance. Chronically poor sleep might prompt a plan revision. Even without wearable data, the coach can track subjective recovery from athlete check-ins.
Stress management. Training stress doesn't exist in isolation from life stress. HRV trends, readiness scores, and athlete-reported stress levels help the coach modulate training load. The goal isn't to build a stress management program — it's to make smarter training decisions by accounting for the athlete's total load.
Strength and gym work. Supporting exercises for cycling performance: core stability, hip flexor mobility, single-leg strength, upper body endurance for long days in the saddle. Injury prevention exercises if the athlete has known vulnerabilities. These get included in training plans and pushed as Todoist tasks alongside bike workouts.
These pillars are supporting, not primary. If the athlete doesn't connect a sleep tracker or doesn't care about meal planning, the coach still works — it just has less data to work with. The pattern is modular: plug in what's useful, leave out what isn't.
TrainingPeaks integration and skills (if available)
TrainingPeaks is where the training programs are scheduled and uploaded. Use the MCP server (https://github.com/JamsusMaximus/trainingpeaks-mcp) to create and schedule the traning tasks for the athlete:
Training tasks. Individual workouts with structured descriptions. A training task includes the session type (intervals, endurance, recovery), duration, target zones or power ranges, and any specific instructions. Example: "Threshold intervals — 3x12min @ 95-100% FTP, 5min recovery between, 15min warmup/cooldown. Total ~90min."
Todoist integration and skills
Todoist is the action output layer — where plans become tasks and tasks become things the athlete actually does. The integration works through the official Todoist MCP server (https://ai.todoist.net/mcp).
Two categories of tasks:
Meal tasks. Daily meals aligned with the training plan. Hard training days get more carbohydrate-heavy meals; rest days shift toward protein and vegetables. Each meal task includes a brief description or recipe reference. The coach adapts to the athlete's dietary preferences (which are tracked in the knowledge base).
Grocery lists. Aggregated shopping lists derived from the meal plan. Instead of per-meal ingredient lists, the coach batches a week's groceries into a single organized list — produce, proteins, dairy, pantry staples — with quantities. This is one of the most practically useful outputs: it turns an abstract meal plan into something you can carry into a grocery store.
Claude Code skills provide consistent formatting for these workflows:
/plan-meals— generates a meal plan for a specified period (default: the coming week), aligned with the training plan, and pushes meal tasks to Todoist with consistent formatting, labels, and due dates./grocery-list— reads the current meal plan, aggregates all ingredients, organizes them by grocery store section, adjusts quantities, and pushes a single shopping list to Todoist.
Additional skills may emerge as the coaching relationship develops — /weekly-review, /analyze-ride, /prep-event — whatever workflows the athlete and LLM find themselves repeating. The schema should document the Todoist project structure, label conventions, and task formatting preferences so that all skills produce consistently organized output.
Tips and tricks
- Start with one MCP server. Strava or Garmin Connect are the most common starting points for cyclists. You can always add more data sources later. The coach works fine with a single source of activity data.
- Let the schema evolve. The first version of CLAUDE.md will be rough — probably just zone definitions, basic methodology preferences, and minimal conventions. After a few weeks of workout analyses and plan adjustments, you'll know what the coach should focus on, what metrics matter most, and what coaching style you prefer. Update the schema to capture these. The schema should get more opinionated over time, not less.
- The overview page is your dashboard. It should always reflect the coach's current understanding of your fitness, fatigue, form, and priorities. Open it in Obsidian when you want a quick status check. If it feels stale, ask for a review.
- Obsidian Dataview is especially useful here. If the LLM adds YAML frontmatter to analysis pages (date, TSS, IF, NP, duration, RPE), Dataview can generate dynamic tables showing training load over time, weekly TSS totals, or progression in key metrics. This turns the wiki into a lightweight analytics dashboard.
- Obsidian's graph view shows connections between events, plans, analyses, and sources. Useful for seeing how a training methodology connects to specific workouts, or how an event drives the structure of a training block.
- Common methodologies worth exploring: polarized training (80/20 easy/hard split), sweet-spot (high volume at 88-94% FTP), pyramidal (most time in Z1, less in Z2, least in Z3+), block periodization (concentrated training stimuli). The coach doesn't need to pick one on day one — the methodology can evolve as the athlete and coach learn what produces results. The schema captures the current approach.
- Filing analyses compounds. The 50th workout analysis is dramatically more valuable than the 5th. By then the coach has documented patterns: how you respond to rest weeks, whether your heart rate decouples on long rides, how your power numbers change with temperature, what RPE mismatch looks like for you. These patterns aren't available to a fresh LLM session — they only exist because the knowledge base accumulated them.
- The knowledge base is just a directory of markdown files. It can be a git repo for version history, synced via iCloud or Dropbox for mobile access in Obsidian, or kept purely local. The files are yours.
Why this works
The hard part of self-coaching isn't knowing what a good interval session looks like — any LLM can generate a training plan from scratch. The hard part is the bookkeeping. Tracking TSS trends over weeks. Noticing when CTL is climbing too fast. Remembering that you always fade in the third interval of VO2max sets and maybe need to adjust the prescription. Connecting the fact that your worst workout weeks correlate with poor sleep. Adjusting the plan because a work trip disrupted three days of training. Humans abandon structured training because the cognitive overhead of managing a plan, tracking execution, analyzing results, and adjusting course — on top of actually doing the workouts — is exhausting. A human coach handles this overhead for you. The LLM does the same thing, at a fraction of the cost, with 24/7 access to your data.
The human's job is to ride the bike. And to choose goals, provide honest feedback on how workouts felt, steer the coaching philosophy, and ask the right questions. The LLM does the planning, analysis, meal prep logistics, record-keeping, and all the tedious cross-referencing that makes a coaching relationship actually work over time.
What makes this different from asking ChatGPT for a training plan: compounding knowledge. A fresh session can give you a reasonable 12-week plan. But it doesn't know that your FTP jumped 15 watts after a block of polarized work last winter, that you respond better to three-day training blocks than four-day ones, that you're prone to saddle sores on rides over four hours, that you tend to under-fuel on Saturday long rides, or that your A-race is a hilly gran fondo in September with 3000 meters of climbing. The knowledge base holds all of this. Every workout analysis, every ingested source, every plan revision makes the coach more specifically yours.
The closed loop is what distinguishes a coach from a dashboard. Plan. Execute. Analyze. Adjust. Most training apps stop at "plan" or "track." The wiki is the memory that connects all four steps — the coach can prescribe a workout, see how it was actually executed, analyze whether the athlete is absorbing the training load, and adjust future prescriptions accordingly. This loop runs on every workout, and the knowledge base ensures that insights from one cycle inform the next. Over a season, the compounding effect is significant.
Note
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the page naming conventions, the schema details, the zone calculation methodology, the Todoist project hierarchy, which MCP servers to connect — all of that will depend on your platforms, your goals, your training philosophy, and your LLM of choice. Everything mentioned above is optional and modular. You might not want meal planning and just want ride analysis. You might not use Todoist. You might train by feel and only want the coach to analyze after the fact rather than prescribe. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.