Lion Lift

View saved version →

---
name: compare-workout-to-plan
description: Compare a scheduled or planned workout with what was actually logged and explain meaningful differences. Use when the user asks how a workout compared to what was planned, whether they stuck to a schedule, or what changed between a plan and the real session.
---

# Compare a workout to its plan

Explain, in plain language, what was planned versus what actually happened for one workout. This skill only reads and compares; never call a scheduling tool from here.

## Find the plan and the session

- For a **lift**, the plan and the result live in the same completed record — no second record to find. `original_lift_plan` holds the frozen plan (exercise names, planned weight/reps per set); `lifts` holds what was actually logged. Fetch the one record (`fetch_records` / `get_record` on the `lifts` collection, `status` `completed`) and compare those two fields directly. `original_lift_plan` is only present on lifts that were scheduled through a path that writes it — if it's missing, say plainly that there's no preserved plan to compare against (the workout was likely logged directly, not scheduled first), rather than guessing at one.
- For a **run, swim, or bike**, the plan and the logged session are two separate records with **no stored link between them** — match them yourself by date. Use `list_run_workouts` / `list_swim_workouts` / `list_bike_workouts` to find the plan whose `scheduledFor` falls on the day in question, then use `fetch_records` on that sport's own collection (`run` / `swim` / `bike`, `status` `completed`) to find the logged session on that same calendar day. If more than one plan or more than one completed session that day is plausible, say so and ask which one rather than guessing. If either side is missing — no matching plan, or no completed session that day — say so plainly instead of fabricating a comparison.
- Note the plan's `status` when relevant. A plan still `pending` (never synced via the app's Sync Workouts screen) never actually reached Apple Fitness or the Watch, so even if a session was logged that day, the plan can't have directly guided it the way a `synced` one would have.

## Compare what matters

- For a **lift**, compare exercise by exercise and set by set: same exercise, planned weight/reps vs. actual. Call out exercises or sets that were skipped, added, or changed by more than a trivial amount — not every identical value.
- For **run/swim/bike**, the comparison is necessarily high-level, not step-by-step: the logged session carries overall totals (distance, duration, average heart rate, pace, power, when recorded), not the same warmup/block/cooldown structure the plan has. Compare total distance against the plan's summed distance goals, total duration against its time-based goals, and average heart rate/pace/power against any target alerts in the plan — and be explicit that this is an approximation of whether the plan was followed, not a verified segment-by-segment match.
- Don't invent precision the data doesn't support. If the logged session has no heart rate, pace, or power recorded, say that plainly rather than guessing whether a target alert was hit.

## Present the comparison

- State what was planned and what actually happened side by side, in plain language, then lead with the meaningful differences rather than restating every value that matched.
- Mention the plan's sync status when it affects how much weight to put on the comparison (see above).
- If no plan, no logged session, or no confident match between the two could be found, say so directly rather than presenting a guess as a real comparison.

View saved version →

---
name: generate-report
description: Export an in-depth training report as a PDF, in the Lion Lift visual theme, with charts, graphs, tables, trends, and analysis across a user-specified time period and page count. Use when the user asks for a report, export, or PDF summary of their training.
---

# Generate a training report PDF

Produce a polished, multi-page PDF report of the user's training — not a plain data dump. This connector has no PDF-rendering tool of its own; it only supplies the data. Build the report using whatever document/file-creation capability is available in this conversation.

## Scope the report

- Confirm the time period, which sports to include (swim, bike, run, lift, or all), and the target page count before gathering data. A 1-page report and a 10-page report need very different amounts of detail — over- or under-filling a requested length is worse than asking first.
- Gather data the same way `lion-lift-analyzer` does: use available Lion Lift read tools for completed workouts in the selected sports and period. Include sleep/work context or goals only when those collections exist. Ask the user for age, height, weight, sex, or training experience only when a specific interpretation needs that context; never imply a profile tool returned it.

## Build it correctly, not just completely

- When grouping or charting lifts by muscle group, use the `muscleGroups` array field, not the legacy single joined `muscleGroup` string — a multi-group session like "Chest, Back, Shoulders" must count once toward each of Chest, Back, and Shoulders individually, not as one combined bucket of its own.
- Use real charts and tables, not prose pretending to be one: volume or trend over time as a line or bar chart, sport or muscle-group distribution as a pie or bar chart, a session log as an actual table. Pick the chart type the data actually supports — don't force a trend line onto three data points.
- A forecast is a short, clearly-labeled projection from the recent trend, not a guaranteed outcome. State the assumption behind it, and skip it entirely (say why, in the report) if there's too little history to support one.
- Call out, in the report itself — not just in conversation — any contributing factor found in the sleep/work logs and any missing context (age/height/weight, or missing performance data) that limits confidence in a conclusion. Same honesty `lion-lift-analyzer` applies, just surfaced to the reader directly.

## Match the Lion Lift look

- Use Lion Lift's actual palette, not a generic report style: a dark navy primary (approximately `#1F3B5E`, derived from the app's own `Color(red: 0.12, green: 0.23, blue: 0.37)`) for headers and accents. When breaking anything out by sport, use the app's own per-sport colors: run red, bike orange, swim blue, lift near-black, core purple. Keep layout clean and legible — this is a personal report, not a marketing document.

## Deliver it

- State the exact period, sports, and page count the report covers before presenting it. If the actual content came out meaningfully shorter or longer than the requested page count, say so and why, rather than silently padding or cutting it.
- This skill only reads and reports. Never call a scheduling tool from here.

View saved version →

---
name: lion-lift-analyzer
description: Review progress and training trends over a given period (days, weeks, or months) across any combination of swim, bike, run, and lift. Use when the user asks for an analysis, review, or summary of their training over a time range, for one sport or all of them.
---

# Analyze training over a period

Analyze completed training across the sports and time range the user asks about, and explain what the data actually shows — trends, balance, consistency, standout sessions — not just a restated list of numbers.

## Scope the analysis

- Resolve the exact date range and which sports to include (swim, bike, run, lift, or any combination — default to all four if the user doesn't say). Confirm an ambiguous range ("last month," "this training block") against today's date rather than guessing a boundary.
- Use `list_collections` / `list_fields` to confirm the current schema if anything is uncertain. Use `fetch_records` with `start_date`/`end_date` and `status` `completed` for each relevant sport's own collection (`lifts`, `run`, `bike`, `swim`); widen the range slightly around local-day boundaries since dates are stored in UTC.
- If a `goals` collection exists, pull relevant weekly targets as context for whether training volume matched intent — don't treat a goal as a requirement the user is being graded against.

## Check for the context that actually changes the conclusion

- If a `dailyLog` collection exists, check relevant sleep and work entries for the same period. If short sleep or a heavy work stretch overlaps a dip in training volume or performance, describe it as a possible contributing factor, not a proven cause.
- Use only available Lion Lift read tools for athlete context. If age, height, weight, sex, or training experience would materially change an interpretation, ask the user directly; never guess or imply these details were retrieved from a profile tool.
- Note any other real gap in the data (missing heart rate, a sport with too few sessions to say anything meaningful) rather than filling it in.

## Draw real conclusions

- Look for actual patterns: volume trend up or down, consistency (sessions per week, gaps), whether hard efforts cluster or spread out, balance across the requested sports, and any standout session (a clear best/worst effort, a notable jump or drop).
- Distinguish a real trend (several sessions moving the same direction) from a single outlier session — don't call one unusually good or bad session a trend.
- Tie conclusions to specific sessions and dates as evidence, not just an aggregate average.

## Present the analysis

- Lead with the clearest two or three takeaways, then the supporting detail per sport. State the exact date range and which sports were included.
- Call out explicitly, near the top, any contributing factor found in the sleep/work logs or any missing context (age/height/weight, or missing performance data) that limits how confidently a conclusion can be drawn.
- This skill only reads and analyzes. Never call a scheduling tool from here.

View saved version →

---
name: propose-bike-workout
description: Propose a cycling workout using Lion Lift ride history, recent cross-training, the athlete's goals, and available time. Use when the user asks what ride to do; this skill does not schedule it.
---

# Propose a bike workout

Give one practical ride for the requested day. Make it specific enough to review and, if desired, pass to `schedule-bike-workout`.

## Gather context

- Ask for missing details that would change the ride: intended day, available time, focus (for example endurance, climbing, or intervals), trainer or road setting, terrain if relevant, available power or heart-rate sensors, and current fatigue, pain, or illness. If a minor detail is open, state a reasonable assumption.
- Use Lion Lift's read tools to discover available collections and fields. Review recent completed rides, normally 6–12 weeks, for frequency, duration, distance, comparable sessions, power, heart rate, cadence, effort, and notes when recorded. Review recent runs, swims, and lifts for total load and hard sessions, especially leg-intensive work or consecutive demanding days. Exclude scheduled or incomplete records from completed training totals.
- Retrieve only fields needed for the decision. Widen date queries around local-day boundaries when records use UTC timestamps. Treat implausible or inconsistent measurements as uncertain. Do not infer interval structure from ride totals alone.
- Use the athlete's stated goals and constraints. Do not assume a particular age, ability, threshold power, training plan, or personal file exists.

## Design the session

- Match the focus and duration to recent cycling fitness, the preceding 24–48 hours, upcoming commitments if known, and available time. Avoid abrupt jumps in duration or intensity. If history is sparse or recovery uncertain, favor a manageable easy aerobic ride.
- Specify warm-up, each work and recovery segment with repeat count, and cool-down. Use power or heart-rate targets only when reliable history and the athlete's equipment support them; otherwise use effort and a talk-test cue. Avoid treating road speed as a stable intensity target across changes in terrain, wind, or traffic.
- Allow practical flexibility for outdoor riding, including safe places to start intervals. Treat current pain, illness, dizziness, or other concerning symptoms as a reason to pause or modify training, not as data from which to diagnose a condition.

## Present the proposal

State a distinctive title, intended date, trainer or road setting, focus, expected duration and approximate distance if supportable, complete step sequence and recovery, targets, and the main evidence behind the choice. Distinguish logged facts from coaching judgment and mention material data gaps briefly. Include an easier adjustment or stop condition when recovery is uncertain.

This skill only proposes. Do not call a scheduling tool here. If the user wants it scheduled, hand the complete proposal to `schedule-bike-workout` for confirmation and creation.

View saved version →

---
name: propose-lift-workout
description: Propose a strength-training session using Lion Lift lift history, recent swim/bike/run load, goals, equipment, and available time. Use when the user asks what to lift; this skill does not schedule it.
---

# Propose a lift workout

Give one practical session for the requested day. Explain the muscle groups and training purpose in plain language, then provide a plan specific enough to review and, if desired, pass to `schedule-lift-workout`.

## Gather context

- Ask for missing details that would change the session: intended day, available time, goal, equipment, exercise preferences or limitations, and current soreness, pain, illness, or unusual fatigue. If a minor detail is open, state a reasonable assumption.
- Use Lion Lift's read tools to discover collections and fields. Review recent completed lifts, normally 6–12 weeks, for exercise selection, sets, reps, loads, frequency, notes, and performance on comparable movements. Review recent runs, rides, and swims for total load and hard sessions, particularly work that stresses the same muscles. Exclude scheduled or incomplete records from completed training totals.
- Retrieve only fields needed for the decision. Widen date queries around local-day boundaries when records use UTC timestamps. Distinguish completed reps and loads from planned ones. Treat implausible or inconsistent entries as uncertain.
- Use the athlete's stated goals and constraints. Do not assume a particular age, lifting experience, training split, or personal file exists.

## Design the session

- Choose the muscle groups and exercises based on recent lifting, recovery, cross-training, and upcoming commitments if known. Prefer familiar movements unless the user wants variety. Include a short warm-up, exercise order, sets, reps, rest, and a realistic time estimate. Balance the session so it fits the available time.
- Choose one main focus and explain it simply: **strength** means practicing heavier efforts with fewer reps and ample rest; **hypertrophy** means enough challenging work to support muscle growth; **muscular endurance** means sustaining repeated efforts with lighter loads or more reps. Explain **progressive overload** as a gradual increase in a suitable variable, such as reps, load, or total work, when prior performance and recovery support it. Do not imply every session must be harder than the last.
- Use recent comparable sets to suggest loads or a bounded starting range when evidence supports it. Otherwise prescribe an effort target, such as finishing with a few good reps available, and explain how to choose the load. Avoid invented maxes, abrupt load jumps, and training to failure by default. Offer an easier adjustment when recovery is uncertain.
- Treat current pain, illness, dizziness, or other concerning symptoms as a reason to pause or modify training, not as data from which to diagnose a condition.

## Present the proposal

State a distinctive title, intended date, focus, muscle groups, expected duration, and a brief reason this session fits the athlete's recent training. Show each exercise with sets, reps, suggested load or load-selection cue, and rest. Separate logged facts from coaching judgment and mention material data gaps briefly.

This skill only proposes. Do not call a scheduling tool here. If the user wants it scheduled, hand the complete proposal to `schedule-lift-workout` for confirmation and creation.

View saved version →

---
name: propose-run-workout
description: Propose a specific run using Lion Lift workout history, recent training load, and the runner's goals and constraints. Use when the user asks what run to do; this skill does not schedule it.
---

# Propose a run workout

Give one practical run the user could do on the requested day. The result should be specific enough to review and, if desired, pass to `schedule-run-workout`.

## Gather context

- Ask only for missing details that would materially change the workout: intended day, available time, goal, running environment, and current pain, illness, or unusual fatigue. If the user leaves a minor detail open, make a stated, reasonable assumption.
- Use the connected Lion Lift read tools to discover available collections and fields. Review recent completed runs, normally 6–12 weeks, for frequency, volume, longest run, comparable sessions, pace, heart rate, and effort when recorded. Review recent lifts, rides, and swims for total load and hard sessions. Exclude scheduled or incomplete records from completed training totals.
- Retrieve only fields needed for the decision. Expand the date window around local-day boundaries if records use UTC timestamps. Treat missing, implausible, or inconsistent measurements as uncertain rather than filling them in.
- Use the user's stated goals and constraints. Do not assume a particular age, ability, training plan, or personal file exists.

## Design the session

- Match the session to recent training, the preceding 24–48 hours, upcoming commitments if known, and available time. Avoid abrupt increases in volume or intensity. If recent history is thin, favor an easy, conservative session and use effort targets.
- Give warm-up, each work and recovery segment with its repeat count, and cool-down. Set pace or heart-rate targets only when the data supports them; otherwise use effort or a conversational cue. Include an easier alternative or stop condition when recovery is uncertain.
- Treat current pain, illness, dizziness, or other concerning symptoms as a reason to pause or modify training, not as data from which to diagnose a condition.

## Present the proposal

State the workout title, intended date, indoor or outdoor setting, expected duration and approximate distance, complete step sequence, targets, and the main evidence behind the choice. Distinguish logged facts from coaching judgment and mention material data gaps briefly.

This skill only proposes. Do not call a scheduling tool here. If the user wants it scheduled, hand the complete proposal to `schedule-run-workout` for confirmation and creation.

View saved version →

---
name: propose-swim-workout
description: Propose a pool swim using Lion Lift swim history, recent cross-training, the athlete's goals, and available time. Use when the user asks what swim to do; this skill does not schedule it.
---

# Propose a swim workout

Give one practical pool session for the requested day. Make it specific enough to review and, if desired, pass to `schedule-swim-workout`.

## Gather context

- Ask for missing details that would change the session: intended day, time in the water, pool length and units, preferred strokes, focus (for example technique, endurance, or speed), equipment access, and current fatigue, pain, or illness. If a minor detail is open, state a reasonable assumption.
- Use Lion Lift's read tools to discover available collections and fields. Review recent completed swims, normally 6–12 weeks, for frequency, distance, duration, stroke mix, comparable sets, recorded pace or effort, and notes. Review recent runs, rides, and lifts for total load and hard sessions, especially shoulder-intensive lifting or consecutive demanding days. Exclude scheduled or incomplete records from completed training totals.
- Retrieve only fields needed for the decision. Widen date queries around local-day boundaries when records use UTC timestamps. Treat implausible or inconsistent measurements as uncertain. Do not infer interval structure from session totals alone.
- Use the athlete's stated goals and constraints. Do not assume a particular age, ability, training plan, or personal file exists.

## Design the session

- Match the focus and volume to recent swim fitness, the preceding 24–48 hours, upcoming commitments if known, and available pool time. Allow realistic time for rest and transitions. If history is sparse or recovery uncertain, favor a manageable technique or easy aerobic session.
- Specify warm-up, drills where useful, main set, work and recovery for each repeat, and cool-down. Make distances practical for the stated pool length. Use the athlete's pool units in the proposal and label them clearly.
- Use pace or send-off targets only when comparable swim data supports them. Otherwise prescribe effort and explicit rest. Do not treat an estimated pace or an uncalibrated device metric as a measured threshold.
- Treat current pain, illness, dizziness, or other concerning symptoms as a reason to pause or modify training, not as data from which to diagnose a condition.

## Present the proposal

State a distinctive title, intended date, pool length and units, focus, expected duration and total distance, complete set sequence with strokes and rest, any supported targets, and the main evidence behind the choice. Distinguish logged facts from coaching judgment and mention material data gaps briefly. Include an easier adjustment or stop condition when recovery is uncertain.

This skill only proposes. Do not call a scheduling tool here. If the user wants it scheduled, hand the complete proposal to `schedule-swim-workout` for confirmation and creation.

View saved version →

---
name: schedule-bike-workout
description: Turn a user-approved ride into a structured Lion Lift cycling workout. Use when the user asks to schedule a bike workout; confirm the exact session and local date/time before creating it.
---

# Schedule a bike workout

Create the ride the user approved using Lion Lift's structured bike scheduling tool. A proposal from `propose-bike-workout` is useful but not required.

## Prepare the workout

- Resolve the user's local calendar date and start time, warm-up, every work and recovery step, repeat counts, targets, and cool-down. Ask for missing details needed to preserve the intended session. Do not infer what “today” or “tomorrow” means near a date or time-zone boundary.
- Check Lion Lift's current scheduling schema before constructing the call. The present `schedule_bike_workout` tool requires a distinctive `display_name`, local `scheduled_for` in `YYYY-MM-DDTHH:MM` format, and at least one block with `work`, optional `recovery`, and `iterations`. `warmup` and `cooldown` are optional single steps. Use each step's `display_name` to clarify its purpose.
- Current goal types are open, time (seconds), distance (miles), and energy (kilocalories). Convert units carefully. Current alerts support heart-rate zones or ranges, speed thresholds or ranges, power zones or ranges or thresholds, and pedal cadence thresholds or ranges in RPM. Include only supported targets the user approved and can reasonably measure; do not invent FTP, zones, or sensor availability. For road rides, account for terrain and traffic before encoding a speed target.
- The scheduling tool has no indoor/outdoor parameter. The rider chooses trainer or road when starting the workout on the Watch. Preserve the intended sequence: a repeated work/recovery pair can include recovery after its final repetition, so represent a plan ending on work explicitly. Do not silently add or remove recovery.

## Confirm and create

Before the write, show the complete workout in plain language: local date/time, title, warm-up, every block and repeat count, targets, recovery, cool-down, and any unit conversion or representation change. Mention that trainer versus road is chosen on the Watch. Obtain the user's explicit confirmation of that exact session. If details changed since the proposal, confirm the revised version.

After confirmation, call the scheduling tool once. If the result is uncertain, inspect the bike-workout list for a matching record before retrying; avoid duplicates. Report the created title, scheduled local time, and returned status. The record is pending until the user opens Lion Lift and uses **Workouts → Bike → Sync Workouts** to put it in Apple Fitness/on the Watch. If the write fails, state the failure without implying that the workout was scheduled.

View saved version →

---
name: schedule-lift-workout
description: Turn a user-approved lift into a scheduled Lion Lift session. Use when the user asks to schedule a lift; confirm the date and every exercise's exact sets, weights, and reps before creating it.
---

# Schedule a lift workout

Create the lift the user approved using Lion Lift's lift scheduling tool. A proposal from `propose-lift-workout` is useful but not required.

## Prepare the workout

- Resolve the user's local calendar date, exercise order, every set's reps and weight, and any notes. The present tool schedules by date, not start time. Confirm ambiguous “today” or “tomorrow” near a date or time-zone boundary.
- Check Lion Lift's current scheduling schema. Call `list_known_exercises` before `schedule_lift` and use familiar catalog names where they match the intended movements. Do not silently substitute a different exercise; the app permits free-text names when needed.
- The present `schedule_lift` tool requires `scheduled_date` (`YYYY-MM-DD`) and `lifts`, each with a name and sets of numeric `weight` and `reps`; `notes` is optional. Weight is in pounds, with no separate unit field. Convert any other units carefully and show the converted values before confirmation.
- Resolve proposal ranges or effort cues into exact set values before scheduling. Do not invent loads from an effort target or use zero to represent bodyweight without confirming what the user wants logged. If a requested element, such as timed holds or rest periods, cannot be encoded as sets of weight and reps, explain the limitation and agree on a faithful notes-based representation or leave it out.

## Confirm and create

Before the write, show the exact calendar date, each exercise and every set's weight in pounds and reps, plus the notes that will be saved. Obtain explicit confirmation of that complete record. If details changed since the proposal, confirm the revised version.

After confirmation, call `schedule_lift` once. If the result is uncertain, inspect the relevant scheduled lift records before retrying; avoid duplicates. Report the scheduled date and returned status. If the write fails, state the failure without implying that the workout was scheduled.

View saved version →

---
name: schedule-run-workout
description: Turn a user-approved run into a structured Lion Lift workout. Use when the user asks to schedule a run; confirm the exact session and local date/time before creating it.
---

# Schedule a run workout

Create the run the user approved, using Lion Lift's structured run scheduling tool. A proposal from `propose-run-workout` is useful but not required; the user may supply their own session.

## Prepare the workout

- Resolve the user's local calendar date and start time, indoor or outdoor setting, warm-up, every work and recovery step, repeat counts, targets, and cool-down. Ask for any missing detail needed to create the intended session. Do not infer what “today” or “tomorrow” means near a date or time-zone boundary.
- Check Lion Lift's current scheduling tool schema before constructing the call. For the present `schedule_interval_run` tool, use a distinctive `display_name`, local `scheduled_for` in `YYYY-MM-DDTHH:MM` format, `location`, optional `warmup` and `cooldown`, and at least one block with `work`, optional `recovery`, and `iterations`.
- The current goal types are open, time (seconds), distance (miles), and energy (kilocalories). Convert units carefully. Available alerts include heart-rate, pace, power, and cadence targets. Use only targets the user approved and that the tool supports. Outdoor GPS is required for pace alerts; for indoor runs, omit pace alerts or use an approved heart-rate or cadence alert.
- Preserve the intended sequence. A repeated work/recovery pair can include recovery after its final repetition; if the user's plan ends on a work step, represent that explicitly with an appropriate final block. Do not silently add or remove recovery.

## Confirm and create

Before the write, show the complete workout in plain language: local date/time, title, location, warm-up, every block and repeat count, targets, recovery, and cool-down. Obtain the user's explicit confirmation of that exact session. A general request to schedule or approval of a different proposal is insufficient if these details have changed.

After confirmation, call the scheduling tool once. If the result is uncertain, inspect the run-workout list for a matching record before retrying; avoid duplicates. Report the created title, scheduled local time, and returned status. The record is pending until the user opens Lion Lift and uses **Workouts → Run → Sync Workouts** to put it in Apple Fitness/on the Watch. If the write fails, state the failure without implying that the workout was scheduled.

View saved version →

---
name: schedule-swim-workout
description: Turn a user-approved pool swim into a structured Lion Lift workout. Use when the user asks to schedule a swim; confirm the exact session and local date/time before creating it.
---

# Schedule a swim workout

Create the pool swim the user approved using Lion Lift's structured swim scheduling tool. A proposal from `propose-swim-workout` is useful but not required.

## Prepare the workout

- Resolve the user's local calendar date and start time, warm-up, every work and recovery step, repeat counts, strokes, targets, and cool-down. Ask for missing details needed to preserve the intended session. Do not infer what “today” or “tomorrow” means near a date or time-zone boundary.
- Check Lion Lift's current scheduling schema before constructing the call. The present `schedule_pool_swim_workout` tool requires a distinctive `display_name`, local `scheduled_for` in `YYYY-MM-DDTHH:MM` format, and at least one block with `work`, optional `recovery`, and `iterations`. `warmup` and `cooldown` are optional single steps. Use each step's `display_name` for its stroke or purpose.
- Current goal types are open, time (seconds), distance (meters), energy (kilocalories), and `poolSwimDistanceWithTime` (both meters and seconds must be met). Convert units carefully. A conventional swim send-off may need explicit recovery or a different representation; do not assume the combined distance-and-time goal behaves like a send-off. If the desired timing cannot be represented faithfully, explain the limitation and ask the user to approve a concrete alternative.
- Current alerts support heart rate, power, and stroke cadence, but no pool pace alert. Use only supported targets the user approved. The scheduling tool has no pool-length parameter; the swimmer sets pool length in the Watch workout. It does not support open-water swim scheduling.
- Preserve the intended sequence. A repeated work/recovery pair can include recovery after its final repetition; if the plan ends on work, represent that explicitly. Do not silently add or remove rest or change the total distance.

## Confirm and create

Before the write, show the complete workout in plain language: local date/time, title, warm-up, every set and repeat count, strokes, targets, recovery, cool-down, and any unit conversion or representation change. Obtain the user's explicit confirmation of that exact session. If details changed since the proposal, confirm the revised version.

After confirmation, call the scheduling tool once. If the result is uncertain, inspect the swim-workout list for a matching record before retrying; avoid duplicates. Report the created title, scheduled local time, and returned status. The record is pending until the user opens Lion Lift and uses **Workouts → Swim → Sync Workouts** to put it in Apple Fitness/on the Watch. If the write fails, state the failure without implying that the workout was scheduled.