Fitness Ledger

View saved version →

---
name: fitness-sync
description: Reconcile workout and activity-source snapshots into deterministic, provenance-preserving fitness facts in ChatGPT Library files; use for validation, rest-day checks, and source conflicts.
---

# Fitness Sync

Use this skill to normalize and reconcile workout and activity snapshots that the user provides or has already connected. Persist raw observations, normalized fitness facts, and diagnostics in the user's ChatGPT Library files. It is source-agnostic: connectors remain outside this plugin.

## Library-native persistence

- Resolve the selected or canonical Library fitness files before reading or mutating them.
- Read the complete relevant source snapshots and current canonical fitness data before reconciliation.
- Replace the same canonical Library file identity after validation; never create a second “latest” file for an ordinary sync.
- Preserve raw source observations, source completeness, coverage windows, stable IDs, conflicts, and audit history in the Library record.
- If the canonical fitness file is absent, ask whether to initialize one in Library. Do not write to local paths or assume a private database.

## Core rules

- Preserve raw source observations; do not fabricate a source value or treat absence as deletion.
- Require stable workout IDs, valid dates, non-negative measurements, and unique set identities.
- A complete zero-result workout pull is valid and must not delete prior canonical workouts.
- Reconcile by stable workout ID; classify records as new, updated, or unchanged.
- Do not add overlapping activity totals from different sources.
- Manual overrides outrank automated sources. Configure automated precedence explicitly for each deployment and retain conflicts as diagnostics.
- Reject incomplete, truncated, or future-dated activity responses before publishing a derived daily fact.

## Deterministic helpers

The bundled Python helpers validate and reconcile fixtures without network access and are retained as offline developer/test references. The ChatGPT runtime should use Caliber and Apple Health when those sources are connected, or reconcile user-provided snapshots when they are not; in either case, persistence uses Library reads/replacements and must not depend on launching a local process.

## Scheduled combined synchronization

The nutrition ledger's initialization contract owns the daily schedule in `sync.daily_sync_time_local`, defaulting to `23:55` local time. The scheduler must use the persisted IANA timezone and invoke `run_combined_sync` at that local wall-clock time. Every run pulls nutrition, Caliber workouts, Apple Health workouts, and Apple Health activity; it must emit a clear success or failure result even when no workouts exist. A successful run records its completion; an incomplete source response blocks publication. This is an orchestration contract for the host application: installing this skills-only plugin does not itself create an operating-system or ChatGPT automation.

Use the helpers with fixtures first. Add live connectors only outside this skills-only package, with separate authentication and privacy review.

## Safety boundary

Do not infer health conditions or prescribe medical treatment from workout/activity data. Keep source provenance and uncertainty visible whenever data is incomplete or conflicting.

Use the nutrition skill's [Library persistence contract](../nutrition-ledger/references/library-contract.md) for version-safe canonical-file reads and replacements. Fitness synchronization follows the same no-partial-write rule: if a source check, validation, reconciliation, or Library replacement fails, publish no derived fitness facts.

Referenced files: 3

View saved version →

---
name: nutrition-ledger
description: Log food, hydration, and body weight into an auditable ChatGPT Library nutrition ledger; use for corrections, daily panels, and provenance-aware nutrient totals.
---

# Nutrition Ledger

Use this skill when the user wants to log, correct, inspect, or summarize their nutrition data. Keep the conversation natural, but store entries in the user's persistent ChatGPT Library files. The canonical ledger is a Library file; never require a local filesystem path, a local process, or manual spreadsheet maintenance.

## Library-native persistence

- Search Library by the canonical filenames or the user's selected Library reference before reading or mutating data.
- Use the existing Library identity and current version when reading. Never create a duplicate copy when the canonical file already exists.
- Read the canonical ledger before every report or mutation; do not rely on search snippets or a cached state file alone.
- **Canon-first is mandatory:** resolve and read the canonical ledger before reading `Fitness_Ledger_Nutrition_Current_State.json` for any food-history, daily-food, correction, deletion, audit, or reporting request. The state file may only be used after canon as a derived cross-check.
- If canonical entries and current state disagree, canonical active entries win. Flag the cache as stale/inconsistent and rebuild or reconcile it; never omit a canonical item merely because the state/cache does not contain it.
- Never answer “show today’s foods”, “what did I eat today”, or equivalent from `Current_State` alone. Filter active canonical entries by the configured local date, then render from that reconciled canonical set.
- For a mutation, preserve the ledger's Library identity and replace that same Library file only after validation and state reconciliation succeed.
- Treat `Fitness_Ledger_Nutrition_Ledger.json` as canonical history and `Fitness_Ledger_Nutrition_Current_State.json` as rebuildable cache. The workbook is a reporting projection, not the operational source of truth.
- If a required Library file cannot be resolved, ask the user to select or upload it. Do not silently create an unrelated local ledger.
- If the user already has an established ledger under a different filename, prefer the selected or resolved existing file and preserve its identity; ask before creating or renaming anything. Generic filenames are defaults for new setups, not a reason to duplicate existing history.

## Core rules

- Treat the JSON ledger as canonical; a daily state file is rebuildable cache.
- Require a persisted IANA timezone (for example, `Europe/London`) before assigning dates. A detected local timezone may be offered as a setup suggestion only; it requires explicit user confirmation and persistence before any date-sensitive operation. Never infer it from the runtime clock or silently default to a region.
- Preserve corrections and deletions in the audit log. Do not silently overwrite history.
- Track nutrient provenance per field: A label/direct, B authoritative reference, C reconstructed estimate, D unknown.
- Track identity, portion, and composition confidence separately; never collapse them into an opaque score.
- Missing is `unknown`, not zero. Retain source-declared zeroes.
- Report item-, calorie-, and confidence-weighted nutrient coverage; gate adequacy interpretations when coverage is insufficient.
- Use package labels before generic databases for branded food. Scale known nutrients for weighed portions.
- Before reporting, reconcile from the ledger and validate it. Never report from a stale cache alone.

## DATE PREFLIGHT — REQUIRED BEFORE EVERY DATE-SENSITIVE OPERATION

Before any daily report, food log, hydration log, weight log, correction, deletion, fitness sync, or other date-sensitive operation:

1. Read the canonical ledger or initialization settings and resolve the user's configured IANA timezone.
2. If the timezone is missing or invalid, stop and ask the user to configure it. A detected timezone is a setup suggestion only and requires explicit user confirmation and persistence before proceeding. Never infer a timezone from the host, device, runtime, conversation metadata, or IP address.
3. Compute the current local date from the resolved timezone and the current instant. Never use the host/runtime date, UTC calendar date, or an unqualified `date.today()` result.
4. Show the resolved timezone and local date before mutation, for example: "Target ledger date: 2026-08-31 (America/New_York)."
5. For explicit historical dates, preserve the user's explicit date and record that it was user-assigned; do not reinterpret it through the current timezone.
6. Store the resolved timezone used for a new entry when the schema supports it. Changing a user's configured timezone must not rewrite historical entry dates.
7. Treat this preflight as a blocking guard, not explanatory guidance. Do not proceed on a failed or skipped preflight.

A successful write still requires canonical read-back verification. If the write or read-back cannot be completed, report "not persisted" and do not claim success.

## Product identity and versioning

Food masters may carry GTIN/UPC, brand/manufacturer, product name, variant,
package and serving attributes, source identifiers, verification timestamps,
and a deterministic formulation fingerprint. A same-GTIN formulation change
creates a new version linked by `supersedes_food_master_id`; it never rewrites
historical entries. Name-only or duplicate matches remain ambiguous and must
not receive unjustified Tier-A identity confidence. The offline reference
helpers live in `scripts/product_identity.py`.

## First-run setup

For a new user, initialize a ledger before logging data. Require a confirmed IANA timezone; collect only the goals the user chooses to set. Optional Apple Health and Caliber selections record local adapter intent, not credentials or a claimed live connection.

Initialization also configures the daily combined synchronization schedule. Default it to `23:55` in the user's configured local timezone (near midnight), and ask for a different `HH:MM` time if desired. The schedule must be stored in the ledger; never interpret it in UTC or the runtime host timezone. The scheduled run checks nutrition, Caliber workouts, Apple Health workouts, and Apple Health activity every day, including rest days. A successful run records its completion; a failed or incomplete source check must be reported and must not publish derived fitness facts.

After initialization succeeds, store the requested sync configuration in the Library ledger. Do not claim that an external scheduled task exists unless the host explicitly provides and confirms that capability. A user-controlled daily automation may be offered, but its absence must not block ordinary mobile logging and reporting.

Do not overwrite a ledger during onboarding. `--force` is reserved for an explicit replacement request.

## Daily reports

The bundled script is an offline developer/test reference. The ChatGPT runtime must use Library reads and replacements for persistence; mobile users must not be asked to run a command or depend on a local script.

Use the canonical renderer contract encoded in the ledger and skill. When the offline reference implementation is available in a development environment, it may be used for validation.

`panel` and `foods` have one stable report contract: header, active entry count, fixed meal order, consistent food lines, meal subtotals, daily totals, hydration, and explicit unknowns. Use plain protein totals; do not expose internal protein-credit fields.

## Conversational output contract

Apply this contract every time food or hydration is logged and every time a daily food report or panel is requested. Do not vary the structure based on how simple the entry seems.

For a successful food or hydration log, show:

1. The ledger date and configured timezone.
2. Every newly added item with its amount, calories, protein, carbohydrates, fat, and fiber. Show `unknown` when a value is unavailable; never silently omit the nutrient.
3. A subtotal for each affected meal or snack group.
4. The updated daily totals for calories, protein, carbohydrates, fat, fiber, and water when water is tracked.
5. Remaining amounts or overages against configured personal calorie, protein, and fiber targets when available.
6. Any material estimate, assumption, or unresolved nutrient identity issue.
7. A clear persistence/read-back confirmation after the canonical ledger write succeeds.

For `foods`/“foods for the day”, show every active entry grouped by the fixed meal order, followed by each meal subtotal and the full-day totals. For `panel`/“today’s panel”, retain the progress and micronutrient sections, but also include the same individual entries, meal subtotals, and full-day totals. A summary-only response is allowed only when the user explicitly asks for one.

The canonical renderer is the source of formatting for local or automated workflows. The conversational layer must preserve this same information when presenting a successful result; it must not replace the detailed confirmation with only the new daily total.

Natural-language report routing is mandatory:

- “Show today’s food,” “what did I eat today,” or equivalent requests map to `foods`.
- “Today’s panel,” “today’s numbers,” or equivalent requests map to `panel`.
- “Full nutrient panel” maps to `panel` followed by the labeled micronutrient section.
- Before either `foods` or `panel`, read canonical history first, select active entries for the configured local date, and reconcile state from those entries. `Current_State` is never the primary read source.
- If `Current_State` omits an active canonical item, include the canonical item in the report and mark/rebuild the state as stale rather than returning the incomplete cache view.
- Never manually reconstruct a daily report from raw JSON, a cache, or ad-hoc calculations when the canonical renderer is available.
- The Progress section reports calories and protein against the user’s personal targets (when configured), never FDA Daily Values. `%DV`/reference percentages belong only in the micronutrient section.
- If a personal target is unavailable, render the target as unavailable; do not substitute a generic DV.

For micronutrient panels, append a clearly labeled nutrient section after the canonical daily panel. Show amount plus %DV/reference for each known nutrient and `unknown` for missing fields.

## Safety boundary

This is a data-quality and tracking workflow, not medical diagnosis or treatment. Do not infer nutrient deficiencies from one day or incomplete coverage. Keep the user in control of every mutation and do not transmit ledger contents to external services unless they explicitly ask for it.

Read [the schema reference](references/schema.md) before modifying schema, provenance, cache, or workbook behavior.

Read [the Library persistence contract](references/library-contract.md) before implementing or changing Library-backed read, mutation, cache, or conflict behavior.

The offline reference modules in `scripts/` expose identity/versioning,
confidence, coverage, source resolution, barcode, enrichment, invariants,
debt, longitudinal, contribution, activity-join, and migration primitives.
They are testable building blocks; ChatGPT runtime persistence still follows
the Library contract above.

Referenced files: 18

View saved version →

---
name: weekly-review
description: Review a completed nutrition and fitness week in ChatGPT Library using the user's persisted targets, canonical ledger, and reconciled activity data.
---

# Weekly Review

Use this skill when the user asks for a weekly review, weekly recap, seven-day summary, adherence review, trends, or a nutrition/fitness cross-reference.

## Source and date rules

- Resolve the canonical Library nutrition ledger before calculating anything. The ledger is the source of truth; rebuildable current-state files and workbook projections are not sufficient by themselves.
- Use the ledger's persisted IANA timezone for every day boundary. A review window is seven complete local calendar days unless the user explicitly supplies another range.
- Include only entries and fitness observations whose local date falls inside the requested window. Do not leak data from the day before or after the window.
- Reconcile fitness inputs before analysis. Apple Health is canonical for automated steps when present; an explicit persisted manual override supersedes it. Preserve and disclose source conflicts rather than silently summing duplicates.
- Treat missing nutrient fields as `unknown`, never as zero. Distinguish measured, labeled, reference-derived, reconstructed, and unknown values in the review.

## Targets are user-specific

- Never invent, assume, or substitute a calorie, protein, fiber, micronutrient, step, or weight target.
- Use only targets explicitly stored in the user's ledger or explicitly supplied by the user in the current conversation. If a target is absent, report the metric without a target comparison and label the comparison unavailable.
- In particular, never use a hard-coded 2,000-kcal standard. A generic Daily Value may be shown only in the micronutrient reference section, never as the user's calorie target.
- Preserve the distinction between a single daily target and a target range. For ranges, report the range and the number of days within it; do not collapse it to an invented midpoint.
- Record the target basis and provenance in the narrative (for example, `USER_EXPLICIT` or `LEDGER_TARGET`).

## Required review sections

1. **Window and data quality** — local dates, number of days represented, missing days, late-arriving source data, unresolved conflicts, and unknown coverage.
2. **Nutrition** — daily and seven-day totals/averages for calories, protein, carbohydrates, fat, fiber, and hydration when available. Compare calories and protein only with user-specific targets. Show target attainment as a range or percentage only when the target exists.
3. **Micronutrients** — weekly totals/averages or coverage notes for tracked nutrients, with amount plus `%DV`/reference only where the reference is defined. Unknown is not deficiency.
4. **Fitness and activity** — canonical steps, workout/cardio sessions, and relevant body metrics. Flag suspicious post-hoc workout durations; do not use them for workout-density conclusions unless the user confirms they are valid.
5. **Cross-reference and trends** — compare nutrition and activity on workout versus rest days, and use non-overlapping 24/48/72-hour pre-workout windows when relevant. Use smoothed weight trends and ranges rather than point-cause claims.
6. **Actions** — concise, evidence-backed adjustments tied to the observed data. Do not prescribe medical treatment or infer a deficiency from incomplete coverage.

## Output contract

- State the exact window and timezone first.
- Provide a compact daily table followed by weekly averages/totals, target comparisons, data-quality caveats, and findings.
- Keep measured values separate from estimates and unknowns.
- Explain whether each conclusion is supported, suggestive, or unavailable because of missing data.
- A weekly review is read-only unless the user explicitly asks to log a correction or persist a target; never mutate the ledger merely by reviewing it.