HN 표시: LLM 사이클링 코치를 위한 아이디어 파일

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. 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. 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. 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. 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-.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 progress