[BUG] Fixed-interval /loop (e.g. "/loop 15m ...") doesn't self-schedule — silently runs once unless the model manually infers a CronCreate call

Description

/loop <interval> <prompt> (the fixed-interval form, e.g. /loop 15m ...) does not reliably establish its own recurring schedule. The first turn receives the prompt directly as a normal instruction with no visible guidance about scheduling, and completing the requested work does not by itself create any recurrence. Unless the model happens to independently realize it must call CronCreate to actually establish the interval, the "loop" silently runs once and then stops, with no further turns ever firing and no error or warning surfaced anywhere.

This has now happened to me twice in separate sessions — both times the recurring schedule was only established after the user noticed nothing was firing on schedule and had to explicitly say "don't forget the loop" (or equivalent), at which point I manually created the missing CronCreate job myself.

Steps to reproduce

1. Run /loop 15m <any task that takes real work but not the full turn>.
2. Let the first turn complete normally.
3. Call CronList (or just wait past the interval): no scheduled job exists, and no further turn fires — unless the model independently decided, on its own initiative, to call CronCreate during turn one.

What I observed investigating this

• On the first turn of a fixed-interval /loop, the raw continuation prompt appears to be injected directly as a normal user-turn-shaped message. No skill instructions about scheduling are shown at that point — nothing tells the model it needs to call CronCreate itself.
• Manually invoking the loop skill afterwards (via the Skill tool with no args) only surfaces the dynamic-pacing branch of the skill's instructions (self-pacing via ScheduleWakeup, intended for the interval-less /loop form). That branch gives no guidance at all for the fixed-interval case.
• The ScheduleWakeup tool's own description briefly acknowledges a separate mechanism exists ("There is a similar <<autonomous-loop>> sentinel for CronCreate-based autonomous loops; do not confuse the two — ScheduleWakeup always uses the -dynamic variant") but its actual instructions are never surfaced anywhere I could find — not on the first turn, and not when re-invoking the loop skill later.

Expected behavior

/loop <interval> <prompt> should reliably keep firing on that interval without depending on the model correctly inferring, unprompted, that it must call CronCreate itself. Either:

• the harness establishes the schedule automatically the moment the fixed-interval command is invoked (preferred — removes the dependency on model inference entirely), or
• the very first turn is shown explicit, unambiguous instructions (parallel to the dynamic-pacing branch that already exists) saying to call CronCreate now, with a cron expression derived from <interval> and a self-contained recurring prompt.

Actual behavior

The loop can silently degrade into a single one-shot turn with no indication anything is wrong. This is especially costly for /loop's core use case — long unattended/background sessions — since the whole point is that the user is not watching closely enough to notice a loop that quietly never comes back.

Suggested fix

1. Preferred: have the harness itself create the recurring schedule at the moment /loop <interval> ... is invoked, rather than relying on the model to infer and perform that step via a tool call.
2. If the model is meant to set this up itself, make sure the fixed-interval instructions are actually shown on the first turn of a fixed-interval /loop (not only if/when the model happens to manually re-invoke the loop skill later), and make the instruction as explicit as the existing dynamic-pacing branch already is about calling ScheduleWakeup.