asgeirtj/system_prompts_leaks/loop

/loop — schedule a recurring or self-paced prompt

Parse the input below into [interval] <prompt…> and schedule it.

Parsing (in priority order)

1. Leading token: if the first whitespace-delimited token matches ^\d+[smhd]$ (e.g. 5m, 2h), that's the interval; the rest is the prompt.
2. Trailing "every" clause: otherwise, if the input ends with every <N><unit> or every <N> <unit-word> (e.g. every 20m, every 5 minutes, every 2 hours), extract that as the interval and strip it from the prompt. Only match when what follows "every" is a time expression — check every PR has no interval.
3. No interval: otherwise, the entire input is the prompt and you'll self-pace dynamically (see "Dynamic mode" below).

If the resulting prompt is empty, show usage /loop [interval] <prompt> and stop.

Examples:

• 5m /babysit-prs → interval 5m, prompt /babysit-prs (rule 1)
• check the deploy every 20m → interval 20m, prompt check the deploy (rule 2)
• run tests every 5 minutes → interval 5m, prompt run tests (rule 2)
• check the deploy → no interval → dynamic mode, prompt check the deploy (rule 3)
• check every PR → no interval → dynamic mode, prompt check every PR (rule 3 — "every" not followed by time)
• 5m → empty prompt → show usage

Offer cloud first

Before any scheduling step, check whether EITHER is true:

• the parsed interval (rule 1 or 2) is ≥60 minutes, or
• regardless of which rule matched, the original input uses daily phrasing ("every morning", "daily", "every day", "each night", "every weekday")

If either is true, call AskUserQuestion first:

• question: "This loop stops when you close this session. Set it up as a cloud schedule instead so it keeps running?"
• header: "Schedule"
• options: [{label: "Cloud schedule (recommended)", description: "Runs in Anthropic's cloud even after you close this session"}, {label: "This session only", description: "Runs in this terminal until you exit"}]

If they pick Cloud schedule: do NOT call CronCreate. Invoke the schedule skill directly via the Skill tool with args set to their original input verbatim (e.g. Skill({skill: "schedule", args: "every morning tell me a joke"})), then follow that skill's instructions to completion. Do NOT tell the user to run /schedule themselves. Then stop — do not continue to any section below (no CronCreate, no ScheduleWakeup, no "execute the prompt now"). If they pick This session only:

• If the trigger was a parsed ≥60-minute interval (rule 1 or 2): continue below with that interval.
• If the trigger was daily phrasing only (rule 3, no parsed interval): do NOT call CronCreate. Explain that a daily-cadence loop won't fire before this session closes, so there's nothing useful to schedule locally — suggest they either pick Cloud schedule, or re-run /loop with an explicit shorter interval (e.g. /loop 1h <prompt>) if they want a session loop. Then stop.

If neither trigger condition was met: continue below.

Fixed-interval mode (rules 1 and 2)

Convert the interval to a cron expression:

If the interval doesn't cleanly divide its unit (e.g. 7m → */7 * * * * gives uneven gaps at :56→:00; 90m → 1.5h which cron can't express), pick the nearest clean interval and tell the user what you rounded to before scheduling.

Then:

1. Call CronCreate with: cron (the expression above), prompt (the parsed prompt verbatim), recurring: true.
2. Briefly confirm: what's scheduled, the cron expression, the human-readable cadence, that recurring tasks auto-expire after 7 days, and that the user can cancel sooner with CronDelete (include the job ID). Only if you did NOT show the cloud-offer AskUserQuestion above (i.e., neither trigger condition applied), end the confirmation with this exact line on its own, italicized: _Runs until you close this session · For durable cloud-based loops, use /schedule_. If the user already answered that question, omit this line.
3. Then immediately execute the parsed prompt now — don't wait for the first cron fire. If it's a slash command, invoke it via the Skill tool; otherwise act on it directly.

Dynamic mode (rule 3 — no interval)

The user wants you to self-pace. Decide what makes the next iteration worth running — a passage of time, or an observable event.

1. Run the parsed prompt now. If it's a slash command, invoke it via the Skill tool; otherwise act on it directly.
2. If the next run is gated on an event (CI finishing, a log line matching, a file changing, a PR comment) and no Monitor is already running for it: arm one now with timeout_ms: 600000. Its events arrive as <task-notification> messages and wake this loop immediately — you do not wait for the ScheduleWakeup deadline. A monitor expires after at most 10 minutes and tells you; on later iterations call TaskList first and re-arm only if no monitor for it is still running.
3. Decide whether the loop continues. If the task needs another iteration, call ScheduleWakeup with:

• delaySeconds: with a Monitor armed this is the fallback heartbeat — how long to wait if no event fires (lean 1200–1800s; idle ticks more frequent than the task needs are pure overhead). Without a Monitor this is the cadence — pick based on what you observed. Read the tool's own description for cache-aware delay guidance.
• reason: one short sentence on why you picked that delay.
• prompt: the full original /loop input verbatim, prefixed with /loop so the next firing re-enters this skill and continues the loop. For example, if the user typed /loop check the deploy, pass /loop check the deploy as the prompt.
• noop: true if this tick changed nothing ("still waiting", "quiet hold"); false if it did something worth keeping. Consecutive noop: true ticks collapse in the terminal.

If it doesn't need another iteration, stop instead (step 6) — re-arming is a per-turn choice, not a default.

1. After the wakeup is armed, briefly confirm: that you're self-pacing, whether a Monitor is the primary wake signal, that you ran the task now, and what fallback delay you picked. This must be ordinary visible response text — the user cannot see your thinking/reasoning, so an update written only there is invisible to them. Make it the last thing in the turn, then end the turn.
2. If you were woken by a `<task-notification>` rather than this prompt: handle the event in the context of the loop task, then make the same decision. If the loop should continue, call ScheduleWakeup again with the same prompt and the same 1200–1800s delaySeconds from the schedule step above (the Monitor remains the wake signal; the new wakeup is only the fallback heartbeat), then write the same brief update as visible text. If the event means the work is finished, stop (step 6).
3. To stop the loop — the task is complete, further iterations can't make progress, or the user asked you to stop — call ScheduleWakeup with stop: true (no other fields) and TaskStop any Monitor you armed (use TaskList to find the task ID if it is no longer in context). Then write the loop's outcome for the user as ordinary visible response text — a stopped loop has no next tick to surface it. Stopping is the loop's normal ending — the user can restart it anytime with /loop. Before you stop, send a one-line outcome via PushNotification — the user may be away and waiting to hear it's done. Skip this if you're stopping because the user just told you to; they're already here.

Input

$ARGUMENTS