Notification-Driven Self-Paced Dispatch (the /loop Pattern)

In one line: Resume authorized work from current state using the host's actual event, wait or scheduling capabilities.

This pattern coordinates work over time. It does not ship a scheduler, authorize recurring work, or guarantee that a message resumes an inactive controller. Verify the host's capabilities, update/cancel behavior and run identifiers before promising unattended progress. Where the host requires a recurring automation, use that mechanism within the user's request.

Three load-bearing rules:

1. Use verified wake mechanisms. Prefer a supported specific event/wait; use an appropriate authorized schedule where necessary. A notification and actual execution resumption are different observations. Avoid duplicate watchers; record and reconcile pending primary/fallback events.
2. Choose cadence by the task. Acceptable latency, current state, reliability, resource use and user notification preferences determine cadence. Cache configuration and pricing vary; no universal five-minute cache assumption or “never 300 seconds” rule applies.
3. Resume from current authority and state. The prompt points to the exact project/run, maintained plan, scope and stop conditions. It is not a fresh grant. Check revocation, expiry, completion, supersession, consumed events, existing workers and dependencies before any effect.

Memory and optional STATE.md snapshots aid orientation; they do not own the mandate, work queue or actual deployed state. The host may preserve or summarize conversation context. A self-contained prompt should remain understandable without assuming either complete retention or total context loss.

Duplicate and stale events. Completing a task or omitting a new schedule call does not cancel an existing timer. Update/cancel supported schedules and verify the resulting state. Stale events must recheck the current run and produce no new effect. An adopting controller needs a durable atomic claim when duplicate or concurrent events are possible; the kit's schema pack does not implement that behavior.

Stopping. User stop, revoked/expired authority, completed work, exhausted approved budget or a required checkpoint stops new actions. Cancel scoped workers and pending schedules where supported; preserve recovery evidence and report incomplete work. An uncancelled child process must not be presumed harmless.

Evidence: exercise the actual host/controller for event delivery, resumed execution, duplicate fallback, revocation, lost notifications, unknown job status and stale writers. Record which path was demonstrated. Unchanged external state is normal during monitoring; notify according to the user's preference rather than manufacture progress.

Detailed operational procedure: skill:s4u-loop-dispatch.