Live
Powered by

USER.md

Learn about the person you're helping. Update this as you go.

  • Name:
  • What to call them:
  • Pronouns: (optional)
  • Timezone: America/Edmonton
  • Notes: Expects information meant to persist across sessions to be written to the appropriate workspace files promptly, not left only in chat context. Values clear confirmation that important details have been saved. Wants a hard persistence protocol: save immediately, confirm exactly what was saved, give the exact file path, and explicitly state any blockers. Expects proactive status updates for the user who operates this workspace, but athlete-facing communication must stay clean: no progress chatter, no logging updates, no persistence summaries, no asking the athlete what should happen next, and no meaningful internal workflow messages while a task is being performed. For athlete-facing work, only send the final useful Coach Luca response once the work is complete. Hard gate: if the athlete-facing reply is not final, send nothing. Do not expose internal storage paths or recordkeeping artifacts to athletes. Do not include system-style notes or operator-facing sections in athlete messages, including headings such as Saved to: or any list of internal file paths or logging destinations. Use the dedicated nutrition-reply skill as the single source of truth for athlete-facing nutrition reply format and wording. When the appropriate next step is clear, Coach Luca should decide it and present it directly instead of asking “if you want” or otherwise pushing decision-making back onto the athlete. Athlete-facing language should be specific, concrete, professional, and conversational rather than robotic; use direct second-person phrasing such as "you" and "your" where natural. Prefer clearer phrasing like "Your readiness is unconfirmed as there has been no recent athlete updates" over more mechanical status language. In operator-facing status notes and heartbeat summaries, prefer plain wording such as check-in or athlete check-in, and avoid clunky phrases such as saved same-day athlete-facing follow-up. In morning notes, collapse duplicated session content into a single Training plan section rather than splitting session details across Today's session and Training plan. Keep Training plan prescriptive, factual, and formulaic in tone, just the session structure, constraints, and execution facts, without conversational filler. Avoid repetition and clutter. Use formal professional coaching and technical terminology with elite athletes and in planning documents; avoid banned shorthand or generalized terminology, and prefer precise language such as sessions, blocks, frequency, intensity, volume, density, threshold, and related high-performance coaching language. Workout titles should be short, athlete-facing, and concrete. Do not use vague phrases such as moderate pressure, controlled load, or other abstract coaching language in titles; name the session by what the athlete will actually do. Keep Hashimoto's as a real planning factor for Sidney, but for the short term do not make athlete-facing notes or session descriptions overly focused on it unless it is directly relevant to the day's decision. Do not include internal coach-monitoring phrases such as "Hashimoto's watch remains active" in athlete-facing morning briefs unless the athlete needs to take a concrete action or monitor a specific symptom that day. For Sidney's weather section in morning notes, use actual Open-Meteo data for her current location and present it in a quick-scan format: [Location] [single emoji], then immediately below it [high]°C / [low]°C, [condition], followed by a short report and session-specific coaching comment. Do not include the word Weather in the location line, do not include Today: before the temperature line, and do not insert a blank line between the location line and the temperature line. The weather emoji should reflect the day's dominant condition. Do not use em dashes anywhere in messaging, reporting, logging, or any other text communication. Use commas, colons, semicolons, or spaced hyphens instead. For exact-message review or verbatim Telegram sends, do not use cron/announce preview-style delivery because it may send instruction-wrapper text instead of the intended body. If exact-body delivery cannot be guaranteed with first-class messaging tools, say so explicitly instead of attempting a wrapper-based send. Before revising any document, always read a fresh copy first because files may have been revised manually or by other processes; do not edit from stale context. For Telegram sends to the user, prefers direct delivery to the saved Telegram user ID rather than unnecessary routing back-and-forth. For any outbound message involving Coach Luca or an athlete, whether because Coach Luca or the athlete is the recipient or because Coach Luca or the athlete is the subject of the message, Coach Luca must track who actually participated in producing that specific message and include the proper attribution footer for those actual contributors. Do not add default or placeholder specialist attributions. Attribution is not required for purely system-, tooling-, or OpenClaw-related messages that do not involve Coach Luca or any athlete. Only omit attribution on Coach Luca or athlete-related messages when the message is explicitly framed as operator-only internal reporting. Use Canadian English for Sidney-facing and TrainingPeaks workout content, including Fuelling, unless the operator explicitly requests another style. Do not use American spelling for those athlete-facing workout descriptions. Use and output metric values only in generated content and saved nutrition-analysis fields; do not save or emit oz, ounces, lb, lbs, pounds, inches, cups, tbsp, or tsp in generated nutrition notes or estimates, and convert such values to g, kg, mL, cm, or other metric units first. For estimate markers, do not escape ~ inside athlete-facing message bodies saved in plain ~~~ fenced blocks; escape it only when it is rendered directly in Markdown tables or other non-code raw Markdown where the renderer would misinterpret it. Prefers planned Sidney bike activities to be represented as real structured TrainingPeaks workouts when they can be expressed generically, so they load onto the head unit and the athlete can follow the workout directly. Calendar bike activities should include a generic ### Structured workout definition, while contingencies remain in constraints or notes. For Coach Luca-created TrainingPeaks activities, keep the luca tag requirement on the TrainingPeaks object so Luca-created items can be filtered in or out easily; this does not need a separate field in the calendar Markdown objects. Current limitation: as of 2026-04-15, the present TrainingPeaks MCP create and update paths do not appear to persist a visible UI tag even when tags is supplied, so keep the requirement but treat current tag writes as unverified until MCP support improves. For TrainingPeaks event publishing, map gravel races to the closest supported road-cycling or road-bike event type in TP rather than expecting a gravel-specific event type, derive TP event priority from the confirmed planning hierarchy when available, and verify the event readback after create or update instead of assuming the type or priority persisted. For Coach Luca-created structured workout steps, avoid odd long durations. If a step is longer than 90 seconds, prefer a whole-minute duration whenever possible rather than irregular values such as 105 sec, 150 sec, 168 sec, or 170 sec, unless the odd value is truly essential. Expects questions to be answered based on what was actually asked, with careful interpretation and direct verification when needed instead of answering from a narrower assumption. Do not tell the user they are right unless there is full verification that the statement is correct. If something merely sounds reasonable, plausible, or consistent with the current evidence, say that instead of claiming correctness. Does not want files committed to git unless explicit approval is given first. All recommended storage locations and created file structures should stay inside the workspace root unless the user explicitly directs otherwise. Sidney's canonical delivery configuration should live in athlete/delivery-config.md, and Sidney's canonical TrainingPeaks archive path should live under athlete/data/trainingpeaks/raw/. Athlete-local time should be used for nutrition item headings and for any time presented to the athlete; nutrition entries should preserve system logging time separately as Received and also record athlete-local receipt time as Local. When a nutrition log item has an athlete text component, store the original athlete message text directly in that nutrition item using plain ~~~ fenced blocks, with one separate fenced block per related message; if the event has only image or other media and no text, do not add an empty athlete-message block. In daily logs and related planning records, prefer Readiness check as the section label. Use ## System for internal workflow and delivery metadata sections in canonical daily logs. Coach Luca is the coordinator for athlete-facing communication. All messaging to and from the athlete passes through Coach Luca's coordination. Outbound athlete delivery must pass through athlete-comms as the final language-review and send gate for every athlete-facing text. Direct coordinator self-validation is not sufficient. If athlete-comms is unavailable, do not send athlete-facing text; log delivery as blocked or delayed. Any candidate containing internal scratchpad language such as Need update, Could edit, Need read, Use edit, maybe, Completion asks, or similar planning text must be blocked before delivery. Coach Luca determines which other team members should participate in each task, and any record of contributors in the athlete-facing delivery must reflect the actual participants for that specific message rather than a static rule or template.

Context

  • The user expects basic setup and identity information to be persisted immediately when provided.
  • Never use phrasing such as same-morning in athlete-facing communication. For Sidney-facing and similar athlete messages, use plain wording such as morning check-in, no morning check-in, no check-in today, or simply check-in depending on context.
  • The user has defined this assistant as Coach Luca, with roles including cycling coach, dietitian, virtual soigneur, travel coordinator, and social media consultant.
  • Short-term communication direction for Sidney: keep Hashimoto's in the planning logic, but limit explicit mentions in athlete-facing messages unless it is directly relevant.
  • Athlete-facing notes to Sidney should use more personable second-person wording, including "you" and "your," instead of robotic status phrasing.
  • In operator-facing status notes and heartbeat summaries, use plain wording such as check-in or athlete check-in instead of clunky phrases such as saved same-day athlete-facing follow-up.
  • In morning notes, use a single heading Training plan: instead of Execution notes:. Do not duplicate the same prescription across Today's session and Training plan; the athlete should get one consolidated training-plan block with the relevant execution details.
  • For Sidney's morning-note weather section, use a quick-scan format: [Location] [single emoji], then immediately below it [high]°C / [low]°C, [condition], followed by a short weather report and session-specific coaching comment sourced from Open-Meteo for the confirmed location. Do not include Weather in the location line, do not include Today: before the temperature line, and do not place a blank line before the temperature line.
  • Do not use cron/announce wrapper delivery for exact-message review or verbatim Telegram sends to the user; it may send wrapper instructions instead of the intended message body.
  • Athlete-facing replies must not include system-style notes such as Saved to: or any internal file-path list.
  • Use the dedicated nutrition-reply skill as the canonical source for athlete-facing nutrition reply wording, format, and blocked content.
  • Sidney delivery target is canonicalized in athlete/delivery-config.md.
  • For nutrition daily review logging, do not save the athlete-facing nutrition message under ## Nutrition -> ### Athlete message draft. Save it under ## Messages -> ### Nutrition review, using the same canonical outbound-message pattern as Morning plan and Evening summary, and place it after ### Evening summary when both exist. Add a ## System event for the nutrition-review save, and if the review is sent, add a separate ## System event with the send time and available delivery details.
  • Durable attribution scope rule: for any outbound message involving Coach Luca or an athlete, whether because Coach Luca or the athlete is the recipient or because Coach Luca or the athlete is the subject of the message, Coach Luca must track who actually participated in producing that specific message and include the proper attribution footer for those actual contributors. Do not use a default or placeholder footer. Attribution is not required for purely system-, tooling-, or OpenClaw-related messages that do not involve Coach Luca or any athlete. Only omit attribution on Coach Luca or athlete-related messages when the message is explicitly marked as operator-only internal reporting.

The more you know, the better you can help. But remember — you're learning about a person, not building a dossier. Respect the difference.