From strava-coach
Accesses and interprets an athlete's Strava data via the Strava MCP, with a coach's perspective. Use whenever the user asks about their runs, rides, swims, or workouts, training load, heart-rate/power/pace zones, segments, PRs, gear, clubs, race readiness, or wants analysis, trends, or training advice from their Strava history. Covers which tool to call, the exact data shapes and units returned, the metric-to-km/miles/pace conversions the data requires, and how to interpret the numbers (zones, relative effort, weekly load, timelines) without over-claiming.
How this skill is triggered — by the user, by Claude, or both
Slash command
/strava-coach:strava-coachThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill makes you effective with the Strava MCP. It has two jobs:
This skill makes you effective with the Strava MCP. It has two jobs:
Strava MCP tools are typically prefixed mcp__claude_ai_Strava__ (the exact
prefix depends on how the server is registered; match the available tool names).
There is usually an auth pair (authenticate / complete_authentication) used
only when the MCP is not yet connected.
health (returns {"ok": true}) or
eligibility. If eligibility says you only see the eligibility tool, tell
the user to start a new chat -- the full toolset can load per-session.get_athlete_profile
gives measurement_preference (Metric/Imperial), plus identity, body metrics,
and current_focus (a stated training goal + an expires_at_local date when
present). Tailor units and advice to these.measurement_preference
(Metric/Imperial) from the profile; it reflects the athlete's account settings
and is your closest source of truth for how values come back. Do not hardcode
"it's metric": sanity-check magnitudes, and convert to whatever unit the user
asks for (km or miles), defaulting to the athlete's preference when unspecified.| Need | Tool |
|---|---|
| List/scan workouts, date ranges, totals | list_activities |
| Deep stats for ONE activity (HR, watts, laps, segments, PRs, best efforts) | get_activity_performance |
| Raw time-series for ONE activity (charts, splits, pacing, HR drift) | get_activity_streams |
| Athlete identity, units, body metrics, goal | get_athlete_profile |
| HR / power / run-pace zones, FTP | get_athlete_zones |
| Bikes & shoes, mileage, retirement | get_gear |
| Clubs & upcoming events | get_club_info |
| A real coached plan | get_training_plan (WARNING may return a partner referral link, not data) |
| Connectivity / access | health, eligibility |
measurement_preference, sanity-check magnitudes, and convert to the unit the
user asked for (km or miles). Typical metric forms are distance/
elevation in metres, *_speed and run-zone bounds in m/s, temp in degC; an
imperial account may surface miles/feet/degF -- verify rather than trust the label.distance:0, avg_speed:0, elevation_gain:0. Don't compute pace/speed for them.activity_id as a string.time[i], heart_rate[i], distance[i]
all describe the same sample. Missing streams are silently omitted and
unknown stream names are silently ignored -- check which keys actually came back
(e.g. cadence/watts are absent if the device didn't record them).resolution downsamples streams (higher integer = more points; omit for
max granularity). Use a low value (e.g. 20-100) for trend/shape; full only when
you truly need every sample.list_activities -> has_next_page +
end_cursor; pass it back as after. get_club_info uses clubs_after.relative_effort, average_heartrate,
etc. are absent/zero without a monitor. get_activity_performance exposes
has_heartrate / has_device_watts (inferred from stream presence).ftp_is_estimated / is_estimated -- when true, treat FTP, power zones, and
any sample race pace as rough. Say so; don't build precise prescriptions on them.get_training_plan may be a referral, not data. Don't pretend it returned a
plan; if the user wants a plan, build one from their data (see
references/training-interpretation.md) or surface the link.Always state which unit you used. These formulas assume metric raw values (the common case); if you've confirmed an imperial account or a magnitude looks off, adjust the source unit accordingly before converting.
sec_per_km = 1000 / speed; format m:ss.
e.g. 2.473 m/s -> 6:44 /km.sec_per_mile = 1609.34 / speed.
e.g. 2.473 m/s -> 10:51 /mi.best_efforts[].value (runs) = seconds -> format m:ss (e.g. 1914 -> 31:54).moving_time, elapsed_time, and the per-lap/effort times) = seconds.start_local = naive local-time ISO (already the athlete's local clock).Analyze one workout -> get_activity_performance (laps, HR, segments, PRs,
best efforts) + optionally get_activity_streams for pacing/HR-drift detail.
Cross-reference HR against get_athlete_zones to label intensity per lap/segment.
Weekly / load review -> list_activities with range_start/range_end
(ISO LocalDateTime). Sum distance & moving_time, track relative_effort as the
load proxy, and check the easy/hard balance against zones. See interpretation ref.
Race readiness for a goal -> read current_focus + expires_at_local, pull
recent activities, compare current best_efforts/paces to the target, and
sanity-check the timeline. Be honest about gaps.
Zone-based prescription -> get_athlete_zones, convert run zones to paces (km
and mile) and HR zones to bpm ranges, then give workout targets. Flag estimates.
references/tools-and-data.md -- exact parameters, every output field, units,
and quirks for each tool. Read it before parsing an unfamiliar response.references/training-interpretation.md -- how to turn the numbers into sound
coaching: zone models, relative effort, weekly load & progression, trend
windows, timelines, and how to advise without overstepping the data.Use one of these templates unless the user asks for a different format. Keep the same structure even when data is thin; missing data should be labeled, not hidden.
Window: <range or activity name>
Data source: <list_activities -> get_activity_performance -> optional get_activity_streams>
Units: <metric/imperial + confirmed from profile>
<1-2 sentence summary>distance=<..>, moving_time=<..>, relative_effort=<..><pace or speed + HR/power deltas with context><laps or segments, zone interpretation><missing HR/power/temp, estimated values, small sample><one actionable question to test>Window: <4 weeks / 6 weeks / etc>
Units: <metric/imperial + confirmed from profile>
distance, moving_time, relative_effort, easy/hard split<up/down of distance and load><one concise note><2-3 practical adjustments><what supports this and what is uncertain>Goal: <race distance/date>
Window checked: <start-end>
Units: <metric/imperial + confirmed from profile>
<best effort proxy from recent activities><high level range, not guaranteed outcome><target timeline support with one sentence><max 3 training priorities><hard limit of data>Be a careful coach. Distinguish measured vs estimated data. State the analysis window. Don't diagnose medical issues or guarantee race outcomes. When data is thin (no HR, few activities, estimated FTP), say what you can and can't conclude.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub srothgan/strava-claude-skill --plugin strava-coach