Automations

Any kanban card can be toggled into automation mode. The card's description becomes the prompt, and the automation config adds a schedule, a provider, and delivery options. The automation system is a session starter: it injects the prompt and confirms activity, nothing more. What happens next is up to the agent and whatever the prompt asks for.

Every run's prompt opens with a structured run header: the current time with timezone, the card title and id, the trigger (scheduled or manual), and when the automation last ran. The agent always knows it is inside an automation run and what fired it.

Automations are a good fit for recurring, unattended work:

• Morning standups: summarize board state and open problems before you sit down.
• Nightly context refreshes: keep project reference docs in sync with the code while you sleep.
• Documentation updates: a recurring pass that catches drift between docs and reality.
• Recurring audits: dependency checks, test runs, or any inspection you want on a schedule.

A schedule is either a cron expression for recurring runs or an ISO datetime for a one-shot. One-shots auto-disable after firing, with the config preserved, so you can re-enable the same automation later with a new date.

The scheduler checks every 30 seconds and fires at most one automation per tick, so a backlog or restart can never double-fire. Next-run times are computed server-side and shown on the board. The timezone comes from the TZ value in the workspace .env (any IANA timezone, falling back to UTC), and all schedules evaluate and display in that timezone.

Brand-new automations get a 24-hour first-fire backstop: a schedule created after today's slot has already passed still runs promptly instead of waiting a full cycle.

Prompt delivery is verified end to end, not paste-and-hope. Fresh sessions receive the prompt at launch. Live sessions go through paste, confirm queued, Enter, then verify the input cleared, with an Enter-only resend. Duplicate fires and silent non-submits are structurally prevented. A session blocked by a CLI dialog (update, trust, or auth prompt) is detected and treated as a hard failure rather than blindly accepted.

Failures are loud. Any hard failure records an error result on the card, sends a notification through your messaging channel (Telegram, for example) with the session name and log path, and never leaves a prompt silently queued. Every kickoff also appends a structured entry to a size-capped diagnostic log under the SlyCode home directory.

You do not have to wait for the schedule. The Automations screen and each automation card have a Run Now button, and sly-kanban automation <id> run triggers the same run from the CLI and prints the delivery outcome. Manual runs are marked as such in the run header the agent sees.

The dashboard has a dedicated Automations view: every automation card laid out with its schedule, last result, an enabled or disabled badge, and a live countdown to the next run. Cards group by their first tag, and the header shows the active timezone.

Schedules are edited with a cron builder that covers hourly, daily, weekly, monthly, interval (including overnight wrap-around), and one-shot frequencies. It is bidirectional: switch between the friendly form and raw cron at any time.

• Messaging and voice: set up the channel that automation reports and failure alerts arrive on.
• Kanban workflow: the cards, stages, and actions that automations are built on.