Live
Powered by

TrainingPeaks publish instructions: July 8 to September 13 calendar

  • Prepared: 2026-07-07 by Cowork session, for execution by the OpenClaw instance (Coach Luca) or any session with the trainingpeaks-mcp tools connected
  • Scope: create-only publish of the planned activities in athlete/calendar/2026-07-08.md through athlete/calendar/2026-09-13.md
  • Authority: operator explicitly requested this live TrainingPeaks publish on 2026-07-07, which satisfies the operating-mode gate in athlete/settings.yml and the athlete supplement skill

Hard rules

  1. Create only. Do not edit, move, or delete any existing TrainingPeaks activity, workout, event, or note. Sidney's live calendar is otherwise managed by Gunnar Holmgren.
  2. Target athlete ID 1575220 explicitly on every call. Do not rely on default athlete resolution; it has a known bug in this environment (/users/v3/user returns 402).
  3. Verify auth first (tp_auth_status). If stale, run the browser auth flow via the tp-mcp CLI, then re-check.
  4. Read back every item after create. Trust the readback, not the request. If event type or priority does not persist, report it rather than assuming.
  5. Follow the shared skill skills/trainingpeaks-activity-creator/SKILL.md and the athlete supplement athlete/skills/trainingpeaks-activity-creator/SKILL.md. Highlights: Canadian English ("Fuelling"), no provenance text in descriptions, luca tag on every created item, no planned start times, no redundant sport prefixes in titles.

Pre-publish checks

  1. tp_auth_status — confirm authenticated.
  2. tp_get_athlete_settings for athlete 1575220 — confirm the live power zones still match athlete/context/power-zones.md (Z1 0-145 ... Z6 315+, FTP ~260). All calendar structured steps are written as %FTP, so a zone-table mismatch does not block publishing, but report any drift.
  3. tp_get_workouts for 2026-07-08 to 2026-09-13 — list anything already on the calendar in the window. Report pre-existing items; do not touch them. If a pre-existing item collides with a planned day, publish ours anyway and flag the collision.

Publish procedure

Process the calendar files in date order. For each ## activity section in each athlete/calendar/YYYY-MM-DD.md file:

  1. Map the activity to a TP object:
    • Kind: workout, Discipline bike → tp_create_workout, sport Bike. Use the CX activity subtype for Surface: cx days if supported.
    • Kind: workout, Discipline strength → tp_create_workout, sport Strength. Description from the Workout section. No structure needed.
    • Kind: workout, Discipline run → tp_create_workout, sport Run.
    • Kind: rest → follow the June pattern (rest days were published as TP items, e.g. 2026-06-18 → TP 3779663712): create as Day Off / rest workout type with the Workout text as description.
    • Kind: travel → same pattern as rest days, title as written (e.g. "Travel to Vermont").
    • Kind: event (2026-09-13 Canmore C2 only) → tp_create_event, priority C (season opener per context/season-goals.md hierarchy: A = PanAm/Worlds, B = Nationals/Charm City, C = other NA C1/C2). Event type cyclocross if supported, otherwise closest supported fallback. Also verify readback of type and priority per skill.
  2. Title: use the calendar activity Title verbatim.
  3. Description: concatenate the ### Workout text, then a blank line, then Fuelling: ... from the ### Fuelling section, then ### Notes text if present. Canadian English spelling throughout.
  4. Structure: when the file has a ### Structured workout section, build the structure JSON from it (primaryIntensityMetric percentOfFtp, steps and repetition blocks as listed, durations in seconds). Let the server derive duration and TSS. Skip structure for test days with "maximal even effort" steps if validation rejects them; publish those with description only and report it.
  5. Duration: from the Duration field (use the lower bound of ranges like "3:30-4:00").
  6. Tags: luca.
  7. After each create: read the item back by ID, confirm date, title, sport, and structure presence.
  8. Writeback: replace the - TrainingPeaks ID: pending line in the source calendar file with - TrainingPeaks ID: <returned id> for the matching activity section only. Two-activity days get two IDs, one per section.

Completion report

Report: total items created by type, all workout IDs, any pre-existing items found in the window, any validation failures and how they were resolved, any readback mismatches, and confirmation that every calendar section now carries a real TrainingPeaks ID (grep the range for TrainingPeaks ID: pending — it should return nothing).