gtapps/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.

   Handle the script's error contract as activity-deep-dive does: {"error":"strava_auth",...} or {"error":"fetch",...} (both exit 1) → relay the message to the operator and stop gathering further data; compose from whatever was already gathered.

3. Compose. You have the digest from steps 1–2, the operator's voice (agent_name, sign_off, operator_profile, language in config.json — the same voice every other channel message uses), and the goal below. Write toward the goal; there is no required template.

   • Morning goal: give the operator what's worth knowing and doing today — recent load/trend, anything worth flagging, a plan or nudge for today.
   • Evening goal: reflect on what today's training meant. On a day with nothing logged, the rest itself is the information — an earned-recovery day reads very differently from a third silent day in a row; use judgment, don't force a script. Set up tomorrow. If step 1 captured a new activity, invite an RPE reply.
   • The single most recent prior brief lives in compiled/brief-morning-<date>.md / compiled/brief-evening-<date>.md if continuity would genuinely add something — reading just that one file is optional judgment, not a required step. These briefs accumulate daily with no retention cap (per docs/knowledge-schema.md), so never glob-read the whole brief-*.md set.

4. Deliver per the Operator Notification protocol in CLAUDE.md (core resolves the channel and falls back to push / SHELL.md logging when no channel is reachable). Never gate delivery on session_state — routines can fire while the terminal is unmonitored. Push-fallback: a single line per § Operator Notification push format, leading with the thing most worth knowing.

   • Evening only, after a confirmed successful channel send (not a push fallback, not a logged-only send): write state/strava-pending-rpe.json with the activity held from step 1:

     {"activity_id": <id>, "name": "<name>", "sport": "<Run|Ride|WeightTraining|…>", "synced_at": "<ISO 8601>"}
     

     so a channel RPE reply binds correctly (capture-activity-rpe reads and deletes it) — the same write-after-confirmed-send guard documented in CLAUDE.md § Memory Conventions.

5. Archive. Write .claude-code-hermit/compiled/brief-<slot>-<date>.md:

   ---
   title: "<Morning|Evening> Brief — <YYYY-MM-DD>"
   type: brief
   created: <ISO 8601 with offset>
   session: <current session ID from SHELL.md, or null>
   tags: [<slot>-brief, fitness]
   ---
   

   Body: the brief as delivered. Then append - [[compiled/brief-<slot>-<date>]] to .claude-code-hermit/sessions/SHELL.md under ### Artifacts produced this session in ## Monitoring (create the subsection if absent). Lifted into ## Artifacts when /claude-code-hermit:session-close archives the session.

Security

Never include Strava tokens, credentials, or raw athlete IDs in the brief or its archive.