Telo

View saved version →

---
name: long-term-trends
description: Analyze months or years of the connected user's telo history using weekly or monthly aggregates, comparable periods and explicit coverage. Use for historical trends, seasonal comparisons or changes over time.
---

# Long-term trends

Use the connected telo account and answer in the user's language. Respect the user's chosen metrics and time range; for an open-ended request, start with the last 12 complete calendar months ending before the current local month and state that choice.

## Inspect and retrieve

Call `data_status` to inspect recorded date ranges and the latest received upload. Reuse its metric inventory or call `list_metrics` to discover exact metric names and units. Import progress and HealthKit read permissions are unknown, and a recent upload does not prove fresh or complete data. If `data_status` is unavailable, disclose that limitation and use available discovery tools. Never infer a confirmed sync failure from an old occasional measurement.

Use the user's current local date from context; ask if it is needed and unavailable. Do not shift requested periods to make stale records look current. If no records overlap the requested range, say so and identify available dates.

Call `query_daily` with explicit inclusive `from`/`to` dates and `granularity: "month"` for years or `"week"` for shorter trends. The response means:

- `value` uses `aggregation`: either the sum of recorded daily values or their unweighted average. These are not averages of all original sensor samples.
- `daily_min` and `daily_max` are extrema of stored daily values, not intraday extremes.
- `days_present` counts recorded dates; `days_expected` counts calendar dates in `period_start`–`period_end`, clipped to the query. Neither proves continuous sensor wear.
- A completely absent bucket or metric produces no row. Represent that interval as a gap, not zero. Keep units and aggregation methods separate across changes.
- Weekly `period` labels use SQLite `%Y-W%W`: Monday weeks split at New Year, not ISO weeks. Use `period_start` and `period_end` to interpret boundaries. Workout `sessions(granularity: "week")` uses Monday-date buckets with a different New Year convention; do not join the labels as if identical.

## Recover complete results

On `truncated: true`, discard the incomplete response before combining results. First request fewer metrics, then split into non-overlapping ranges at full bucket boundaries (month starts for monthly data, Mondays and January 1 for the existing weekly buckets). Keep the original outer bounds. Retry only the affected batches.

Prefer not to split a bucket. If it must be split, combine sums by addition, means weighted by `days_present`, minima/maxima with min/max, and coverage only across disjoint subranges. Never average averages equally or sum repeated buckets from overlapping retries. If a single bucket and metric still truncates, report that the full result could not be retrieved; do not loop indefinitely.

For a suspicious change, query daily values around that period. Use workout sessions or details only if needed to answer the user's question. Follow `workout_detail`'s independent cursors; historical summaries may exist after raw series expire.

## Interpret comparable periods

Identify the direction and dated changes the records support. Compare the latest three complete calendar months with the same months in the prior year only when both periods have usable observations; show coverage differences and avoid treating incomplete cumulative totals as behavioral changes. Distinguish a single year-over-year difference from established recurring seasonality. For a requested current month, label it partial and compare matching elapsed calendar days if useful.

For sum metrics, show recorded totals with covered days. A per-observed-day average may be useful but must be labeled and does not estimate missing days. For average metrics, weight multi-bucket comparisons by observed days and preserve units. Avoid percentage changes when the reference is zero. A device or recording-method change is a possible explanation, not a fact unless returned evidence supports it; daily aggregates do not identify the source device.

Present the range, granularity, coverage, a compact table or chart, and the changes with supporting numbers. Show gaps in charts. Separate observations from hypotheses; do not diagnose, infer causation or declare biological age/readiness from these trends. Explicitly state when coverage prevents a reliable comparison.

View saved version →

---
name: weekly-health-review
description: Compare two consecutive seven-day periods of the connected user's telo sleep, activity, workouts and personal baselines, with explicit data coverage. Use for a weekly health review or week-over-week recap.
---

# Weekly health review

Use the connected telo account and answer in the user's language. This workflow reads records; it does not schedule future reports or change connections.

## Establish availability and dates

Call `data_status` before interpreting the records. Its `last_ingest` is a received upload batch, including empty uploads and re-sent records, not proof that sync finished. Collection ranges and per-metric dates describe stored records. `history_import` and `healthkit_read_permissions` are unknown: do not claim an import is running, complete, or that permission was denied. An old workout alone does not prove stalled sync.

If there are no records, explain that no data has reached telo and direct the user to check sync in the telo iPhone app; do not invent a review. If a tool is unavailable in the installed version, state the limitation and use only available tools. Do not silently claim freshness was verified.

Use the user's local calendar date from conversation context, or ask when it is unavailable. Do not infer today's timezone from a historical workout offset. Unless the user specifies another period, use:

- Recent interval: today minus 7 days through yesterday, inclusive.
- Comparison interval: today minus 14 days through today minus 8 days, inclusive.

For 2026-10-24 these are 2026-10-17–2026-10-23 and 2026-10-10–2026-10-16. Both have seven days and no overlap. Honor explicit calendar-week requests; label a requested current, incomplete week as partial. Never silently move the window backward to hide missing recent data.

## Retrieve and compare

1. Discover exact names and units with `list_metrics` (or reuse the metric inventory just returned by `data_status`). Select available sleep-related daily metrics, resting heart rate, HRV, activity and body measurements relevant to the request; do not assume names from another provider.
2. Call `query_daily` with `granularity: "day"` over the two intervals. This avoids calendar-week buckets splitting the requested rolling weeks. Separate the returned dates into the two windows. Use `sessions(kind: "sleep")` for nights and `sessions(kind: "workout")` for workout counts, duration and distance. Query only the categories needed.
3. Track missing dates per metric. A missing row or null is unavailable, not zero. A recorded zero is valid. Days with body measurements need not occur every day; report the observation count. Multiple sleep sessions on one date are not multiple nights: distinguish naps if the records support it, otherwise describe sessions. Do not add overlapping session durations or time in bed to sleep stages. Sleep duration excludes awake stages; preserve local timestamp offsets.
4. For `aggregation: "sum"`, report the recorded total and its covered days. For `avg`, average the observed daily values. Keep different units or aggregation methods separate. Report workout totals as recorded workouts; absent workouts cannot by themselves establish rest days. Do not treat incomplete totals as evidence that activity fell. Do not extrapolate missing days.
5. If available and relevant, call `derived_metrics` for the recent window to contextualize HRV/resting-HR against preceding personal baselines. Respect `insufficient_data` and the reported baseline sample count. Training load is duration in minutes, not intensity-weighted TSS or a readiness score; its zero-workout days may include missing uploads.

If a response is truncated, discard it as an incomplete result and retrieve smaller non-overlapping date ranges or metric batches. For daily queries, splitting dates does not split daily buckets. Deduplicate overlapping retries by date/metric/unit/aggregation and sessions by UUID. If even a single day for a single metric or session kind is truncated, disclose the unresolved limit; do not fabricate a complete total or retry indefinitely. Use `workout_detail` only for a requested drilldown and follow its independent series and event cursors.

## Present the review

Name both date ranges. Show a compact comparison of values, units, observed days or sessions, and absolute changes; show percentage changes only with a nonzero, comparable prior value. State which comparisons have insufficient or unequal coverage. Even 7/7 recorded days does not prove full sensor wear.

Explain the few changes supported by the records, distinguishing factual differences from hypotheses. Avoid diagnosis, causal claims and prescriptive training decisions based only on these signals. If data is old or absent, report its dates and what cannot be concluded. Do not turn a missing-data review into a confident health assessment.