cron-scheduler

Cron Scheduler

Convention: See skills/conventions/test-before-bulk.md — test every cron job on 3-5 items first.

Contract

This skill guarantees:

• Schedule staggering: max 1 job per 5-minute slot, no collisions
• Quiet hours gating: timezone-aware, with user-awake override
• Thin job prompts: jobs say "Read skills/X/SKILL.md and run it" (no inline 3000-word prompts)
• Idempotency: jobs can run twice without duplicate side effects
• Results saved as reports: reports/{job-name}/{YYYY-MM-DD-HHMM}.md

Phases

1. Define job. Name, schedule (cron expression), skill to run, timeout.
2. Validate schedule. Check no collision with existing jobs (5-minute offset rule).
   • Slots: :05, :10, :15, :20, :25, :30, :35, :40, :45, :50
   • If collision detected, suggest the next available slot
3. Check quiet hours. Default: 11 PM - 8 AM local time.
   • Override: user-awake flag (if user is active, quiet hours suspended)
   • During quiet hours: save output to held queue
   • Morning contact releases the backlog
4. Register with host scheduler. OpenClaw cron, Railway cron, crontab, or process manager. Each registered entry should execute via Minions, not agentTurn. See skills/conventions/cron-via-minions.md for the rewrite pattern (PGLite uses --follow, Postgres uses fire-and-forget + --idempotency-key on the cycle slot). GBrain's v0.11.0 migration auto-rewrites entries for built-in handlers; host-specific handlers need a code-level registration per docs/guides/plugin-handlers.md.
5. Write thin prompt. Job prompt is one line: "Read skills/{name}/SKILL.md and run it."

Idempotency Requirement

Every cron job MUST be idempotent:

• Running the same job twice produces the same result (no duplicate pages, no duplicate timeline entries)
• Use checkpoint state files to track progress and resume interrupted runs
• Check for existing output before creating new output

Output Format

Job configuration saved. Report: "Job '{name}' scheduled at {cron expression}. Next run: {time}."