GitHub triggers

What you’ll know by the end of this check

• Which GitHub events can start a routine (and which can’t)
• How to use filters to scope who and what triggers runs
• Why every matching event gets its own isolated session

The shortest possible answer

A GitHub trigger runs a routine automatically when a matching repo event fires — a new PR, a release, a label, a merge. Wire a routine to your PR lifecycle and every opened PR gets a review without anyone asking for one.

Configured in the web UI only. Subject to per-routine and per-account hourly caps during research preview.

The two event categories

Within each category, you can pick a specific action (like pull_request.opened) or subscribe to all actions in the category.

What’s missing: issues, pushes, comments, stars, forks, deployments. If you want something other than PRs and releases, you’re looking at GitHub Actions, not routines. See GitHub Actions for a broader event surface.

Filters: scope which PRs start runs

All filter conditions must match for the routine to fire. The fields available:

Each filter pairs a field with an operator: equals, contains, starts with, is one of, is not one of, matches regex.

Regex gotcha: the matches regex operator tests the entire field value, not a substring. To match any title containing hotfix, write .*hotfix.*. Without the .* on both sides, you’d only match a title that is exactly hotfix. For literal substring matching, use contains instead.

Four filter combinations worth stealing

• Auth module review — base branch main, head branch contains auth-provider. Every PR touching auth routes to a focused reviewer routine.
• External contributor triage — from fork is true. Every fork-based PR gets extra security + style review before a human looks at it.
• Ready-for-review only — is draft is false. Skips drafts. Routine only runs when the PR is actually ready.
• Label-gated backport — labels include needs-backport. Routine only fires when a maintainer tags the PR.

Pattern: narrow the trigger, broaden the routine’s usefulness. A tightly filtered trigger firing 10 times a day produces better output than a loose filter firing 100 times.

Each event gets its own session

No session reuse across GitHub events. Two PR updates = two independent sessions. Each starts fresh, clones the repo, runs the routine, exits. This matters for cost, for speed, and for how you write the routine’s prompt — it can’t accumulate context from prior fires.

If you need continuity across events, store intermediate state somewhere the routine can read next time (a repo file, an issue body, a Linear ticket).

Research preview caps

GitHub webhook events are subject to per-routine and per-account hourly caps. Events beyond the cap are dropped until the window resets. Check your current limits at claude.ai/code/routines. If you’re wiring a routine to a high-volume repo (dozens of PRs/day), plan for throttling.

Things to try right now (15 minutes)

1. Open the test routine from check 02 in the web UI.
2. Add a GitHub trigger for pull_request.opened on a safe repo.
3. Add a filter: is draft is false AND head branch contains test-claude (so only your intentional test PRs fire).
4. Push a branch prefixed test-claude/ and open a PR.
5. Confirm the routine fires. Check the session URL to see what Claude did.
6. Close the test PR. Note that pull_request.closed did NOT fire (because your trigger was opened only).

The canonical version

Full official docs: code.claude.com/docs/en/routines.

Ready to verify this check?

You’ve fired a routine from a real GitHub PR. You can name at least three filter combinations that would be useful in your workflow. You understand regex anchoring. Mark it cleared.