Spawn an agent session in response to Pull Request lifecycle events

A react trigger runs an agent when something happens on a pull request: it opens, the head advances, a review is submitted, a comment lands, it merges or closes. The agent acts on the event itself; there is no typed prompt, just the agent's system plus the event context.

Splitshift runs a describer on every new pull request:

ellipsis:
  version: v1
  name: PR describer
  description: Write a reviewer-ready description on every new pull request

claude:
  system: |
    Read the diff and the surrounding code. Rewrite the pull request
    description: what changed, why it likely changed, and what a
    reviewer should look at first. Keep the author's checklist items
    if they wrote any. Update the description with gh.

trigger:
  type: react
  pull_request:
    on: [opened]

sandbox:
  repositories:
    - name: splitshift-api

budget:
  session: 1.00
  day: 10.00

When priya-shah opens "Expire pending trades on account deactivation" with a one-line description, the session reads the diff and replaces it with a summary of the change, the motivation pulled from the linked issue, and the two files reviewers should start with.

Surfaces

A react trigger sets exactly one surface block, and each config is one automation. Two surfaces cover the pull request lifecycle: pull_request reacts to the actions you list, and code_review follows the head as a review bot. Every surface carries only the filters that make sense for it.

React fires every matching config independently, so a reviewer, a describer, and a labeler can all run on the same pull request.

Actions do not each start a session. Everything an agent reacts to on one pull request is delivered into one durable conversation: the first action starts it, later ones continue it with full memory of what the agent already did, and a merge or close ends it. A react agent posts no reply per action; it acts through the sandbox.

pull_request

on lists the pull request actions to react to:

Filters: repositories (the repos to watch, by name), base and head (branch names, prefixes ending in *, or default), draft (true or false), labels (any match), paths (changed-file globs, ** allowed), and for (see Who triggers it).

trigger:
  type: react
  pull_request:
    on: [pushed]
    base: [main]
    paths: ["src/api/**"]

code_review

code_review reviews the unreviewed part of a pull request on every head advance, and never re-comments lines it already reviewed. It is action-less: it fires when the head advances (open plus each push) and there are new commits past what the agent last reviewed. Use it for a review bot; use pull_request: {on: [pushed]} when you want to run something on each push (tests, a description update).

It reuses the pull_request filters minus on: repositories, base, head, draft, labels, paths, for.

trigger:
  type: react
  code_review:
    base: [main]
    for: { users: true, exclude_users: [priya-shah] }

Scoping to a repository

repositories is the watch set: a list of repository names to react in. Owners default to the account. An empty list watches every repository. This is independent of sandbox.repositories — the repository that triggered the event is always cloned into the sandbox.

trigger:
  type: react
  pull_request:
    on: [opened]
    repositories: [splitshift-api]

Who triggers it

for decides which authors trigger a config, classified on the pull request author. It is include minus exclude:

• users — true (all humans), a list of logins, or false/[] (none). Defaults to true.
• bots — same shape, for bot accounts. Defaults to false, so automation like Dependabot never triggers by accident.
• exclude_users / exclude_bots — logins to subtract from the include set.

Because react fires every matching config, for is how you make two configs mutually exclusive: a general reviewer for: { users: true, exclude_users: [priya-shah] } and a per-author reviewer for: { users: [priya-shah] } never both fire on one pull request.

Next

Answer conversational requests instead of events with mentions, or see how a session executes for what happens after the trigger fires.