wick-schedules

Schedules

wick_schedule_message puts something on the clock. There are two types, and picking the right one is most of the skill.

Never poll a status with type=message every=30s. Every fire of a message schedule is a full LLM turn just to say "not yet". A watch does the checking in wick (no LLM, no DB write while pending) and wakes you exactly once.

A watch is deliberately simple: fetch → test → notify once. Branching, loops, retries with backoff, several notifications or multi-system orchestration belong in a wick workflow (skill wick-workflows), not in a watch.

Common fields (both types)

• Target — one of:
  • session_id (omit it = THIS conversation): every fire lands in that session with its history.
  • project_id: a project job; session_mode=new (default) opens a fresh session per fire, session_mode=template + session_template (daily-{date}, {datetime}, {ym}, {run}, {id}) reuses one.
• Timing — one of: run_at (one-shot: RFC3339 or +30s / +20m / +2h / +1d), every (30s, 5m, 1h30m, 1d), cron (5 fields, matched in the SERVER's timezone — the response names it).
• max_runs caps a recurring schedule; ends_at stops it at a time.
• message (≤ 8000 chars): for a message schedule, the turn delivered on every fire; for a watch, the text of the ONE notification (write it to your future self: what to do once the condition is met).
• Actions: create, list (live by default; status=all for history), pause / resume (no shift of the next slot), reschedule (timing, message, target, and for a watch steps), cancel id=sm_… (stops it, keeps the row and history), delete id=sm_… (removes it AND its run history — owner/admin), run_now id=sm_… (an extra fire to test it — does not count toward max_runs, does not shift the cadence). Watch only: update (= reschedule, replaces steps), test (dry run), runs / run (history) — see below.