Automation reference

Tallpine routes CI failures, review feedback, and merge conflicts with built-in rules. Project settings do not accept the retired reactions: configuration. See Migration before reusing an old YAML example.

For a step-by-step pull-request workflow, see Handle CI and review feedback.

What Tallpine handles

Messages are signature-deduplicated, so an unchanged set of failures or comments is not sent on every poll. A changed failure set or changed unresolved feedback can produce a fresh nudge.

Recurring Automations are separate from these event rules. In the sidebar, create an automation with a project, prompt, agent, role, time zone, and schedule. You can inspect its run history, edit it, pause or resume it, and delete it. The CLI supports the same saved definitions:

tallpine automation create --project my-app --name "Daily checks" \
  --prompt "Run the project checks and summarize failures" \
  --cron "0 9 * * *" --timezone UTC
tallpine automation list --project my-app
tallpine automation runs <automation-id>
tallpine automation update <automation-id> --enabled=false

Choose one schedule format: a five-field cron expression or an RRULE, a calendar recurrence rule. Set the time zone with an IANA name, such as America/New_York.

Cron accepts numeric minute and hour fields, * for day and month, and supported weekday choices. It does not accept arbitrary ranges or steps. RRULE does not accept COUNT or UNTIL, or intervals faster than one minute.

Automations run in the local daemon, so the computer must be awake and Tallpine must be running. After a restart, Tallpine runs at most three missed occurrences. The same automation will not start another run while its current run is active. Deleting an automation also deletes its run history.

To try an automation, create one in Automations with a short prompt and a schedule a few minutes ahead. Then open its run history and linked session. If it does not run, check the time zone, confirm the automation is enabled, and make sure Tallpine stayed open and the computer stayed awake. Pause the automation before changing a schedule you are testing.

Project Cues save reusable instructions or exact shell commands for manual use. They do not run on a schedule. An agent Cue sends a prompt to an eligible session or starts a worker. A command Cue opens a fresh local terminal. Manage Cues in the project dialog and choose Run a cue from a session.

For example, create an agent Cue named Check tests with the prompt Run the focused tests and report failures, then choose Run a cue in a project session. If the session cannot accept a prompt, start a worker from the offered option or wait until the session can accept one.

A command Cue such as npm test runs that exact command in a new local shell. An agent does not review or interpret it, so check the command and working directory before running it.

Mode-aware delivery

Lifecycle messages go through the same session manager as user messages:

• Terminal UI sessions receive the message through their runtime.
• Chat sessions receive a native provider turn and persist it in the structured conversation.

Tallpine does not run both controllers at once. A handoff between compatible interfaces drains or interrupts the old controller before committing the new one.

Notifications

The desktop notification center keeps alerts for input requests, pull requests ready to merge, merged pull requests, and pull requests closed without merging. Desktop toasts appear while Tallpine is running. Marking an alert read keeps it in history; clearing one or all removes it from the center.

Paired phones can receive push notifications when notifications are allowed on the phone and the daemon can connect to the push service.

Tallpine does not currently configure Slack, Discord, webhook notifiers, per-reaction retry budgets, or automatic merge from project config. Merge explicitly from the desktop or with:

tallpine pr merge <pr-number>

Reviews

Repository observation and Tallpine reviewer agents are related but separate:

• The GitHub/GitLab observer watches a claimed pull request or merge request and records CI, review, and merge data.
• A Tallpine review run starts a configured reviewer against a worker's pull request. Use Reviews in the desktop app or tallpine review trigger, tallpine review ls, and tallpine review cancel.

autoReview is a project default copied to new worker sessions. Each session also has its own toggle. Automatic review waits for an eligible pull-request revision and an idle worker. It does not merge the pull request or publish every workspace inspection as a review. See the agent catalog for reviewer support.