Shape Calendar

View saved version →

---
name: shape-plan-training
description: Plan, create, import, reschedule, pair or remove workouts in the user's connected Shape calendar. Use for requests to save a training week, build structured running/cycling/swimming sessions, move workouts, or match completed sessions to their plans. A request for ideas alone does not authorize calendar changes.
---

# Plan training in Shape

Use the connected Shape tools and their current input schemas. Follow the user's stated scope, dates, units and constraints. Do not request API tokens or use a separate connection. If the tools are unavailable, explain that Shape needs to be connected and stop before claiming a calendar change. If a tool answers that no device is connected or nothing is synced, switch to `connect_device` (see the shape-setup skill) before planning anything.

## Establish the plan

- Resolve dates in the athlete's local calendar. Ask when a date, sport or material target is ambiguous. Keep titles short and workout-specific.
- For a new block or a change to planned training, call `get_training_status` with no `from` or `to`. Read readiness drivers, load and the existing projection. Use `list_activities` over the affected date range to avoid scheduling conflicts or duplicating sessions; page through results if `total` exceeds the returned count.
- Respect the athlete's stated restrictions, availability and race priorities. Ask for missing constraints when they materially affect the plan.
- A request to create or move a specified workout authorizes that change. When the user asks only for advice or a proposed plan, present the proposal and wait for an instruction to save it. Clarify the exact affected workouts before an ambiguous deletion. Do not repeat a confirmation already supplied for the same identified change.

## Create and change workouts

- Use `create_activity` for one session and `batch_create_activities` for several. Use `update_activity` or `batch_update_activities` for existing sessions, sending their actual ids and only fields that should change. Keep each batch between 1 and 100 entries.
- `date`, `title` and `sportType` are required to create a workout. `date` is `YYYY-MM-DD`. Include `startTime` as local `HH:mm` only when the user specifies a start time; do not infer one or attach an offset.
- Sport values include `run`, `bike`, `swim`, `hike`, `yoga`, `tennis`, `skiing`, `nordicski`, `strength`, `surf` and `other`. Use values accepted by the live schema.
- Convert distance to meters and duration to seconds before saving. Choose `target: "distance"` for a distance target, `"time"` for a duration, `"pace"` when both are specified, and `"steps"` for a structured interval session. A target alone supplies no distance or duration.
- Set `completed: false` for a planned session. Mark a workout completed only when the user says it was done. Do not turn a planned prescription into an invented recording.
- Rest days have no workout. Skip them when importing a plan; do not add zero-distance rest placeholders. Simple easy sessions do not need invented interval steps.
- Set an estimated `load` for planned endurance workouts so they appear in the projection. Use `(duration_seconds / 3600) × effort² × 100`: recovery 0.25, easy 0.5, tempo 0.75, threshold 1.0, VO2 1.25, race 1.5. A 60-minute easy run is 25. Label estimates as estimates. If duration or intended effort cannot reasonably be established, ask rather than silently assigning one. Do not overwrite a completed workout's recorded load with this estimate.
- Recompute planned load when changing duration or intensity. Moving only the date does not require a new load estimate. For structured workouts with several intensities, estimate the component loads rather than treating every minute as the hardest interval.
- Before writing structured intervals or a swim, read [Workout details](references/workout-details.md) for repeat groups, pace targets and swim-specific fields.

## Pair and remove sessions

- A completed row's `plannedActivityId` points to its separate prescription. Read that planned row with `get_activity` when comparing or editing the plan. Do not assume the completed row contains planned steps.
- Use `pair_activities` with `completedActivityId` and `plannedActivityId` to match a performed workout to the plan it fulfills. Resolve both ids from returned data and verify their completed/planned states. If an existing pairing conflicts, explain it and obtain authorization before removing it.
- Use `unpair_activity` with `activityId` to remove an identified pairing without deleting either workout.
- Use `delete_activity` for one identified workout, or `batch_delete_activities` with `ids` for several. Individual deletion removes its pairing; batch deletion does not remove links on surviving paired workouts. If a counterpart will remain, include the pairing removal in the described deletion scope and use `unpair_activity` first when authorized.
- Calendar changes may also affect workouts on the user's connected devices. Report a saved change as saved; do not claim device delivery unless a returned result establishes it.

## Check and report

After creating, moving, changing or deleting planned workouts, call `get_training_status` again without a history range. Explain the returned next-week `series` and peak `projection` where relevant. Shape labels ratios above 1.5 as High; explain the change without treating that band as a medical verdict. Readiness cannot be projected into the future.

Report the workouts actually saved, moved, paired or removed, with dates and readable units. Preserve any unrelated sessions. If a write fails, stop dependent steps. If its outcome is uncertain, inspect the affected calendar before retrying a creation so a repeated call does not create duplicates. Relay connection, access and missing-data messages rather than claiming success.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: shape-review-training
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.
---

# Review training and recovery in Shape

Use 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.

## Choose the relevant data

| Question | Tools and scope |
| --- | --- |
| What is on my calendar or what did I complete? | `list_activities` over the relevant date range, with the appropriate sport and completed filter |
| What was prescribed for this completed workout? | `get_activity` for its `plannedActivityId` |
| How did I pace the workout or execute the intervals? | `get_activity_details` for the selected completed activity |
| How recovered am I, why is readiness low, or how does the plan affect load? | `get_training_status` with no `from` or `to` |
| How did fitness, fatigue or morning readiness change over a past period? | `get_training_status` with both `from` and `to` |
| What were the recorded daily sleep, HRV or other health measurements? | `list_health_metrics` with a bounded date range and an optional metric whitelist |

Use 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.

## Calendar and planned-versus-completed comparisons

- 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.
- `completed: true` selects performed workouts; `false` selects plans. Omit it only when both are relevant.
- 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.
- `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.
- Show dates, workout titles, sport and readable distance/duration. Convert meters and seconds for display; do not treat absent values as recorded zeros.

## Recordings, laps and zones

Use `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.

`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.

`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.

Routes 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.

## Readiness and load

- Use Shape's `get_training_status` results rather than rebuilding readiness or training load from activity and health lists.
- 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.
- 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.
- 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.
- 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.
- 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.

## Daily health trends

Metric 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.

Use 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.

## Deliver the review

Lead 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.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: shape-setup
description: Set up Shape after installing it: check which devices are connected to the user's Shape account, connect a Garmin or Wahoo from the chat with a one-time link, point Apple Health users to the iPhone app, and explain what happens next. Use right after install, when a Shape tool says nothing is synced or no device is connected, or when the user asks to connect, add or check a watch.
---

# Set up Shape

Use the connected Shape tools. Do not request API tokens. The goal of this
workflow is one thing: the user's device is connected to Shape, and they know
what to ask next.

## Check what is connected

- Call `connect_device` with no `provider`. It returns every device option
  with `connected`, and a link for each that is not connected yet.
- If one or more devices are already connected, say so and skip to
  "What to ask next". Do not offer links for devices that are connected.

## Connect a device

- If the user has named their device, call `connect_device` with that
  `provider` (`garmin`, `wahoo` or `apple_health`). Otherwise show the
  options from the first call and ask which they use.
- For Garmin and Wahoo, give the user the `url` exactly as returned. It is a
  personal one-time link that works in any browser for 15 minutes and needs no
  Shape sign-in. Tell them to open it, sign in to their device account, allow
  Shape, and come back to this chat.
- For Apple Health, give the App Store link and say that Health connects from
  the Shape iPhone app: install it, sign in with the same account, and allow
  Health access when asked.
- After they come back, call `connect_device` again with the same `provider`
  to confirm `connected: true`. If a link expired or was used, call the tool
  again for a fresh one; never reuse an old link.

## What happens after a connect

- The last 30 days import right away; older history follows over the next
  hours. Say this plainly so the user does not expect years of data at once.
- If a Shape tool answers that the account has no active plan, relay that
  message as it is. It names where plans are described. Do not add prices,
  promotions or a trial pitch, and do not present it as an error in the
  connection.

## What to ask next

Once a device is connected, suggest one or two first questions that work
with a fresh import, for example "How did my training look over the last
two weeks?" or "Am I ready to train hard today?". Keep it to the data that
exists; readiness needs about two weeks of sleep and heart-rate readings.

Referenced files: 1 — file references are metadata, not package contents.