← Fitness LedgerCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Fitness Ledger
Snapshot Sep 30, 2026 · 23:15 UTC · version 1.0.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"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.",
"included_files": [],
"skill_md_contents": "---\r\nname: weekly-review\r\ndescription: Review a completed nutrition and fitness week in ChatGPT Library using the user's persisted targets, canonical ledger, and reconciled activity data.\r\n---\r\n\r\n# Weekly Review\r\n\r\nUse this skill when the user asks for a weekly review, weekly recap, seven-day summary, adherence review, trends, or a nutrition/fitness cross-reference.\r\n\r\n## Source and date rules\r\n\r\n- 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.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- Treat missing nutrient fields as `unknown`, never as zero. Distinguish measured, labeled, reference-derived, reconstructed, and unknown values in the review.\r\n\r\n## Targets are user-specific\r\n\r\n- Never invent, assume, or substitute a calorie, protein, fiber, micronutrient, step, or weight target.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- Record the target basis and provenance in the narrative (for example, `USER_EXPLICIT` or `LEDGER_TARGET`).\r\n\r\n## Required review sections\r\n\r\n1. **Window and data quality** — local dates, number of days represented, missing days, late-arriving source data, unresolved conflicts, and unknown coverage.\r\n2. **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.\r\n3. **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.\r\n4. **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.\r\n5. **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.\r\n6. **Actions** — concise, evidence-backed adjustments tied to the observed data. Do not prescribe medical treatment or infer a deficiency from incomplete coverage.\r\n\r\n## Output contract\r\n\r\n- State the exact window and timezone first.\r\n- Provide a compact daily table followed by weekly averages/totals, target comparisons, data-quality caveats, and findings.\r\n- Keep measured values separate from estimates and unknowns.\r\n- Explain whether each conclusion is supported, suggestive, or unavailable because of missing data.\r\n- 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.\r\n"
}SHA-256: ab30675e055748e2dde632ffe59e8b7efe9597877be4124e497c29d070846c44