The boring half of the ticket runs itself.

Ten triggers, nine actions

Triggers: issue created, issue assigned, issue status changed, task status, schedule, git push, PR merged, CI status, inbound webhook, and manual. PR and CI triggers work on GitHub and GitLab alike — not one with the other “coming soon”. Webhook tokens compare in constant time, and you can regenerate one the moment you suspect it leaked.

Actions — nine of them, from create-worktree and run-agent to open-pr, set-status, notify, HTTP and shell — carry retry backoff, and failures are classified transient or permanent so a flake retries and a real error stops instead of hammering.

Conditions match on labels, priority, status or any payload field, so “only P1 bugs on this repo” is a line of config, not a script.

Safety rails, not hope

An automation that can create branches and run agents needs brakes designed in, and they are:

• A priming gate, so a new flow doesn’t fire on the backlog it first sees
• A once-per-issue idempotency ledger — the same issue never triggers the same flow twice
• A loop guard, so flows can’t trigger each other forever
• A live kill switch per flow, propagated to the daemon, plus mid-run cancel
• Per-flow rate limits, and one master switch over everything

Runs where you aren’t

Flows run in-process while the app is open. Turn on keep-running and they run headless in the local daemon after you quit, alongside your agent sessions and PTYs — the 9pm schedule fires at 9pm whether or not the window is up.

The open-pr and run-command actions act on the project’s own host: on a remote-execution project they run on the remote machine while the app is connected. Headless flows — the daemon running with no app attached — refuse them for remote projects rather than touching the wrong machine, so those flows need the app running.