Work that starts itself

1. Open the Project

Open the Project from Projects. Its page lists Automations above its runs, and the chips All, Automations and Runs filter the list.

2. Turn the composer into an automation

Write the prompt in the composer at the bottom of the page, as you would for a run:

Review this pull request for correctness and security. Comment on each problem with the
file, the line and a fix. Approve only when you find none.

Then press the clock button (Automate). A Runs when row appears under the prompt.

3. Add a trigger

The Runs when row offers four kinds:

GitHub triggers take filters: Only with labels, Only from authors and Only into branches (for example main, release/*). Leave a filter empty to match everything. A schedule takes a preset, or Custom… with a cron expression and a time zone, and previews its next three times. A Linear trigger needs Linear connected under Settings → Integrations first.

Press Create automation. The console opens its editor with the name filled in from the prompt's first line.

4. Copy a webhook secret now

For a webhook trigger, Rush shows the URL and its secret once, after you save. Copy both. Your system starts a run with the secret as its bearer token, and the body reaches the agent as the event:

curl -X POST "$AUTOMATION_WEBHOOK_URL" \
  -H "Authorization: Bearer $AUTOMATION_SECRET" \
  -H "Idempotency-Key: deploy-4812" \
  -d '{"service": "checkout", "alert": "p95 latency over 2s"}'

The Idempotency-Key header stops a retry from starting a second run.

5. Set the agent and the limits

The editor has the name, the prompt and a sidebar:

• Agent: a Saved agent, or Project's default agent; Read-only (no pushes); and Each run as New run or Wake a session, which continues a session you pick, as it is, instead of starting a fresh one.
• Triggers: each with Last fired or Never fired, and + Add for another.
• State: On: triggers fire or Off: triggers are ignored.

Each run gets the event that fired it below your prompt, marked as untrusted, so the agent treats an issue body or a comment as data, not instructions. Run now starts one by hand to test it.

An automation runs as the person who created it, with that person's accounts, in the Project's repository with its apps and secrets. Only its creator or an org admin can edit it; an admin who saves a change becomes its runner.

An automation starts work from events other people cause, so it ignores the ones that would let the wrong person, or a loop, start a run:

• Bots never fire it, including Rush's own GitHub App, so an agent's comment cannot start another agent.
• Only people with write access count. Mentions, pull requests and issues fire only from people with write access to the repository.
• Forks never fire it. A pull request or a CI run from a fork is ignored.
• Merged, not closed. Pull request merged fires on a merge; a pull request closed without merging fires nothing.
• Agents in Linear never fire it. Linear changes made by an app or a coding agent are ignored, and removing a label never fires.

A matching event is also skipped when the automation is off, the Project is paused, its creator has left the org, the same delivery arrived twice, or the hourly limit is reached. Each automation starts at most 30 runs an hour across all its triggers, and a schedule that starts new runs fires at most once an hour.

6. Check Recent runs

Recent runs in the editor lists each run with what started it (the trigger kind, or Run now), its status and its age. Open one and it is an ordinary run page: the transcript, the changes, the pull request or the answer. Every run an automation starts also appears in the Project's Runs, so your team sees it beside the runs people started.

Automations covers triggers and wakes in depth, and Steer a run as a team shows how teammates follow a run once it starts.