Season and block plan

Asking an assistant to “make me a training plan” in one shot produces a generic plan and often overruns the context window. This recipe splits the job into three stages — assess, design, schedule — so each step is grounded in your real data and you approve the plan before anything touches your calendar.

When to use this

• When you have a goal event and a runway of 8+ weeks.
• At the start of a season, to lay out base/build/peak/taper blocks.
• After a goal event, to plan the next macrocycle.

Do not use this workflow for a quick health check of an already-written plan. For that, use the plan_health_review MCP prompt or the prompt-library copy-paste prompt: it audits planned-vs-completed adherence, load/form trajectory, deload/recovery-week caveats, missing wellness/readiness data, and race-date risk without designing a new season. For a strictly read-only, evidence-limited audit that keeps athlete-stated availability/duration separate from observations and never derives an age rule, use Masters plan review.

The recipe

Send the stages as separate messages. Wait for each before sending the next.

Stage 1 — assess

Stage 1 of planning my season. Use icuvisor with my intervals.icu data.
Read my athlete profile, my fitness trend (CTL / ATL / TSB) for the last
8 weeks, my training-load summary for that period, and my upcoming events.
If I train multiple endurance sports, call get_fitness with
include_per_sport_load_trends:true and summarize run, bike, swim, and other
load trends separately, including any caveats. Summarize my current combined
fitness/form, my recent weekly load range, and how much training history you can
actually see. Do not propose a plan yet.

Stage 2 — design

Stage 2. My goal is [GOAL EVENT] on [DATE]. It demands [e.g. 3-hour road
race, hilly]. Design a periodized plan from now to race day:
- Name each block (base, build, peak, taper), its length, and its purpose.
- Give a weekly training-load target and ramp rate per block.
- Place recovery weeks (every 3rd or 4th week).
- State a target CTL for race day.
Use get_fitness_projection to check the CTL path is realistic given my
current fitness and the ramp you chose. Present the plan as a week-by-week
table. Do not write anything to my calendar yet. If wellness/readiness data is
missing, do not use it as evidence for or against the plan.

Stage 3 — schedule

Stage 3. The plan looks good. Add it to my calendar one week at a time:
create the block markers and the key sessions as events, show me each week
before moving to the next, and stop if I say so. If I ask for gym or strength
work, schedule only a simple gym time block or free-text note unless my
intervals.icu account exposes a supported workout type; do not invent detailed
sets/reps/loads as structured workout steps. For the first structured endurance
workout, validate the payload, write one event, read it back, and confirm no
unexpected warnings or lost structured steps before writing the rest.

What icuvisor does

A good answer looks like

Stage 2 should produce something like:

Plan: 12 weeks to [GOAL EVENT]. Current CTL 58; race-day target CTL ~72.

Block	Weeks	Focus	Weekly load	Ramp
Base 2	1-3	Aerobic volume, tempo	480 → 520	+6%/wk
Recovery	4	Absorb	300	-40%
Build 1	5-7	Threshold	540 → 590	+5%/wk
Recovery	8	Absorb	340	-40%
Build 2	9-11	VO2 + race-specific	560 → 600	+4%/wk
Taper	12	Sharpen	320 → race	-45%

get_fitness_projection confirms this lands CTL at 71 and TSB at +12 on race morning — within target. Pushing the Build ramps above 6%/wk would overshoot ATL and leave TSB negative on race day.

Variations

• No calendar writes: stop after Stage 2 and apply the plan in intervals.icu yourself. Useful when the server runs read-only.
• Existing annual plan or deterministic proposal: use get_annual_training_plan to summarize explicit calendar phases and TARGET loads without treating personal notes as plan instructions. For a new read-only season proposal, use propose_annual_training_plan. Its optional taper_weeks (1–3, default 1) and taper_target_load_pct (1–100%, default 60%) model final contiguous-week load scenarios; for example, taper_weeks: 2 and taper_target_load_pct: 50 produces two final taper rows at half the target weekly load. The response reports requested/resolved values and default/input assumptions, and clamps duration to a shorter horizon. Feed its projection bridge into get_fitness_projection instead of asking the assistant to reconstruct weekly load in chat. This is a deterministic load scenario, not a prescription or an intensity/suitability claim. If you decide to write the proposal’s phase notes, first inspect the dry-run from apply_annual_training_plan; an explicit commit with its returned preview token is required before any write.
• Apply a library plan: if a structured plan already exists, ask the assistant to use apply_training_plan instead of authoring one. Dry-run previews include deterministic icuvisor-plan-v1-... external_id values for the proposed events; when you apply the same plan/start/date tuple again, those IDs make retries safer and protect matching existing plan events during replacement. They are still best-effort upstream idempotency aids scoped to icuvisor’s same-day checks, not a promise that every cross-day or upstream race condition is deduped.
• Gym or strength blocks: ask for a NOTE such as “Gym — 45 min strength and mobility” or a simple supported calendar workout type if your account has one; detailed exercises, sets, reps, and loads are future scope until intervals.icu exposes a documented strength-training API.
• Triathlon or multisport season: in Stage 1, ask for get_fitness with include_per_sport_load_trends:true so the assistant can separate run, bike, swim, and other load trends. Treat those per-sport CTL/ATL/TSB-style values as computed context from visible category load, not upstream-native form. Use the combined CTL/ATL/TSB from get_fitness for global freshness and race-day form, then use per-sport trends to decide which discipline needs more base, maintenance, or recovery. For a read-only explicit allocation scenario, provide sport_allocations to propose_annual_training_plan, for example [{"sport":"Ride","load_share_pct":50,"weekly_session_count":4},{"sport":"Run","load_share_pct":30,"weekly_session_count":3},{"sport":"Swim","load_share_pct":20,"weekly_session_count":2}]. The response returns caller-supplied sport_targets for each weekly parent load/hour row, with deterministic rounding reconciliation; it does not infer availability, discipline priority, intensity, training days, physiological suitability, or workouts, and it does not schedule anything. Use the aggregate projection bridge for get_fitness_projection; do not treat sport targets as a calendar or workout schedule.
• Re-plan mid-season: “I missed two weeks to illness — re-assess and adjust the remaining blocks.”
• Audit without re-planning: use plan_health_review to check whether the current calendar still makes sense. Deload or recovery weeks should be treated as intentional load reductions unless adherence, wellness, or form evidence says otherwise; a race date supplied by the user is only a scenario anchor if no matching race event is found.

Why this prompt works

• Three stages, three messages. Keeps each tool burst small and gives you a checkpoint before any write — the opposite of a single mega-prompt that gets interrupted.
• get_fitness_projection as a reality check. The assistant proposes a ramp; the tool tests whether the CTL path is actually reachable, so the plan is not just plausible prose.
• Schedule last, week by week. Calendar writes are gated and hard to undo in bulk. Incremental scheduling keeps you in control, and the first write/readback catches cases where a description update would replace structured workout steps if the desired workout_doc was omitted. For plan-health reviews, stop at a reviewed proposal: no calendar write should happen until the exact change has been shown and approved.