Claude Coach Bootstrap Skill A developer created a skill called 'Claude Coach Bootstrap' that interviews users and scaffolds a personalized git-based repository where an LLM acts as an ongoing strength-and-conditioning coach. The system stores all state in files rather than the model's context, enabling long-running per-session tracking across multiple sessions without memory. The skill guides users through an interview process to determine goals, schedule, and preferred structure level, then generates a repo with schemas, validators, and CI to maintain consistency. | name | coach-repo-bootstrap | |---|---| | description | Interview a user and scaffold a personalized git-based repo where an LLM acts as their ongoing strength-and-conditioning coach, with all state kept in files rather than the model's context. Use this whenever someone wants to set up a workout or training tracker, a personal-coach or AI-fitness-log repo, an RPE-autoregulated strength program, or any long-running per-session tracking system an agent maintains across sessions — even if they never say "skill," "scaffold," or "repo," and even if they only describe the outcome "I want an AI to plan and log my workouts and handle the progression for me" . | Interview the user, then scaffold a git repo where an LLM coaches them across sessions with all state in files. Work in order — interview §1 , scaffold §2 , verify §5 — and don't assume their goals, schedule, equipment, or body: a wrong guess baked into the scaffold costs more to undo than a question costs to ask. The Gotchas §4 encode real failure modes; treat them as load-bearing. The coach has no memory between sessions, so continuity lives in the repo, not the model: each session an agent reads a few small files, reasons, writes conclusions back, and forgets. Three rules keep that loop working over months, and they drive every choice below: Small working memory — the state needed to plan a session fits in a few kilobytes, reloadable from scratch each time; detailed history is archived, not re-read. Write each fact once — one canonical home per fact; everything else points to it. External guardrails — a schema, a validator, and CI, because the model silently drifts its own conventions over time see Gotchas . Ask these in small batches don't dump all of them at once . Adapt follow-ups to their answers. Your goal is to fill in the templates in Phase 2, so listen for those values. A. Goals & context - What do you want out of training? strength, size, endurance, general health, a specific event/deadline, rehab from an injury… - Experience level and background? never trained / returning / experienced / coming from a specific modality like CrossFit, running, lifting - Anything time-bound? a race, a trip, a season starting B. How much structure do you want — this is the key axis; don't skip it. Programs live on a spectrum from fully-planned to fully-improvised. Ask where they want to be: Fixed — "tell me exactly what to do each day." A written weekly template with prescribed days. Predictable; brittle if their week is chaotic. Scaffolded — "give me a default week, but adapt when life happens." A soft weekly shape plus a library the coach composes from. Good default for most people. Flexible — "just tell me the best thing to do on the day I show up." A library of exercises + a few hard constraints; every session composed on the fly from what's stale. Lowest overhead; needs the staleness tooling to stay coherent. Tell them they can start anywhere and move along the spectrum later many people start Fixed and loosen once fixed days stop fitting their week . Record their choice; it decides which program blocks you generate in Phase 2. C. Schedule reality - How many sessions/week can you realistically hit not aspirationally ? - Typical session length? Are short 15–25 min sessions acceptable, or only "real" workouts? - Fixed training days, or does it move around week to week? - Any recurring activities that already train something? a sport, a weekly class, a commute-by-bike . These matter — they can "cover" a training goal so the coach doesn't double-program it. Ask what each one demands physically and roughly how hard/long it is. - What kinds of sessions will you log? Start from strength and cardio , then add every named activity they do yoga, a specific sport, a class, a swim . This answer becomes the log type set and the validator's VALID TYPES §3.2 — if you leave it at the generic default, the validator will reject the user's real activities or the coach will silently flatten them into a lossy sport . D. Locations & equipment — one profile per place they train - Where do you train? home, a specific gym, outdoors, travel… - For each: what equipment is actually there? Be concrete dumbbell range and increments, machines, bars, bands, cardio options, floor space . - Safety constraints? no spotter → avoid movements where failure is dangerous; no rack; etc. E. Constraints & health ask gently; all optional; note only what they volunteer - Injuries, past or present, or movements that hurt? - Medical conditions or medications that affect training, heart rate, hydration, or recovery? If they share these, record them so the coach programs around them — but don't press. - Anything you specifically want to avoid or emphasize? F. Logging & tracking preferences - How much detail do you want in logs — terse, or a full narrative per session? - Do you want personal records tracked? - Wearables: there's no clean way to auto-link a wearable, so don't build around one. But if they use one, mention that a screenshot of the wearable's session summary HR, zones, calories is easy to drop into a session and read, so they can share those whenever they want the data captured. Treat those numbers as directional, not gospel see Gotchas . G. Progression philosophy — explain and confirm - The default is RPE-based autoregulation : each exercise has a target rep/RPE range and a trigger "add weight when all sets hit the top of the range at RPE ≤ 8" . Load goes up when they clear the bar, holds when they're grinding. No fixed weekly percentages, no calendar deloads — deload by feel when signals stack up. - Briefly teach the RPE scale so their logged numbers mean something: 6 = 4+ reps left · 7 = 3 left · 8 = 2 left · 9 = 1 left · 10 = max, nothing left. - Confirm this suits them, or adjust some people want fixed linear progression instead . When the interview is done, play back a summary of what you heard and get confirmation before scaffolding. Before writing any files, build the exercise library from the interview — the specific movements they'll actually train, from their goals, equipment, and chosen structure level. Each library entry carries a movement pattern tag a muscle-group/goal like squat bilateral or cardio easy ; those tags are the pattern vocabulary the whole repo keys off — the staleness briefing and the validator both derive it from the library, so there's no separate pattern list to maintain. Tag only patterns they'll really train a walker who lifts twice a week has no cardio intervals , and getting the library from the user rather than this doc's examples is what keeps the scaffold from overfitting. Also note: every concrete example here — yoga covering core, a weekly sport banking interval cardio, HR-elevating medication — is an illustration, not a default. Substitute the user's real activities and constraints and delete anything that doesn't apply to them. Then create this structure. Fill every template from the interview answers, and delete blocks that don't apply to the structure level they chose Fixed / Scaffolded / Flexible . their-coach-repo/ ├── CLAUDE.md operating manual for future session-agents see §2.6 ├── README.md short human-facing overview ├── profile.yaml who they are, goals, schedule, constraints ├── equipment/ │ └──