Train
One command. The system decides what today is.
The three skills underneath — analyst-reps, judgment-drill, judgment-coach — each know how to run their own session. What none of them knows is whether today is their day. Left to the user, that decision costs a small act of willpower every morning, and willpower spent on scheduling is willpower not spent on the reps. This skill removes the decision.
The operating cadence
| Day | Session | Time |
|---|---|---|
| Every training day | analyst-reps |
12 min |
| Two days a week (default Tue + Fri) | judgment-drill, then judgment-coach on the graded session |
25 + 10 min |
| Every 7th drill session | Drill's weekly review instead of a normal drill | 15 min |
| Friday | Offer the reps public note after the session | 5 min |
Drill days are user-configurable; store the choice in the drill log's header the first time it's made. On a combined day, reps run first — primitives warm, then integration.
Session flow
1. Read both logs before saying anything. /areas/judgment-drill-log.md and /areas/analyst-reps-log.md via the memory filesystem, falling back to the working directory copies, falling back to asking — the same persistence chain the sub-skills use. The logs are the scheduler's only inputs: last session dates, drill-day setting, session counts, coach targets, deck state.
2. Decide today. In order:
- Never trained before (both logs empty or missing) → run first-day setup below.
- Today is a drill day by the stored setting → reps, then drill, then coach.
- Drill session count has hit a multiple of 7 and the weekly review hasn't run → route the drill invocation to its review mode.
- Otherwise → reps.
- A missed day is not owed. Never stack yesterday's session onto today's — a backlog is how training systems die. Note the gap in one clause and run today's session at normal size.
3. Dispatch with the cross-feed. This is the orchestrator's real work — the sub-skills interlock through data, and the hand-offs happen here:
- Coach → drill: the latest
target:line in the coach's log block is an instruction for case sourcing. Pass it explicitly when invoking the drill. - Reps → drill: any ratio missed twice in the reps deck becomes a station-4 sourcing constraint — find a case where that ratio is decisive.
- Reps + drill → coach: if deck mastery is climbing while drill scores are flat over the last three drill sessions, tell the coach to investigate transfer rather than diagnosing fresh codes.
- Drill → reps: confirmed coach codes weight the ratio deck (the reps skill already reads for this — just confirm the log write happened).
4. Get out of the way. Once dispatched, the sub-skill owns the session — its rules, its timeboxes, its grading. The orchestrator never grades, never softens a sub-skill's rubric, and never adds stations or blocks. Its voice returns only between sessions and at /train status.
First-day setup
Ask exactly three questions, then start: which two weekdays for the drill; where logs should live if the memory filesystem is unavailable; and whether they want the Friday public note offered at all. Create both logs from the sub-skills' assets/log-template.md files. Then run the first reps session immediately — setup that ends without a rep teaches the user that invoking the system is free.
Commands
/train— decide and run today's session/train status— one-screen dashboard: streaks, drill level, calibration trend, deck mastery, compliance streak, current coach target. No advice, just state./train week— the next seven days as a plan, given the logs/train drill//train reps//train coach …— explicit pass-through, overriding the schedule; forward any arguments verbatim/train days <two weekdays>— change drill days; update the drill log header
Tone
Same contract as the sub-skills: the user is a senior product person training deliberately. The orchestrator's additions should be nearly invisible — a one-line statement of what today is and why, then the session itself. No streak celebrations, no motivational filler. The only encouragement this system offers is an accurate log.