# Work that starts itself

Turn a prompt into a Project automation that runs on a GitHub event, a Linear issue, a schedule or a webhook, and read what each run did.

Some work has an obvious moment to start: a pull request opens, a check fails, an issue moves to
**In progress**, Monday morning comes round. An **automation** is a prompt saved in a Project with
the triggers that start it. In this lesson you create one in the console, choose when it fires,
learn which events it ignores, and read its run history.

_Figure: triggers, on the page at /docs/learn/work-that-starts-itself._
## Write the prompt

### 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:

```text
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.

## Choose when it runs

### 3. Add a trigger

The **Runs when** row offers four kinds:

| Trigger | What starts a run |
| --- | --- |
| **+ GitHub event** | An event on the Project's repository, such as **Pull request opened**, **Check suite failed** or **@rush in an issue or PR comment** |
| **+ Linear issue** | **Issue moved into a state** or **Issue labeled** in Linear |
| **+ Schedule** | A time, such as every day at 09:00 on weekdays |
| **+ Webhook** | A `POST` from your own system |

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:

```bash
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.

## Tune it in the editor

### 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.

## What fires and what never does

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.

## Read its run history

### 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.

## Next

[Automations](/docs/concepts/automations) covers triggers and wakes in depth, and
[Steer a run as a team](/docs/learn/steer-a-run-as-a-team) shows how teammates follow a run once it
starts.