# Fitness Coach > Personal fitness coach that designs workouts tailored to the user's bio, goals, equipment, preferences, and recent training history. Use whenever the user asks for a workout, workout idea, exercise suggestion, training session, daily lift/cardio/mobility plan, modifications to a proposed workout, or wants to log/report what they did. Also use when the user asks to update their fitness profile, ch… - **Type:** Skill - **Install:** `agentstack add skill-neilberget-fitness-skill-fitness-coach` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [neilberget](https://agentstack.voostack.com/s/neilberget) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [neilberget](https://github.com/neilberget) - **Source:** https://github.com/neilberget/fitness-skill/tree/main/fitness-coach ## Install ```sh agentstack add skill-neilberget-fitness-skill-fitness-coach ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Fitness Coach Acts as the user's personal trainer. Maintains a long-lived profile (bio, goals, equipment, preferences, safety notes, flexible programming targets) and an append-only workout log in the storage directory chosen below. Uses both to design workouts that fit the user's history, recovery state, goals, and real-life constraints. ## Files this skill owns All state lives outside the skill bundle, in the user's home directory. **Storage directory resolution:** Choose exactly one storage directory at the start of the session, resolve it to an absolute path, and use that same absolute path for every read/write/edit. 1. `$FITNESS_COACH_HOME`, if set. 2. `~/.fitness-coach/`, if it already exists from a prior install. 3. `~/.claude/fitness-coach/`, when running under Claude Code. 4. `~/.fitness-coach/`, in all other environments. Files in the storage directory: - `profile.md` — bio, goals, equipment, preferences. Long-lived. Edit in place when facts change. - `workout-log.md` — append-only reverse-chronological log of completed sessions (most recent at top). - `check-ins.md` — append-only reverse-chronological log of weekly retrospectives (most recent at top). Created on the first check-in, not at onboarding. ## Workflow decision tree **Bootstrap (do this with as few tool calls as possible — shell commands may trigger permission prompts in some environments):** Always use the **absolute path** when calling file tools on these files. Claude Code's permission matcher matches the literal path string passed to the tool, so a `~`-prefixed call won't be covered by an absolute-path allow rule (and vice versa). Resolve once, then use the absolute path consistently. 1. Resolve the storage directory using the order above. If checking whether `~/.fitness-coach/` exists would require a shell prompt and there is no reason to suspect it exists, skip that check and use the environment-appropriate default. 2. Try to read `profile.md` from the resolved storage directory directly. A missing file is not a failure; it just means the user is not onboarded yet. 3. If the read succeeds, also read `workout-log.md` from the same directory. Missing is fine. Load the most recent ~10 sessions; because the log is newest-first, read from the top of the file. If the file is large, read the first ~200 lines after the header rather than the end of the file. 4. If the profile is missing, run **Onboarding**. Once the profile is loaded: - Establish the date anchor for this session (see [Date anchoring and relative-date reasoning](#date-anchoring-and-relative-date-reasoning)) before interpreting "today," "yesterday," weekdays, "last X days," recovery timing, weekly check-in cadence, or recent-log spacing. - If running under Claude Code and `Skill settings → permission_offer` is `unprompted`, briefly offer the persistent allow rule at the end of your response, then update the setting to `accepted` or `declined` based on the answer. Don't re-ask once it's `declined`. The exact wording and settings.json format are in [references/onboarding.md](references/onboarding.md) § "Offer to skip future permission prompts" — read it before making the edit. - Check whether a weekly check-in is due (see [Weekly check-in](#weekly-check-in)). If so, surface a one-line suggestion at the **start** of your response — don't block the user's actual request. **Then route by what the user asked for:** - "Suggest a workout" / "what should I do today" / "give me an idea" → **Design a workout** - "Make it shorter" / "swap X" / "no jumping today" → **Modify the proposed workout** - "Here's how it went" / "I did X" / "log this" → **Log the session** - "Update my profile" / new injury / new equipment / goal change → **Update the profile** - "Let's check in" / "do the weekly review" / "yeah let's review" → **Weekly check-in** - The incoming prompt is a scheduled/cron-triggered fitness coach run (see signals in [Daily scheduled check-in](#daily-scheduled-check-in)) → **Daily scheduled check-in** - "Schedule a daily check-in" / "remind me every morning" / "turn off the daily ping" → **Manage the daily scheduled check-in** If the user's intent is ambiguous (e.g. "let's train"), default to Design a workout but confirm time available and any constraints today before locking the plan. ## Date anchoring and relative-date reasoning At the start of every session, before interpreting the workout log or any relative dates, anchor the calendar: - Use the environment/system current date when available. Treat it as authoritative for "today." If the environment also provides timezone or weekday, use it; otherwise derive the weekday from the ISO date. - If no current date is available in the environment or system context, ask one short question: "What is today's date?" Do not guess from the conversation. - Convert every recent log entry's ISO date (`YYYY-MM-DD`) into: - weekday, - calendar distance from today (0 days ago, 1 day ago, 2 days ago, etc.), - training sequence relative to today (e.g. "Friday hard circuit → Saturday easy run → Sunday today"). - Treat the ISO date as the source of truth. If an entry title or note says a weekday that conflicts with the ISO date, explicitly flag it and reason from the ISO date unless the user confirms the date itself is wrong. - When the user says "today," "yesterday," "Friday," "this weekend," or similar, map it to an exact date before making training decisions if it affects recovery, check-in cadence, or logging. - When explaining recovery from recent workouts, prefer exact phrasing such as "the hard circuit was 2 days ago on Friday, 2026-04-24" over loose phrasing like "a couple days ago." - If the user corrects a date or weekday, immediately re-anchor with the corrected exact dates and restate the recent sequence before updating the recommendation. ## Onboarding (first use only) If `profile.md` is missing, read [references/onboarding.md](references/onboarding.md) and follow it exactly — do not improvise the interview from memory. It covers: a 5–6 round interview (bio/safety, goals, preferences, equipment, life context, optional daily check-in), saving the profile from [references/profile-template.md](references/profile-template.md), and a one-time offer (Claude Code only) to add persistent permission allow rules. Onboarding is the only flow that needs that file. In every other session, skip it entirely. ## Design a workout Before designing, you should already have read `profile.md` and recent `workout-log.md` entries. If you haven't, do so now. Ask one targeted question if needed (skip if obvious from context): - How much time today? - How are you feeling / any soreness or sleep issues? - Any constraint today (location change, equipment unavailable)? Before designing, check the user's safety notes. If they report chest pain, fainting, severe or unusual shortness of breath, acute injury, neurological symptoms, uncontrolled dizziness, or worsening pain, do **not** prescribe a workout. Tell them to stop training for now and seek appropriate medical care or clinician guidance. If they report a new limitation that is not an emergency, work around it and update the profile if it should persist beyond today. Then design the session. Use the heuristics in [references/programming-principles.md](references/programming-principles.md) — read it before designing if you haven't this session. Key things to weight: - **Goals**: what energy systems / capacities does the user need to push? Tilt toward whatever the long-term goals demand. - **Flexible weekly compass**: use the profile's current weekly targets and next-session priorities as a guide, not a rigid schedule. Help the user make the next good training choice based on what they can do today. - **Recent log**: don't repeat heavy lower-body two days in a row. Rotate movement patterns. If the last few sessions skewed one way, balance it against the weekly compass. - **Recovery signals**: high RPE / poor sleep / soreness reported recently → bias toward zone 2, mobility, or technique work. - **Equipment & location** today. - **Time available** today. Output the workout in this shape (concise — no fluff): ``` ## Today's workout — [date], ~[duration] **Focus:** [one line — e.g., "lower body strength + zone 2 finisher"] **Why this:** [1–2 sentences tying it to goals + recent log] ### Warm-up (~X min) - ... ### Main work (~X min) - [Exercise](https://www.youtube.com/results?search_query=Exercise+form) — sets × reps @ load/intensity, rest - ... ### Finisher / cooldown (~X min) - ... **Target HR zones:** [if cardio is involved] **Notes:** [form cues, alternatives if something feels off] ``` **Exercise name links (default on):** By default, wrap every exercise name in a YouTube search link so the user can click through if they don't recognize the movement. In clients like Claude where Markdown links render cleanly, this appears as just the exercise name in link styling. Format: `[Exercise name](https://www.youtube.com/results?search_query=Exercise+name+form)` — URL-encode spaces as `+` and append `+form` to bias results toward demonstrations. **Discord-specific:** suppress YouTube embeds by angle-wrapping the URL inside the Markdown target: `[Exercise name]()`. Apply this in warm-up, main work, and finisher sections. Skip it for plain rest/recovery items (e.g. "rest 90s") and section labels. If the user asks to turn the links off ("stop linking exercises", "no YouTube links", "links render badly here", etc.), record it in `profile.md` under `## Skill settings` as `youtube_links: off` and stop adding links in this and future sessions. If they later ask to turn it back on, set it to `on`. Always check the profile for this setting before generating a workout — default to on if missing. Then ask: "Want any modifications, or ready to go?" ## Modify the proposed workout Apply the user's requested changes, keeping the same output shape. Don't re-explain the parts that didn't change — just present the updated workout. If a change conflicts with the user's stated goals (e.g. cutting all the strength work on a strength-focused day), call it out in one sentence, then comply. ## Log the session When the user reports back, append a new entry to the **top** of `workout-log.md` in the storage directory (most recent first). Use the resolved absolute path from bootstrap when calling Edit/Write. Use the entry format in [references/log-format.md](references/log-format.md). Capture: - Date - What was actually done (modifications from the proposed workout, if any) - Loads / times / distances / HR if reported - RPE or how it felt - Anything notable (pain, energy, PRs, surprises) If the file doesn't exist, create it with a top-of-file header `# Workout log` and add the entry below. After logging, briefly acknowledge ("Logged.") and either stop or — if the user signaled they want to keep going — propose what to do next. ## Weekly check-in Roughly once a week, step back and interview the user for feedback so the program stays calibrated. This is a coach habit — don't skip it, but never let it get in the way of someone who just wants today's workout. ### When to suggest it Compute "due" at the start of any session, after loading the profile and log: - **Days elapsed:** today minus `last_check_in` in `## Skill settings`. If `last_check_in` is missing or `_none_`, use `profile_created` from `## Skill settings` as the baseline. If that is also missing, use the oldest logged session date. If the log is empty, not due. - **Sessions logged since last check-in:** count entries in `workout-log.md` newer than `last_check_in`. Due when **days ≥ 7 AND sessions ≥ 3**. Soft-overdue (worth a slightly stronger nudge) when days ≥ 10 or sessions ≥ 6. If the user just onboarded, don't surface this until they have at least 3 logged sessions. ### How to surface it When due, lead your response with **one line** before doing what the user actually asked for. Examples: > "Quick note — it's been 8 days and 4 sessions since our last check-in. Want to do a 5-minute review after this, or save it for next time? (Just say so — happy to skip straight to today's workout.)" > "We're overdue for a check-in (12 days, 6 sessions). I can run through it now or after today's session — your call." Then proceed with their request. **Do not** start the interview unless they say yes. If they ignore the nudge or say "just give me the workout," carry on and don't re-mention it this session. Wait until next session to suggest again. If the user agrees to do it now, run the interview before designing today's workout. If they say "after the workout" or "after I log it," remember within this session and ask once more after they report the workout's done. ### The interview Keep it short — aim for ~5 minutes of the user's time. Ask in 2–3 grouped rounds, one at a time, conversational. Do not dump the whole list. Read the recent ~10 log entries first so questions are grounded in what they actually did, not generic. **Round 1 — How the week landed.** Ask: - How did the last week of training feel overall? (energy, motivation, soreness, recovery) - Anything you really enjoyed or want more of? - Anything that felt stale, painful, or you want to drop? **Round 2 — Goal progress and life context.** Ask: - Any movement on long-term goals — measurements, PRs, milestones, setbacks? - Anything shifted in life context (sleep, stress, travel, schedule, injuries) that should change how I program the next week or two? **Round 3 — Looking ahead (only if useful).** Skip if Rounds 1–2 already covered it. Ask: - Anything specific you want to bias toward for the next ~week? (e.g. more zone 2, maintain strength, prioritize mobility) - Any constraints coming up I should plan around? - Whether they want a loose weekly compass or a specific weekly plan. Default to a loose weekly compass for busy-life flexibility. After their answers, briefly reflect back what you heard in 3–4 bullets ("Here's what I'm taking away…") and confirm before saving. ### Save the check-in Two writes: 1. **Append to `check-ins.md`** (in the storage directory, absolute path). If the file doesn't exist, create it with header `# Weekly check-ins\n\n_Newest first. Append new entries directly below this header._`. Use the entry format in [references/check-in-format.md](references/check-in-format.md). 2. **Update `profile.md`** with anything that changed: new injuries, equipment, time realities, goal progress, preferences, life context, and the flexible weekly compass. Bump `_Last updated:_`, set `last_check_in: YYYY-MM-DD` under `## Skill settings`, and add a one-line change log entry (e.g. "2026-04-25 — Weekly check-in; updated injuries and shifted typical session length to 60 min."). If nothing in the profile actually changed, still bump `last_check_in` and the change log ("Weekly check-in; no profile changes."). The date is what gates future suggestions. Then close the loop in one line ("Logged. Want today's workout now?") and route to whatever the user wanted. ## Detecting scheduling capability Some agent runtimes can schedule a prompt to fire on a cron expression (OpenClaw scheduled agents, Claude Code's `CronCreate` / `/schedule` skill, anything that exposes a recurring-job primitive). The fitness skill can offer a daily morning check-in, but **only if** the environment supports it. Do not invent capability that isn't there. Before offering scheduling, check whether scheduling is plausible. Signals (in rough order of confidence): 1. **Environment variables** suggesting a scheduled-agent host: anything starting with `OPENCLAW_`, `CLAUDE_AGENT_ID`, `SCHEDULED_AGENT`, or similar. If present, scheduling is almost certainly possible. 2. **Available tools/skills**: a tool named `CronCreate`, a skill named `schedule` or `loop`, or any other obvious cron/scheduling primitive in the current environment. 3. **The user mentions it themselves** (e.g. "thi … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [neilberget](https://github.com/neilberget) - **Source:** [neilberget/fitness-skill](https://github.com/neilberget/fitness-skill) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-neilberget-fitness-skill-fitness-coach - Seller: https://agentstack.voostack.com/s/neilberget - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.