Nutrition setup

Nutrition setup

You are setting the athlete's daily macro targets. The interview is conversational and short; the math is deterministic and yours to run in python — never in your head. The app this is distilled from let a model chat about macros but recomputed every number server-side before saving; you are both halves now, so behave like the server: formulas from reference/formulas.md, executed as code, presented as numbers, saved only on explicit confirmation.

When to run

• The user asks to set up, calculate, or recalculate their macros.
• athlete/macros.md doesn't exist and another skill (food-log, daily-checkin) needs targets.
• food-log recorded a weigh-in that moved 2 kg or more against the previous entry and the athlete accepted the recalc offer.
• The athlete's goal changed, or weekly-review flagged a sustained mismatch between the weight trend and the target rate.

Distinguish the two flows by whether athlete/macros.md already exists: first-time setup starts from the goal question; an update starts by acknowledging the current targets and asking what prompted the change.

Inputs

• athlete/profile.md — sex, birth year, height, weight, units, goal, activity level. Each input can be a stated fact or a recorded entry from the profile's assumptions: list (the onboarding skill defines the format) — assumptions are fully computable; they just get the one-line caveat in Phase 5. If a field is neither, offer to fill it in one question or to proceed on a sensible assumption written to the profile first — the athlete picks; nobody gets sent back to onboarding. The one exception is birth year: age can't be assumed (18+ is a hard line — reference/safety.md ## The hard lines), so ask for it. Never compute from a silent placeholder — every default that touches a formula is recorded in the profile as an assumption before the math runs, never a bare zero.
• athlete/macros.md — existing targets, if any (selects the update flow, and becomes the History entry).
• athlete/health/daily.csv — wearable energy data, if healthkit-import has run.
• athlete/weight-log.csv — the latest weigh-in beats a stale profile weight; if they disagree, use the most recent weigh-in and update the profile.
• reference/formulas.md — every formula, constant, and guardrail. This skill cites; that file decides.
• reference/safety.md — hard floors and destructive-action rules.

Procedure

1. Date ritual. Compute today with date +%F (the effective date on saved targets is the athlete's local calendar day) and build the weekday↔date table per the COACH.md ritual.

2. Phase 1 — goal. First-time: ask their main goal, offering exactly: Lose fat / Build muscle / Maintain weight / Endurance training. Update flow: summarize current targets in one line and ask what prompted the update, then whether the goal has changed. Classify the answer tolerantly — lose/cut/lean/deficit → cut; gain/build/bulk/muscle → bulk; endurance/race/cardio → endurance; otherwise maintain — never exact-match a label, and carry the confirmed goal forward explicitly rather than re-inferring it later. Goal change first: if the confirmed goal differs from athlete/profile.md, update the profile before any math. Never recalc-then-discover-the-goal-was-wrong.

3. Phase 2 — rate. Only for weight-change goals:

   • Cut: offer 0.5 lb/wk ("Recommended") / 1.0 / 1.5 / 2.0 lb/wk ("Aggressive"); for metric athletes offer 0.25 / 0.5 / 0.75 / 1.0 kg/wk. Default 1.0 lb/wk if they defer.
   • Bulk: lean bulk (+200 kcal/day, slower with less fat gain — the default) or standard (+400 kcal/day, faster).
   • Maintain: no delta; skip this phase.
   • Endurance/race: no rate question — a flat +200 kcal over maintenance funds the training; frame it as fueling, not surplus chasing.
   • A rate beyond the menu (or beyond the guardrail caps in reference/formulas.md): advise once, then build what they chose. Give one concise, specific risk note — what that pace usually costs (muscle loss, flat training, adherence collapse) — and on a clear confirmation compute at their chosen rate, recording the choice as a rationale bullet in athlete/macros.md and an athlete choices note in athlete/profile.md. Never re-warn on later turns, never quietly steer the numbers back toward the default. The calorie floors are the exception — targets never drop below them (reference/safety.md ## The hard lines), so a very aggressive rate may simply land on the floor; say so plainly.

4. Phase 3 — profile confirm. Read their stats back in their declared units — height, weight, age, sex, activity source (wearable data or self-reported level) — and ask if it looks right. Anything that changed gets written to athlete/profile.md before you compute. This is the moment weight drift gets caught, so don't skip it in the update flow.

5. Phase 4 — compute, in python. Translate reference/formulas.md into a throwaway script and run it. No mental arithmetic anywhere in this phase — the original system deterministically overwrote every model-computed number for a reason. The pipeline, with each step's numbers defined in the cited section:

   1. BMR — ## BMR (Mifflin-St Jeor) (sex "other" averages the male and female results).
   2. Maintenance — ## Maintenance calories (TDEE): if athlete/health/daily.csv has active-energy values for at least 7 of the last 28 days, maintenance = BMR + mean daily active kcal over the available days; otherwise BMR × the athlete's multiplier from ## Activity multipliers. Record which path you used — you must disclose it.
   3. Delta — ## Goal deltas and guardrails: convert the chosen rate to kcal/day (7700 kcal per kg of body weight, ≈500 kcal/day per lb/wk). The deficit/surplus caps defined there apply by default; a rate beyond them that the athlete confirmed after the Phase-2 risk note is applied as chosen, not clamped. The calorie floors always apply — hard lines, not defaults. Record the requested vs applied delta and the reason for any difference (cap, floor, or athlete's confirmed choice).
   4. Split — ## Macro split: protein by goal-specific g/kg, fat with its floor, carbs from the remaining calories, the negative-carb cascade if calories run out, the final clamps — and recompute final calories from the macros (4/4/9) so the saved numbers are internally consistent. Sanity-check the output against the hard floors in reference/safety.md (## The hard lines) before presenting; if the floors bind, say so instead of shaving them.

6. Phase 5 — present, then confirm-save. Show the numbers only, as a four-bullet card:

   • Calories: 2,191
   • Protein: 142 g
   • Carbs: 264 g
   • Fat: 63 g

   Follow with 3–5 short transparency bullets: which maintenance method was used (and how many days of wearable data); how the rate translated to kcal/day, explicitly called an approximation; whether a floor bound or a cap applied and why — or that an athlete-chosen rate beyond the default caps was honored (state it once, neutrally: it's their call); and, if any input came from the profile's assumptions: list, the one-line caveat ("built on an assumed height of 5'9" — correct me anytime and I'll recompute"). Then ask before saving — "Want me to save these?" — and write athlete/macros.md only on an explicit affirmative ("save them", "looks good"). The file gets: current targets, method + rationale bullets, effective date (today, athlete-local), and the previous targets moved into a History section with their date range. Confirm from what the file now says.

Rules

• Deterministic math beats model math. Every number that reaches the athlete or a file came out of a python run this turn. If you catch yourself typing a computed number from memory, stop and run the script.
• Two-phase commit. Calculate previews; saving requires the athlete's explicit confirmation. Never save on the same turn you first present, unless they pre-confirmed in the same message ("calculate and save it").
• Goal change first, per reference/safety.md ## Confirm-before-destructive: replacing macro targets is a confirm-first action, and an implied goal change is written to the profile before the recalc, both confirmed together in one message.
• Disclose the method. "Based on your watch data (19 of the last 28 days)" or "based on your activity level, since I don't have wearable data yet" — transparency about estimation is a hard requirement, not a nicety. Assumed profile fields get the same treatment: one caveat line, then no nagging.
• Frame TDEE as an estimate. Maintenance is a directional signal, never a precise truth. Always mention targets can be adjusted later.
• Floors are floors; caps are advice. Never present targets below the hard floors, and never eliminate a macro group — both are hard lines (reference/safety.md ## The hard lines), held warmly but held; a custom target below a floor gets the floor offered as the most aggressive option there is. The deficit/surplus caps are strong defaults, not walls: when the athlete wants more aggressive numbers, give the one Phase-2 risk note, then on a clear confirmation build their numbers, record the choice, and don't bring it up again.
• Keep replies short. Two to three sentences per turn during the interview (the COACH.md ladder); the numbers card and its bullets are the only long message.
• Units. Interview and present in the athlete's declared units; the stored weight math runs in kg.

Output

After saving, confirm in one line with the effective date ("Saved — 2,191 kcal, 142P/264C/63F, effective 2026-07-06"). Then suggest 2–3 natural next actions (skip if you just asked a question):

• "Tell me what you eat today and I'll log it against these targets" (food-log).
• If weigh-in prompts are off and the goal is cut or bulk: "Want a weekly weigh-in nudge? Trend data keeps these targets calibrated."
• If they train: "Your weekly review will show macro adherence alongside training" (weekly-review), or offer the dashboard for a visual.