Activity schema

Use this schema for every activity or event stored in a live calendar file.

Required fields

Each calendar object must include:

• ## Activity title
• - Id: YYYY-MM-DD-tokenized-title
• - Title: Activity title
• - Kind: ...

Title rule

• Keep race objects to the event name only.
• Keep the heading and Title metadata exactly the same.
• If the title changes, rebuild the Id from the new tokenized title.
• When creating or substantially revising a workout title itself, read and apply skills/create-workout/SKILL.md first.

Usually required when relevant

Add these metadata fields when they materially describe the object:

• - Discipline: ...
• - Surface: ...
• - Priority: ...
• - Planned time: ...
• - Duration: ...
• - Distance: ...
• - Intensity: ...
• - Location: ...

Optional durable metadata

These fields are allowed when they are durable identifiers or useful object metadata:

• - TrainingPeaks ID: ...
• other external reference IDs
• additional flags or metadata lines that help identify, correlate, or qualify the object

Do not add tool instructions, API payload notes, or sync-state chatter.

Id rule

• Build the Id from the file date plus a tokenized form of the title.
• Use lowercase words joined by hyphens.
• Example: Tempo durability ride becomes 2026-04-16-tempo-durability-ride.

Supported enum values

Kind

• workout
• strength
• event
• travel
• rest

Actual races in the live athlete calendar should use Kind: event, not Kind: race.

Discipline

• bike
• mtb
• cx
• strength
• mobility
• recovery
• travel
• off-bike

Priority

• key
• support
• maintenance
• optional
• informational

Planned time rule

• Use unscheduled by default.
• Use a real clock time only when the plan gives one or the schedule requires one.
• Coarse values such as morning, afternoon, evening, after ride, or all day are allowed when they are genuinely useful.

Section variants

Workout or strength session

Use:

• ### Objective
• ### Goal
• ### Reasoning
• ### Workout plan
• ### Structured workout, when a generic machine-loadable workout should be preserved for external publication such as TrainingPeaks
• ### Supporting work, when needed
• ### Recovery, when needed
• ### Fueling, when needed
• ### Constraints, when needed
• ### Notes

Event, travel, rest, or other non-workout object

Use:

• ### Objective
• ### Goal
• ### Reasoning
• ### Event details
• ### Constraints, when needed
• ### Recovery, when needed
• ### Fueling, when needed
• ### Notes

Splitting rule

Create a separate activity only when it should be independently visible, editable, or publishable.

Usually separate:

• bike session and gym session
• race and pre-ride
• travel and opener
• workout and a separately meaningful recovery appointment

Usually keep embedded inside the parent activity:

• pre-ride activation
• short post-ride mobility
• brief recovery reminders
• fueling notes tied to one main session

Content boundary

Allowed content:

• session prescription
• event details
• activity-specific constraints
• fueling and recovery instructions tied to the object
• short object-level notes
• a concise activity-specific goal statement
• concise coaching reasoning for why the activity is planned this way

Disallowed content:

• long-range strategy
• full season rationale copied into the day file
• operator workflow notes
• MCP or API instructions
• sync bookkeeping
• execution logs about what actually happened
• overly long reasoning sections that turn the calendar object into a planning essay