All guides

12 min read

React to GitHub events

Start an agent the moment a pull request opens, a build goes red, or a tag lands — filtered down to exactly the events you want it on.

  1. 01

    Connect GitHub and choose the repositories

    Authorize GitHub from Settings → Integrations and select which repositories the connection covers. That selection is the ceiling on everything an agent can reach, so start with one repository while you build confidence.

  2. 02

    Pick the event that matches the task

    A reviewer runs on `pull_request.opened` and `pull_request.synchronize`. A build explainer runs on `workflow_run.completed`. A release notes writer runs on `tag.created`. An issue triager runs on `issues.opened`. Choose the event where the work actually begins.

  3. 03

    Filter the trigger down

    Field filters keep the agent off the pull requests you did not mean. Filter by base branch so it ignores work on long-lived feature branches, or by label so a PR opts in one at a time — `agent-review` on the pull requests you want, and nothing else fires.

  4. 04

    Write the prompt against the event payload

    The agent receives the event that started it, so the prompt can refer to the pull request, the workflow run, or the tag directly. Tell it what to read first: the diff, the contributing guide, the last twenty merged reviews.

  5. 05

    Start with a label filter and a comment

    Have the agent post a comment rather than an approving review, and gate it behind a label. Add the label to a handful of your own pull requests, read what it wrote, then widen the filter once the reviews are worth reading.

  6. 06

    Decide who can change it

    A workflow that comments on pull requests is a workflow your team will read closely. Org roles decide who may edit it — admins and editors change the prompt, users run it — and resource visibility keeps it scoped to the team that owns it.

Try it in your workspace.

Start free, connect a tool, and describe the first task in plain English.