fitness-brief

Fitness Brief

One skill, two lenses on the same athlete's training state. Composition is intent-driven, not scripted: gather a bounded digest, then write the brief toward the goal below in the operator's configured voice — there is no fixed section order, no hardcoded tone, and no mandatory rest-day copy.

Flags

• --morning: slot morning. Forward-looking.
• --evening: slot evening. Backward-looking.
• --slot <name>: custom slot label; orientation defaults to forward-looking unless the operator's own conventions say otherwise.

Resolve <slot> from the flag before starting. Filenames below use that resolved value. Steps below say "Morning"/"Evening" as shorthand for forward-looking/backward-looking orientation — a custom --slot follows whichever branch matches its resolved orientation.

Steps

1. Connectivity + sync mechanics. These fold in what strava-health-check and strava-sync used to run on their own crons — this brief now owns that beat.

   • Call mcp__strava__check-strava-connection. If disconnected: say so plainly in the brief and skip the data-dependent parts below rather than fabricating figures.
   • Evening only: call mcp__strava__get-recent-activities (perPage: 5), compare against state/strava-last-activity-id.txt (treat missing as "none"), and for any new activity whose Strava type is Run, invoke /claude-code-fitness-hermit:activity-deep-dive <id> (cap 3 — log skipped IDs to SHELL.md Progress Log past the cap). Advance the cursor file to the highest new ID. Hold the newest new activity's id/name/sport for step 4 — do not write state/strava-pending-rpe.json here. That file's writer contract (see docs/knowledge-schema.md and CLAUDE.md § Memory Conventions) is write-only-after-confirmed-delivery, precisely so a failed or push-only send can't bind a future RPE reply to an activity the operator was never actually told about.

2. Gather (bounded). Raw Strava streams must never enter context — fitness-lab.ts reduces them first.

   • Morning: bun ${CLAUDE_PLUGIN_ROOT}/scripts/fitness-lab.ts weekly-load — a rolling per-week load digest (km, moving time, zone %, tss_proxy). Read state/strava-weekly-baselines.json if present for trend context.
   • Evening: if a new activity was found in step 1 and it was not a Run (step 1 only deep-dives Run activities), bun ${CLAUDE_PLUGIN_ROOT}/scripts/fitness-lab.ts analyze <the non-Run activity's id from step 1> for today's session — pass the id explicitly, not latest: latest resolves the globally most-recent Strava activity, which on a mixed-type day (a Run uploaded after the non-Run) would analyze the wrong session. If the new activity was a Run, step 1's activity-deep-dive call already ran this same analysis and wrote compiled/activity-<id>-<date>.md — read that artifact instead of re-running the analysis, which would redo the same Strava fetch and computation. Either way, also read whatever state/activity-notes.json already holds for it. No new activity is itself the input — there's nothing to analyze.