{"id":74599,"plugin_id":"plugin_asdk_app_6ad65fec72a08191a21f92c4e366e419","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-31T12:11:10.577Z","digest":"3040da25eb2f9b2e760e739045161aae00dcb87de355857c3911b0caca36ee7d","against":null,"payload":{"description":"Review the user's recorded Shape workouts, training load, readiness and daily health trends. Use for questions about pacing, interval execution, planned versus completed training, weekly mileage, sleep, HRV, recovery or fitness trends. This workflow reviews data without changing the account.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":424}],"name":"shape-review-training","skill_md_contents":"---\nname: shape-review-training\ndescription: Review the user's recorded Shape workouts, training load, readiness and daily health trends. Use for questions about pacing, interval execution, planned versus completed training, weekly mileage, sleep, HRV, recovery or fitness trends. This workflow reviews data without changing the account.\n---\n\n# Review training and recovery in Shape\n\nUse the connected Shape tools and their current schemas. Follow the user's question and unit preferences. Do not request API tokens. If Shape is unavailable, explain how to connect it without claiming to have inspected the account. If a tool answers that no device is connected or nothing is synced, offer `connect_device` (see the shape-setup skill) instead of reviewing an empty account.\n\n## Choose the relevant data\n\n| Question | Tools and scope |\n| --- | --- |\n| What is on my calendar or what did I complete? | `list_activities` over the relevant date range, with the appropriate sport and completed filter |\n| What was prescribed for this completed workout? | `get_activity` for its `plannedActivityId` |\n| How did I pace the workout or execute the intervals? | `get_activity_details` for the selected completed activity |\n| How recovered am I, why is readiness low, or how does the plan affect load? | `get_training_status` with no `from` or `to` |\n| How did fitness, fatigue or morning readiness change over a past period? | `get_training_status` with both `from` and `to` |\n| What were the recorded daily sleep, HRV or other health measurements? | `list_health_metrics` with a bounded date range and an optional metric whitelist |\n\nUse the athlete's local calendar for relative dates. Ask for clarification if the date range or selected workout is ambiguous. Do not retrieve a year of history for a question about this week.\n\n## Calendar and planned-versus-completed comparisons\n\n- Activities are returned newest first. Use `limit` and `offset` to page through `total` before reporting complete totals; the default page has at most 50 entries, with a maximum requested page of 200.\n- `completed: true` selects performed workouts; `false` selects plans. Omit it only when both are relevant.\n- A fulfilled plan is hidden from the default list, leaving its completed counterpart. That completed row does not contain the planned prescription or steps. Fetch `plannedActivityId` with `get_activity` for a comparison.\n- `includePaired: true` can expose both rows. Do not add both halves to volume or load totals. Distinguish performed training from planned training and missed sessions.\n- Show dates, workout titles, sport and readable distance/duration. Convert meters and seconds for display; do not treat absent values as recorded zeros.\n\n## Recordings, laps and zones\n\nUse `get_activity_details` for questions summaries cannot answer. Prefer returned `laps` and `zones` when those summaries are sufficient. Ask only for necessary channels such as `heartRate`, `speed`, `power` or `cadence`; the schema lists all supported names.\n\n`points` controls detail from 10 to 2000. Begin with the default or a modest value and raise it only when interval detail is insufficient. Channels are parallel arrays indexed against `time` in seconds from the activity start. Read `units` and `resolutionSeconds` before interpreting values. Laps and zones reflect the full recording even when channels are reduced. Do not invent exact spikes or transitions between returned points.\n\n`detailFrom` identifies the selected recording when it came from another connected source. Explain the returned source rather than assuming it is the activity's displayed source. If details are missing, relay the tool's `message` and `reason`; a planned workout, a manual entry and a missing device recording are different cases.\n\nRoutes are omitted by default. Use recorded `lat`/`lng` only when the user asks about a route. Request `get_activity` with `includeMap: true` only when drawing a map requires its encoded route; an encoded route string does not answer an effort question.\n\n## Readiness and load\n\n- Use Shape's `get_training_status` results rather than rebuilding readiness or training load from activity and health lists.\n- Explain a readiness score with its returned `drivers`, their values and their baselines. Read `basis`: the current snapshot includes completed training today; historical series readiness represents the morning before that day's training.\n- Fitness, fatigue, form and load ratio are separate measures. Explain the returned relationship and trend in the athlete's terms. A ratio above 1.5 is labeled High by Shape; it is a training-load flag, not proof of an injury or a diagnosis.\n- The default `series` includes today and the next seven days of projected load, with `projection` reporting that week's peak. Readiness cannot be projected. Distinguish planned/projected values from recorded results.\n- When a score or projection is absent, explain the returned missing-data reason. Do not prescribe a fixed waiting period or a connection change unless the result supports it. A missing projection may mean no upcoming planned workout carries a load value.\n- Let the athlete's current symptoms or stated restrictions take precedence over a favorable score. Answer training-data questions without diagnosing illness or replacing clinical advice.\n\n## Daily health trends\n\nMetric ids must match the input schema. Examples include `restingHR`, `hrvMs`, `sleepDurationSec`, `sleepScore`, `vo2max`, `steps`, `bodyBatteryCharged` and `bodyBatteryDrained`. Omit `metrics` when the relevant recorded fields are unknown. Without `from`, only the last 90 days are returned; provide it explicitly for older questions.\n\nUse each value's reported source and units. Keep differing HRV methods separate: Garmin RMSSD and Apple SDNN are not directly interchangeable, even though both use milliseconds. `bodyBatteryCharged` and `bodyBatteryDrained` are daily totals, not the watch's instantaneous 0–100 level. Convert sleep seconds to hours/minutes for the athlete. Explain gaps instead of interpreting missing values as a deterioration.\n\n## Deliver the review\n\nLead with the answer, then the few observations that support it. Keep completed work, future plans and any uncertainty distinct. When a comparison cannot be made, say which data is missing. Do not move workouts or delete data during a read-only review unless the user adds a request for that action.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}