← All guides

12 min

React to GitHub events

Start a run the moment a pull request opens, a build finishes, or a tag lands. Filter down to exactly the events you want.

5,000 free credits to start.

  1. 01

    Connect GitHub and choose the repositories

    Connect GitHub from Settings, then Integrations, and select which repositories the connection covers. That selection is the limit of what a workflow can reach. Start with one repository.

  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`. GitHub exposes twelve events.

  3. 03

    Filter the trigger down

    Filters combine with AND or OR and accept globs. Filter by base branch so the workflow ignores long-lived feature branches. Filter by label so a pull request opts in one at a time.

  4. 04

    Write the prompt against the event payload

    The run 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 instead of an approving review, and gate it behind a label. Add the label to a few of your own pull requests, read what it wrote, then widen the filter.

  6. 06

    Decide who can change it

    A workflow that comments on pull requests is one your team will read closely. Editors and admins change the prompt. Operators run it. Viewers read the runs. Share it with the team that owns the repository.

Try it in your workspace.

Start free, connect a tool, and write the first prompt in plain words.