Schedule recurring agent tasks with cron or built-in timers

This skill helps an agent choose the right scheduling approach for recurring, heartbeat, or looped work. The first decision it walks through is whether the agent has a built-in scheduler (Hermes, called "Camp B") or whether the agent owns the clock itself (everything else, "Camp A"). It sets a universal floor: cron only supports a 1-minute minimum with a standard 5-field expression (no seconds field), so anything running sub-minute needs a while ...; sleep N; done loop, a TS extension, or an event hook instead of a tight LLM timer.

For Camp A tools (one-shot agents that run once and exit, amnesiac unless resumed), it shows how to invoke Claude Code, Codex, and Pi from the command line and wrap them in an external clock - cron (1 minute or slower), a systemd timer on Linux, or a plain while-sleep loop. It calls out gotchas that break unattended runs: permission prompts hang forever unless flags like --allowedTools (Claude) or sandbox/auto-approve flags (Codex) are passed; output should be requested as JSON so a wrapper can parse it deterministically; and because each run is amnesiac, state must be resumed (codex exec resume --last) or persisted to a file the next run reads. Pi has no built-in scheduler by design - it always needs an external clock or a TS extension.

For cmux, the skill notes there is no built-in timer, watch, or cron. Looping it means either an orchestrator-driven send/sleep/read-screen cycle on your own clock, a dumb while-sleep wrapper, or the preferred event-driven approach via cmux notify plus OSC terminal hooks, which is cheaper and more responsive than polling. read-screen itself is non-interruptive and safe to poll.

For Camp B (Hermes), the skill documents a gateway that ticks every 60 seconds and runs due jobs in fresh, isolated sessions:

hermes cron create "every 1h" "summarize new emails and report" --skill himalaya

It flags Hermes-unique capabilities: zero-token mode (run a script and deliver its stdout verbatim, useful for watchdogs), job chaining via context_from, self-terminating loops, and a loop-safety rule that scheduled sessions cannot themselves create more cron jobs.

It also lays out a heartbeat pattern - one fast recurring tick that checks a task list against per-task last_run timestamps and only acts on what is due, staying silent when nothing is due - and a verification checklist to run before reporting success: confirm a Camp A wrapper's log grows after one interval (or run the command by hand for a clean JSON exit 0), confirm hermes cron list shows the job with a sane next_run and a run-now delivers, confirm permission/sandbox flags are present since a hung permission prompt is the most common silent failure, and confirm a nothing-due heartbeat tick stays silent.

Use it whenever a request involves recurring, scheduled, heartbeat, or looped agent work, or when deciding among cron, external schedulers, hooks, and built-in agent scheduling. It is a decision guide rather than a scheduler itself, so it adds nothing for a genuinely one-off task with no repetition. It is adapted from davidondrej/skills, and the source notes that local paths, tools, credentials, and agent features should be verified before acting - and that commands, remote access, scheduling, browser automation, or file-changing workflows need explicit user approval and target-environment confirmation first.

Input is a description of the desired recurring or scheduled behavior and which agent or runtime is in play. Output is a concrete scheduling setup - a cron line, a systemd timer, a while-sleep loop, a cmux notify plus OSC hook wiring, or a hermes cron create command - along with the verification step that confirms the schedule actually fires rather than silently hanging on a permission prompt.

Covers Claude Code, Codex, Pi, cmux, and Hermes as the scheduled or orchestrated agents, alongside cron, systemd timers, and shell while-sleep loops as the external clock mechanisms.

Anyone setting up unattended or recurring agent runs - background watchdogs, periodic reports, heartbeat checks, or chained multi-step automations - across any of the covered agent runtimes.