Live
Powered by

Create-workout skill proposal

Summary

This proposal recommends adding a new Coach Luca skill focused on individual workout authoring only.

The purpose of the skill is not to replace planning, calendar management, or TrainingPeaks publishing. Its purpose is narrower and more operational:

Turn an already-decided training intent into a well-authored workout object.

This fills a real gap in the current workspace.

Right now, workout-creation logic is distributed across:

  • memory rules
  • user preferences
  • calendar-format rules
  • TrainingPeaks publication behavior
  • specialist judgment
  • ad hoc coaching habits

That makes the system workable, but not clean. The authoring standards for titles, interval construction, section content, structured-workout steps, contingencies, and formatting are not currently governed by one canonical workflow.

This proposal recommends creating a dedicated skill to solve that specific problem.

Core recommendation

Build the skill with this scope:

  • individual workout authoring only
  • calendar-first output only
  • no TrainingPeaks publishing responsibility
  • strong enough output contract that TP creation can be done accurately by other skills

This is the right scope because it is tight, useful, and does not duplicate the job of existing skills.

What the skill should own

The skill should own one thing:

How Coach Luca authors a workout once the training intent is already known.

That includes:

  • choosing the correct workout architecture
  • selecting step durations and interval structure
  • deciding how much detail belongs in each section
  • writing clean athlete-facing workout titles
  • writing clear ### Goal, ### Reasoning, ### Workout plan, ### Structured workout, ### Fueling, ### Constraints, and ### Notes sections
  • keeping workout objects internally consistent
  • keeping authoring rules reusable across disciplines and phases

What the skill should not own

The skill should not own:

  • macro planning
  • weekly or block planning
  • race-priority decisions
  • final calendar storage mechanics
  • TrainingPeaks creation or update calls
  • athlete-facing message delivery
  • specialist consultation logic

Those responsibilities already belong elsewhere.

Why this skill is needed

Current gap

The current workspace has strong planning and publishing layers, but a weak authoring layer.

In practical terms, the missing question is:

How does Coach Luca reliably turn a prescription into a finished workout object?

At the moment, the answer is spread across too many places.

That causes several problems:

  • workout quality depends too much on remembered conventions
  • formatting and step construction can drift
  • title style can drift
  • structured-workout construction can become inconsistent
  • section detail can vary too much between days
  • TP publishing may be correct technically while still being based on a loosely authored calendar object

A dedicated create-workout skill would make the authoring layer explicit and reusable.

Relationship to existing skills

This new skill should sit between planning and publication.

The intended workflow would be:

  1. planning files define the training need
  2. the create-workout skill authors the workout object correctly
  3. calendar-manager stores that object correctly in the calendar layer
  4. trainingpeaks-activity-creator later publishes it to TP if requested

So this skill complements existing skills instead of replacing them.

Proposed job definition

One-line job

Author an individual workout object from an already-decided coaching intent.

Practical job definition

Use this skill when Coach Luca already knows what the athlete needs to do and now must create the actual workout cleanly.

The skill should govern:

  • workout structure
  • interval logic
  • title quality
  • description quality
  • structured-workout construction
  • section completeness
  • formatting consistency

The skill should not decide whether the athlete needs threshold, tempo, recovery, or a long gravel ride in the first place. That comes from planning.

Output surfaces

Primary output

The skill should govern calendar-ready workout authoring only.

That means the direct output should be a workout object suitable for the canonical calendar format.

Secondary requirement

Even though the skill should not publish to TrainingPeaks, it must still produce output that is strong enough for downstream TP creation.

That means the authored workout must include enough precision that another skill can accurately create the TP activity from it later.

The skill should therefore enforce:

  • clean structured-workout definitions
  • explicit intensity logic
  • explicit duration logic
  • clean naming
  • clean constraints and contingencies
  • no ambiguity between the written workout plan and the structured step list

Workout families in first version

The first version should support all workout families, not just one subset.

That includes at minimum:

  • recovery rides
  • endurance rides
  • tempo rides
  • sweet spot rides
  • threshold rides
  • VO2 or ceiling-support rides
  • race-pressure rides
  • gravel-specific rides
  • climbing torque rides
  • long rides
  • simulation rides
  • opener rides
  • strength sessions
  • movement-quality sessions
  • re-entry sessions
  • travel fallback sessions

This is ambitious, but the skill is specifically about authoring. If the scope is too narrow at launch, Coach Luca will still be forced back into ad hoc authoring for many session types.

Design principle for breadth

The skill should support all workout families from the start, but it does not need to fully hard-code every future case.

It should be designed so new session families or scenario types can be added cleanly later without rewriting the whole skill.

That argues for a structure like:

  • core authoring workflow in SKILL.md
  • variant-specific workout-family guidance in references files
  • future additions by new reference files rather than bloating the main skill file

This skill should be highly prescriptive.

That is the right choice because workout authoring is a fragile and repetitive task where consistency matters.

A vague principle-only skill would not solve the current problem.

The skill should provide concrete rules for:

  • how to choose session architecture
  • how to build step sequences
  • how to choose interval durations
  • how to write athlete-facing titles
  • how to keep descriptions short but useful
  • how to place contingencies
  • how to format structured workout steps
  • how to avoid ugly or inconsistent step construction

This does not mean every workout must follow one rigid template. It means the authoring standards must be clear enough that different workouts still come out coherent.

Proposed skill responsibilities

1. Required inputs before authoring

Before authoring a workout, the skill should require Coach Luca to identify:

  • athlete
  • discipline
  • current phase or block
  • session purpose
  • relationship to the surrounding days
  • event relevance, if any
  • travel or readiness constraints
  • whether the object is workout, strength, movement-quality, or another trainable session type

The skill should not let Coach Luca jump straight into intervals without first confirming the workout's role.

2. Workout classification

The skill should classify the session first.

Example authoring categories:

  • aerobic support
  • durable pressure
  • threshold extension
  • climbing support
  • race-pressure
  • simulation
  • re-entry
  • taper support
  • opener
  • strength
  • movement quality
  • travel fallback

This matters because different session types should follow different authoring patterns.

3. Session architecture rules

This is the heart of the skill.

The skill should define how Coach Luca builds:

  • warm-up
  • pre-load endurance where relevant
  • main set
  • recovery between reps
  • secondary set when needed
  • endurance finish or race-specific finish
  • cool-down

It should also govern how total session cost is kept coherent.

4. Section-writing rules

The skill should define what belongs in:

  • ### Objective
  • ### Goal
  • ### Reasoning
  • ### Workout plan
  • ### Structured workout
  • ### Fueling
  • ### Constraints
  • ### Notes

It should keep these sections from becoming repetitive or vague.

5. Structured-workout rules

This should be a major part of the skill.

The skill should explicitly govern:

  • when to structure a workout and when not to over-structure it
  • how to choose step durations
  • how to format duration values cleanly
  • how to use repetition blocks cleanly
  • how to keep the structured workout aligned with the written workout plan
  • how to avoid awkward irregular durations unless truly necessary

This is where current formatting rules should become formal skill rules rather than loose memory.

6. Title rules

The skill should standardize workout titles so they stay:

  • short
  • athlete-facing
  • concrete
  • specific enough to identify the session
  • free of vague internal-coach abstractions

The skill should likely include these hard rules from the start:

  • Author workouts only after the training intent is already decided.
  • Keep titles short, concrete, and athlete-facing.
  • Match ### Workout plan and ### Structured workout; they should describe the same session.
  • Put contingencies in ### Constraints or ### Notes, not in the title.
  • Prefer whole-minute step durations whenever possible once durations are longer than 90 seconds.
  • Avoid odd long structured-workout durations such as 105 sec, 150 sec, 168 sec, or 170 sec unless they are truly essential.
  • Do not add fake complexity to make a session look sophisticated.
  • Keep the output calendar-ready and TP-compatible, even though TP publication is out of scope.

Proposed file structure for the future skill

A likely initial structure:

create-workout/
├── SKILL.md
└── references/
    ├── workout-families-bike.md
    ├── workout-families-strength-and-movement.md
    ├── structured-workout-rules.md
    ├── title-and-description-rules.md
    └── progression-and-contingency-rules.md

This would keep the main skill lean while allowing depth where needed.

Why not include TP publication in this skill

Keeping TP publication out of scope is the right decision.

Reasons:

  • TP creation already belongs to another skill
  • mixing authoring with publishing will make the skill blur responsibilities
  • the authoring layer should be reusable even when no TP action is needed
  • clean separation makes failures easier to diagnose, authoring problem versus publishing problem

So the create-workout skill should output a workout object that is publication-ready, not publication-executing.

Risks if the skill is not added

If this skill is not added, the current distributed-state problem will likely continue:

  • more conventions will accumulate in memory instead of one workflow
  • formatting will keep being repaired after the fact
  • workout quality will depend too much on who remembers which rule
  • future expansion to new workout types will be messy
  • TP publication quality will still depend on inconsistent upstream authoring

Recommendation

Create the skill.

Specifically:

  • keep it tightly scoped to individual workout authoring only
  • make it calendar-first
  • keep TP publication out of scope
  • make it prescriptive, not vague
  • design it to support all workout families from the start
  • organize it so new workout families and authoring scenarios can be added later without bloating the main file

Proposed next step

The next step should be to define the future skill in one more layer of detail before building it:

  • exact skill name
  • trigger description
  • required input checklist
  • output contract
  • hard rules
  • reference-file breakdown

Once that is agreed, the skill can be created cleanly instead of evolving as another loose collection of rules.