GitHub

PushesCopy Anchor Link

Select GitHub push under Add trigger, then choose a repository. Under Files, enter comma-separated paths or glob patterns such as packages/agent-api/**, backend/**/*.ts. An optional exact branch name limits the trigger to pushes to that branch; leave Branch blank for any branch.

A push starts a run only when at least one added, modified, or removed file matches a pattern. The agent receives the repository, branch, commits with their messages and authors, the matching files, and every changed file in the push. Each trigger starts at most one run per pushed commit, so redeliveries do not create another run. Branch deletions and tag pushes are ignored.

Watch: Configuring a GitHub push triggerSet up a read-only review that runs on every push to main touching src/api/**. Shows configuration only; no push or run.

Configuring a GitHub push trigger

Status checksCopy Anchor Link

Select GitHub status check under Add trigger, then choose a repository and one or more results. An optional exact branch name limits the trigger to the branch being checked, not a pull request's target branch. Leave Check names blank for any check, or enter comma-separated names or glob patterns such as buildkite/**.

For “whenever a check fails on master, triage and fix,” select the repository, set Branch to master, keep the default failure results, and write that instruction as the automation prompt. Select the same repository under the automation's repositories so its session starts from the checked branch. The agent receives the checked commit, check name, result, and details link.

Watch: Configuring a CI failure triggerStart an investigation automatically when a check fails on main, with a prompt that asks for the cause and smallest fix without pushing changes.

Configuring a CI failure trigger

The trigger responds to completed check runs and commit status results, including checks on branches without an open PR. It starts one run per matching trigger, check, result, and commit; repeated reports and reruns with the same result on the same commit do not create another run. Check-suite summaries do not create extra runs. Branch-filtered triggers skip events whose branch is unknown. Creating a trigger does not scan existing failures; it responds to subsequent events.

Pull request commentsCopy Anchor Link

Select GitHub PR comment under Add trigger, choose a repository, and add conditions. Every condition must match for a comment to start a run:

• Comment text contains, starts with, ends with, or equals a value, or does not.
• Comment type is a conversation comment, an inline review comment, or a review summary.
• Author type is a person or an app or bot.
• Comment author is, or is not, one of the listed GitHub logins.

For example, a trigger whose comment text starts with /inspect and whose author type is a person lets reviewers ask Inspect for help directly from a pull request.

New comments and submitted reviews start runs; edits and deletions do not. Reviews that contain only inline comments start runs through their inline comments rather than through an empty summary. The agent receives the pull request number, title, link, and branches, along with the comment's text, author, type, and link, and the file and line for inline comments. When the pull request comes from the same repository and that repository is selected under the automation's repositories, the session starts from the pull request's head branch. Each comment starts at most one run per trigger.