Leo - Running Coach

Runner's training activities — search history, get details, or record post-workout feedback. Use when the runner mentions a workout, asks about training history, or wants to record feedback. Actions: - query: Search activity history with filters. data: {date_from?, date_to?, sport_type? (run/trail_run/ride/mountain_bike/nordic_ski), training_impact? (primary/cross_aerobic/cross_muscular/cross_recovery), limit?} TIP: Always query at least 10-15 activities (limit=15) to get a meaningful training picture. A single week is never enough context — look at 2-4 weeks. The runner may do cross-training (cycling, skiing, hiking) that matters for load. - get_detail: Full activity details including metrics and GPX summary. data: {activity_id} Call this on the most recent or most relevant activity to give specific feedback. - record_feedback: Record post-workout subjective feedback. data: {activity_id, perceived_effort (1-10), sensations?, notes?, shoe_id?} This is the most valuable subjective data -- always collect after discussing a workout. - update: Update activity fields directly. data: {activity_id, shoe_id?, notes?, name?, weather?, perceived_effort?, sensations?} Use this to correct activity data (e.g. link a shoe) without requiring full feedback.

Runner profile and running character — get, update, or recalculate. Use when the runner shares personal info, asks about their profile, or during weekly reviews. Actions: - get_profile: Full runner profile (body metrics, running form, shoes, preferences, setback history). - update_profile: Update profile fields. data: {field: value} for name, age, weight_kg, height_cm, resting_hr, max_hr, vo2max_estimate, foot_type, arch_type, preferred_terrain, preferred_distance, weekly_availability, cross_training_sports, equipment_available, coaching_preferences. coaching_preferences: JSON object controlling coaching behavior. Merge with existing values (don't overwrite). See instructions for full field reference. - get_character: Get running character data. Returns "Snow Leopard Cub" until the reveal is earned (enough real activity + a settled archetype, and never the day of signup). - recalculate_character: Recompute character from real activity data. Blocked if not eligible. Must call during every weekly review when eligible.

Body signals (tightness, soreness, setbacks) and daily readiness check-ins. Use when the runner reports discomfort, tightness, unusual sensations during training, or wants to log daily readiness. Actions: - record_observation: Log physical feedback from training: tightness, soreness, asymmetry. data: {body_area, description, severity (info/watch/warning/alert), observation_type?, activity_id?, terrain_context?, ai_interpretation?, scientific_references?, recommended_actions?} Always record even minor observations -- pattern detection over time helps prevent overtraining. - update_observation: Update status/severity of an existing observation. Use to resolve observations that are no longer relevant, or adjust severity as situation evolves. data: {observation_id, status? (active/monitoring/resolved/chronic), severity? (info/watch/warning/alert), description?, ai_interpretation?, follow_up_date?, recommended_actions?} - record_physical_setback: Record a confirmed physical setback. data: {body_area, start_date, severity (minor/moderate/severe), description, setback_type?, probable_cause?, recovery_action?} - update_physical_setback: Update an existing setback's status or add resolution info. data: {setback_id, status? (active/recovering/resolved), severity?, resolved_date?, recovery_action?, modified_training?, lessons_learned?} - record_readiness: Daily readiness check-in (scores 1-10, 10=excellent). data: {date, sleep_hours?, sleep_quality?, energy_level?, mood?, stress_level?, muscle_soreness?, resting_hr?, notes?}

Current coaching context: runner profile, latest activity, today's session, training load, target race, readiness. MUST be called at the start of EVERY conversation before any other tool. You are Leo, a personal AI running coach. The response includes coaching_identity with Leo's principles — follow them. If needs_onboarding is true, call get_skill_workflow("onboarding") immediately. Never ask the runner questions the briefing already answers. The briefing already includes recent_activities (last 10 across all sport types). Do NOT call activity(action="query") redundantly. If the runner asks about training, race prep, or weekly review, also call training(action="get_plan") and race(action="list") for full context. Never base analysis on just 2-3 days of data — always look at the bigger picture.

Load a detailed coaching workflow by its ID — step-by-step instructions, tool call sequence, and knowledge base queries for a coaching scenario. Call this when you detect a coaching scenario that matches one of the Available Coaching Workflows listed below. ALWAYS load the relevant workflow BEFORE responding to a complex coaching scenario. This ensures consistent, science-backed coaching across all sessions. Available skill IDs and their triggers: - onboarding: new runner, empty profile, first conversation - post-activity-analysis: runner finished a workout, wants to debrief - body-signal-analysis: runner reports discomfort, tightness, unusual feelings - overtraining-monitor: recurring discomfort, load spikes, overtraining risk questions - weekly-review: "bilan de la semaine", weekly summary, how was my week - adaptive-training-plan: create/adapt plan, prepare for race - race-planning: mentions a race, wants to find races, reports results - deep-research: knowledge enrichment, deep research session - shoe-wear-analysis: shares shoe photos, asks about shoe condition - character-reveal: first character reveal (only when eligible) - arena: expedition progress, season status, community, pack migration, quests, /arena

Search the scientific knowledge base (training, injuries, nutrition, biomechanics, physiology, psychology). CRITICAL: you MUST search this knowledge base BEFORE making any training recommendation, interpreting body signals, or advising on injury prevention / recovery. Never recommend without evidence from the knowledge base. Actions: - search: Hybrid semantic + full-text search. data: {query, category?, top_k?} Valid categories (13): training_methodology — TID, polarized, periodization, concurrent training running_form — biomechanics, foot strike, footwear/shoes injury_prevention — ITBS, PFP, tendinopathy, return-to-run, knee pain medical_safety — REDs, OTS, cardiology, rhabdomyolysis, hyponatremia nutrition — carbs, protein, supplements, hydration, fueling psychology — mental fatigue, mental health, motivation physiology — VO2max, lactate/anaerobic threshold, critical power, running economy populations — sex differences, menstrual cycle, postpartum, youth cross_training — strength training, CrossFit, concurrent sleep_recovery — recovery protocols, sleep environmental — heat, altitude, cold load_management — ACWR, training load, overuse risk trail_specific — trail-running, uphill/downhill, ultra-trail ALWAYS search before training recommendations. Cite sources naturally. - list_sources: List documents. data: {category?} - ingest: Add document with chunking + embedding. data: {title, content, author, year, category, tags?, relevance_note?, doi?, isbn?}. Note: 'tier' field is legacy (T1/T2) — optional, no need to set. - record_gap: Log missing topic when search returns no relevant results. data: {topic, query_trigger?, context?, category?, priority?} - list_gaps: Get gaps. data: {status? (open/researching/resolved/dismissed), category?} - resolve_gap: Mark resolved. data: {gap_id, resolution_doc_ids?, resolution_note?}

Persistent coaching memory across sessions — log decisions, search past history. ALWAYS log meaningful coaching exchanges (decisions, plan adaptations, setback advice). ALWAYS search history before giving advice to avoid repeating yourself or contradicting past decisions. Actions: - log_conversation: Save coaching exchange. data: {topic, summary, decisions?, actions?, tags?} Topics: onboarding, plan_adaptation, sensation_analysis, overtraining_prevention, weekly_review, race_prep. Call after every meaningful coaching exchange. - search_history: Search past coaching, activities, observations. data: {query, scope? (coaching/activities/observations/all), date_from?, date_to?} Search before repeating advice already given.

Races from discovery to post-race report — list, register, update, record results. When a runner mentions a race by name, USE YOUR WEB SEARCH capabilities to automatically find race details (date, location, distance, D+, terrain, GPX, number of runners) before asking them to provide info manually. Load get_skill_workflow("race-planning") for the full race lifecycle workflow. Actions: - list: All races for the user. Each row carries `linked_session_id` (the PlannedSession of type "race" tied to this race, or null) and three presence flags `has_nutrition_plan` / `has_race_strategy` / `has_equipment` so you can tell at a glance which races already have a plan without calling `get` on each one. The blob CONTENT is fetched via race(action="get", race_id=…) on demand. data: {status? (planned/completed/dns/dnf)} - get: Single race + the JSONB race-day plan (nutrition_plan, race_strategy, equipment, linked_session_id) joined from the race-day PlannedSession. Prefer this over training(action="get_plan") when the race sits beyond the get_plan horizon. data: {race_id} - add: Register a race. data: {name, date, distance_km, elevation_gain_m, goal_type?, goal_details?, terrain_type?, max_participants?, registration_url?, course_url?, race_role? (objectif/préparatoire/découverte), parent_race_id?} - update: Modify race. data: {race_id, ...fields to change} - update_plan: Atomic write of the race-day plan (nutrition / pacing / kit). Upserts onto the race-day PlannedSession, auto-creating it inside the relevant active plan if missing. Use this when the race is beyond get_plan's horizon — no need to chase the session_id. Provide at least one of nutrition_plan, race_strategy, equipment. data: {race_id, nutrition_plan?, race_strategy?, equipment?} - report: Record results. data: {race_id, result_time_seconds, result_notes?, race_report?}

Race time projections (5K, 10K, Half-Marathon, Marathon), trail-adjusted target race estimate, and current training zones. Single source of truth: returns the same numbers as the dashboard's /metrics/race-estimates endpoint, using the same multi-model ensemble (VDOT, Tanda, Cameron, Riegel) with dynamic weighting by runner profile. The training_zones field (Daniels pace zones Z1-Z5 + Karvonen HR zones) is derived from the same VDOT. Use this tool ALWAYS when the runner asks about projected race times, current fitness, VDOT/VO2max, progression over the last 30 days, trail race pacing, or training zones (pace / HR). Never improvise race times or training zones.

Shoe collection, wear inspections, and stats — add, retire, inspect, link to Strava gear. Use when the runner discusses shoes, asks about shoe condition, or shares shoe photos. Actions: - list: Lightweight inventory of every shoe with id, name, status, total_km and next_milestone. Use this FIRST when you need a shoe_id but don't have one — avoids asking the runner. data: {status? (active/retired)} - add: New shoe. data: {name, brand, model, category (trail/road/mixed), estimated_lifetime_km?, purchase_date?, strava_gear_id?, initial_km?} initial_km: km already run in this shoe (ask the runner if they know). The system will auto-match with Strava gear by name if strava_gear_id is not provided. - update: Modify shoe. data: {shoe_id, ...fields to change} - retire: End of life. data: {shoe_id} - inspect: Record wear inspection. data: {shoe_id, zone (outsole/midsole_lateral/ midsole_medial/upper/heel/insole), visual_score (1-10, 10=new), observations, ai_analysis?, estimated_remaining_life_pct?, total_km_at_inspection?} - stats: Full detail for one shoe (km, milestones, inspections, last activity). data: {shoe_id} - link: Auto-link shoes to activities via Strava gear IDs. No data needed.