I wanted to run a 10k in under 40 minutes. These days you’d just grab an app for that: Runna or Garmin Connect will build you a plan and coach you through it. Instead I had Claude Code build me one from scratch, ground it in my own running data, and wire it up so it keeps updating itself as I train.

What I ended up with is less a training plan than a small automation system: a couple of Claude skills that read my health data, design the plan and write it into Notion, then keep it current as I train. The running goal is just what I pointed it at. The interesting part is how the pieces fit together.

Built From My Own Data

The first thing the system does is ground the plan in real data, not a template.

Claude pulled my last nine weeks of activity from Apple Health and analyzed 20 actual runs. The data access runs through my HealthExport CLI, wired up as a skill, which I wrote about here. It found an easy pace of 5:30–6:00/km at a heart rate of 130–143, a genuine aerobic base left over from my marathon years, plus a couple of harder May efforts around 4:50–4:55/km. It also noticed my benchmark 10k was run on a hilly forest trail with 200 m of climb, so my flat-road fitness was probably closer to 44–46 minutes, a bit better than the 47 I’d quoted.

That detail mattered. The plan got calibrated to my physiology and my habits, not to an average runner’s.

It Asked Before Building

Before writing a single row, the agent did two things I’d want from any coach. It researched current best practice for a sub-40 10k: periodization through base, build, peak, and taper, an easy-to-hard split of roughly 75/25, and the standard menu of quality sessions (threshold, VO2max intervals, race-pace work). Then it interviewed me.

The questions were the high-leverage ones, not a generic intake form: how many days a week I’d actually run, how long my long run could get, and how I wanted to schedule. It folded the answers in, laid out the whole plan for approval, and only then built anything.

The Plan

What it produced is 17 weeks long, moving through Base, Build, Peak, and Taper, with about 75% of running easy. Two quality sessions a week, one easy or cross-training day, and one or two strength sessions that taper off near race day. No fixed weekdays: I asked it to track completion per week, so the plan bends to whatever my week looks like.

Phase Weeks Focus
Base 1–5 Aerobic foundation, early tempo work
Build 6–11 VO2max intervals, longer threshold reps
Peak 12–15 Race-pace work, sharpening
Taper 16–17 Reduce volume, stay sharp, race

The paces are anchored to the goal and recalibrated from my data:

Zone Pace (min/km) Use
Easy / recovery 5:40–6:10 easy & cross day
Long run 5:15–5:45 weekend base
Threshold 4:25 → 4:10 tempo
10k goal pace 4:00 race-specific reps
VO2max 3:50–3:58 1 km reps

Two calibration races are built in: an all-out baseline 10k in week 2 to anchor the starting prediction, and a tune-up 5k in week 13 to recalibrate near peak. Both feed the prediction model directly.

How It Lives in Notion

Everything sits in a single Notion page. The top of it shows the goal, the race details, the weekly template, and one prominent line: my current predicted race time.

Below that are two databases. A Training Log with one row per planned workout (51 rows, 17 weeks times three sessions) that tracks status, actual distance, pace, and heart rate. And a Prediction Log, a time series of every predicted finish time with the reasoning behind it, so I can watch the trend of my projected race time across the whole block instead of just the latest guess.

The Feedback Loop

This is my favorite part. I had Claude build a reusable skill called sync-runs, and now when I say “sync my runs,” it runs the whole loop:

  • Pulls my runs from Apple Health since the last sync.
  • Classifies each one by intensity from pace, heart-rate zones, and distance.
  • Matches each run to that week’s planned slot and updates the row: Done, Modified, or Missed, plus actual numbers and a one-line note (“10 s/km faster than target at lower heart rate, fitness trending up”).
  • Recomputes my predicted race time from real data, preferring my most recent all-out effort projected to 10k via the Riegel formula (a standard race-time predictor), then logs it.
  • Proposes adjustments to upcoming weeks, nudging paces faster if I’m ahead or easing them if I’m struggling, and shows me the changes before writing anything.

The self-updating training loop: run, sync, measure, re-predict, adjust, with a dashed arrow looping back from adjust to run.

A one-off plan became a closed loop I drive with a single sentence: run, sync, measure, re-predict, adjust. Most training plans are dead the moment you deviate from them. This one absorbs the deviation and tells me what it means.

Takeaways

  • Build the loop, not just the artifact. A static plan is dead the moment you deviate. A system that re-syncs, re-predicts, and adjusts stays useful as real life happens.
  • Compose small skills into a system. One skill reads my health data, another reasons over it and writes to Notion. The whole thing is assembled from reusable parts.
  • Ground it in real data, not a template. The plan came from my own runs, paces, and heart rate. That is the difference between generic and personal.