Update to Food Diary

{
  "description": "Food (Еда) diary workflow for meal logging, corrections, daily meal plans, diary summaries, favorites, nutrition goals, and weight progress.",
  "included_files": [],
  "name": "food-diary",
  "skill_md_contents": "---\nname: food-diary\ndescription: Food (Еда) diary workflow for meal logging, corrections, daily meal plans, diary summaries, favorites, nutrition goals, and weight progress.\n---\n\n# Food diary\n\nComplete the requested Food task and answer in the user's language.\nFood MCP results are the source of truth.\n\n## Complete the diary task first\n\n- Discover and use the installed Food tools by their actual names and schemas.\n  Resolve the calendar date in the user's timezone. Ask only when the food\n  itself is unclear or several favorites match; otherwise record directly. For usual foods, search\n  `get_favs` for each product and follow pagination; reuse the selected snapshot.\n  If the requested portion differs, scale its saved nutrition by the quantity\n  ratio in the same unit; clarify incompatible units rather than guessing.\n- Use nutrition the user states or a saved favorite holds. Otherwise look up\n  typical values for the food, preparation, and portion from a reliable source\n  (for example USDA FoodData Central or the product label online) and record\n  them without asking. Say briefly that they are estimates and name the source.\n  If the portion is missing, use a typical serving and state it. Values are per\n  serving, not per 100 g. Food writes need all five nutrients; never fill an\n  unknown one with zero.\n- Save consumption with `record_meal`. For corrections or deletions, identify\n  the entry and current revisions with `list_meals` and `read_day` before using\n  `update_meal` or `delete_meal`. Preserve the tools' revision and retry rules.\n  Confirm a write only after a successful result, including an identical replay.\n- A successful meal write returns the updated day totals. Do not call\n  `read_day` again just to show the day. Call `read_goal_progress` when\n  discussing remaining intake. Use the returned totals rather than adding the\n  write result to an old chat summary.\n- For day reviews, read the requested day and its meal entries; for date ranges,\n  use `read_nutrition_stats`. Follow pagination for complete entry lists. Report\n  per-nutrient coverage, denominators, and provisional current-day status.\n- A meal plan is a proposal, not consumption. Use favorites, stated values, and\n  looked-up estimates to assemble it; show “План” separately from “Записано”.\n  Only log planned meals when the user explicitly asks to record consumption.\n  Food has no meal-plan persistence tool: do not claim that a proposal was saved.\n- Use the relevant favorites, goals, or body tools for other Food tasks. Targets\n  and weight plans are user choices. Preserve measured dates and coverage.\n\n## Report confirmed data\n\nFood returns data only and draws nothing. Answer in short text with the\nconfirmed entries and the day's totals; how to present them is ChatGPT's choice.\n\nKeep unknown nutrition as “неизвестно” / “unknown”, including legacy data.\nLabel `knownValue` and `knownTotal` as partial known sums. Missing dates are gaps,\nnot zero intake. Goals use the current targets even for past dates. A calorie\nbudget differs from a protein target; exceeding protein is not a failure.\nNever claim that all food eaten was logged.\n\nAny chart uses only returned Food data. Keep credentials,\ntokens, owner identifiers, and request IDs out of answers.\n\n## Write safety\n\nNever retry, undo, or repeat a successful Food write to change how the answer\nlooks. If a post-write read fails, keep the confirmed write and summarize its\nreturned items; state that day totals are unavailable rather than using stale\ntotals. If the write result is uncertain, resolve it using the tool's\nidentical-payload retry rules before claiming success; a new request ID could\nduplicate food.\n"
}