Run visual scheduled agent jobs with Cronicle
Use Cronicle to schedule, run, monitor, and manually trigger recurring agent maintenance jobs across one or more worker servers from a web UI and REST API.
npx skills add agentskillexchange/skills --skill run-visual-scheduled-agent-jobs-with-cronicle
Use Cronicle when an operator needs scheduled, repeatable agent-adjacent jobs with a visible run history, worker targeting, retries, live logs, API-triggered runs, webhooks, and multi-server failover. Invoke it instead of local cron or ad hoc shell scripts when agent maintenance tasks, ingestion refreshes, evaluation sweeps, cleanup jobs, or report generators need supervised scheduling across machines. The workflow starts by installing Cronicle on a primary host, adding worker servers, creating categories and plugins or shell-command events, assigning targets, and setting timing, timeout, retry, notification, and webhook rules. Operators can then trigger jobs through the web UI or REST API, inspect active runs, follow logs, review history, and adjust schedules without giving an agent uncontrolled shell access. The scope boundary is scheduled agent operations in Cronicle: create events, run them, observe them, and keep failures reviewable. It is not a general survey of every Cronicle capability.
What this skill actually does
Inputs and prerequisites: Cronicle server, Node.js and npm, POSIX host or worker servers, shell commands or Cronicle plugins, optional REST API keys and webhooks.
Setup notes: Install Node.js and npm, then run curl -s https://raw.githubusercontent.com/jhuckaby/Cronicle/master/bin/install.js | node as root. Start Cronicle with /opt/cronicle/bin/control.sh start, open the web UI, configure workers, API keys, plugins, and scheduled events for repeatable agent operations.
Source and verification boundary: use http://cronicle.net as the canonical reference before running the workflow; keep commands, API calls, CLI usage, and generated outputs reviewable against that upstream source.
Framework fit: publish this as a Multi-Framework workflow only when the operator can invoke the documented toolchain directly, rather than treating the upstream project as a generic product listing.