Calendar manager

Use this skill to maintain the canonical per-day planning layer at athlete/calendar/.

This skill owns the calendar representation layer only. It does not decide what should be planned, and it does not own external publication to TrainingPeaks or any other system. When a planned workout should later publish as a real TrainingPeaks structured workout, this skill should preserve the generic structured-workout definition inside the calendar file so external publication tools can consume it consistently.

Core rules

• Create one live file per date at athlete/calendar/YYYY-MM-DD.md.
• Use the file date as the first line: # YYYY-MM-DD.
• Store one or more independent calendar objects in the file, each under its own ## Activity title heading.
• Do not add wrapper headings such as ## Activities or ## Day summary.
• Every activity must include Id, Title, and Kind metadata lines.
• Every activity must include a ### Goal section and a ### Reasoning section.
• Use ### Workout plan for workouts and trainable sessions.
• When a workout should publish as a real external structured workout, include a generic ### Structured workout section in the calendar object.
• Use ### Event details for non-workout calendar objects.
• Include only activity-level content that belongs to the planned object itself.
• Use ### Goal to state the athlete goal or the specific performance objective this activity is serving.
• Use ### Reasoning to state why the coaching team planned the activity in this form, with enough context to explain session shape, placement, or constraints without turning the file into a long strategy memo.
• Do not turn calendar files into strategy notes, workflow instructions, sync ledgers, or execution logs.
• Durable external reference metadata is allowed when it helps identify the calendar object itself, for example TrainingPeaks ID.
• Ignore athlete/calendar/archives/ during normal calendar work unless the task explicitly asks for archived material.

Required read order

Before creating, revising, deleting, moving, or archiving calendar content, read these sources in order when they are relevant:

1. the current request or operator instruction
2. the existing target calendar day file, if it already exists
3. the athlete's current rolling plan, usually athlete/rolling-7-day.md
4. the athlete's longer-range planning source when the rolling plan is not specific enough
5. the athlete's travel schedule when timing, location, or travel constraints matter
6. the athlete's race calendar when race, pre-ride, or travel events may affect the day

Format contract

Follow the structure in references/day-template.md and the field rules in references/activity-schema.md.

The live contract is:

• one # YYYY-MM-DD heading per file
• one ## Activity title heading per calendar object
• one metadata bullet block per activity
• one fixed section pattern per activity kind, including ### Goal and ### Reasoning on every activity object
• no date text inside the activity heading itself

Kind rules

• Use Kind: event for actual races and other real-world events on the athlete calendar.
• Do not use Kind: race for normal live calendar objects; treat races as an event subtype represented with Kind: event.
• Keep Kind: workout or Kind: strength only for trainable sessions, and use the non-workout section pattern for calendar race objects.

Title creation rules

This skill owns the calendar representation of titles, not full workout-title authoring strategy.

• Keep race objects to the race name only, for example Ghost of the Gravel.
• Keep the ## Activity title heading and - Title: metadata identical.
• When a title changes, update the Id to match the tokenized title.
• When creating or substantially revising a workout title itself, read and apply skills/create-workout/SKILL.md first.

Operations

Use the operation rules in references/operations.md.

This skill must support:

• creating a new daily file with one or more activities
• adding an activity to an existing daily file
• editing activity metadata or content sections
• deleting one or more activities
• moving an activity from one date file to another
• archiving a day file when it should be preserved but removed from the active calendar set

Revision policy

• Revise the smallest affected future date set that keeps the plan coherent.
• Replace stale activity details instead of appending contradictory versions.
• Preserve unaffected activities in the same file.
• Do not leave an active daily file empty. If the last live activity is removed, either replace it with an explicit rest-day object or archive/remove the day file as instructed.
• When moving an activity to a different date, update the Id to use the destination file date plus the tokenized title.

Relationship to other skills

• Use this skill to maintain the neutral calendar layer.
• Use trainingpeaks-activity-creator to publish or revise external TrainingPeaks objects from the calendar layer when requested.
• Morning, evening, and check-in skills may read calendar files when useful, but they do not own them.

Completion standard

The task is complete only when:

• every affected live calendar file follows the calendar contract
• archived files, if any, were moved under calendar/archives/ using the archive rules
• no stale contradictory activity versions remain
• the calendar state matches the current requested plan state