Claude Code Routines: Automating Agentic Loops with GitHub Events Without a Server
The moment a PR is opened, review comments appear without anyone touching it. When a release is published, the changelog is automatically filled in. No server, no cron, no GitHub Actions workflow file. The first time I saw this, I thought, "Is this actually real?"
In April 2026, Anthropic released Claude Code Routines as a research preview. Claude Code is a developer CLI agent built by Anthropic — a tool that autonomously handles code writing, modification, and execution in the terminal. Unlike GitHub Copilot or Cursor, which suggest code inside an editor, Claude Code directly executes shell commands, file modifications, and Git operations. Routines is a feature where, once a session is configured, Anthropic's cloud infrastructure takes over all subsequent executions. No local process or self-hosted CI runner required.
From our team's actual experience, the most tangible change is this: PRs opened overnight already have a first-pass review completed by the time we arrive in the morning, and when a release tag is applied, the changelog fills itself in. This post covers the specific configuration for running agentic loops in the cloud triggered by GitHub events, and the pitfalls commonly missed in early designs.
Core Concepts
What a Routine Does, in One Sentence
A Routine is a cloud agent that receives a "configured prompt + repository context + connectors," and spins up a fresh Claude Code session to run autonomously each time a trigger fires.
Agentic Loop: An autonomous execution cycle where an AI agent repeats tool calls → result checks → next action decisions without human intervention. Routines manage this loop in the cloud.
Trigger detected
→ Start new Claude Code session
→ Read prompt + inspect repository
→ Call connectors (MCP) & shell commands
→ Output results as commits, PRs, messages, or API calls
→ End sessionThere is no point where a human intervenes. The structure has no way to pause and ask "Wait, is this right?" mid-execution. That's why prompt design is everything.
Three Trigger Types
| Trigger | Description | Typical Use Case |
|---|---|---|
| Schedule | Time-based (hourly–weekly, or a single one-time future run) | Nightly dependency audits, weekly documentation sync |
| API | On-demand execution via HTTP POST + Bearer token | Slack event → ticket creation pipeline |
| GitHub | Repository events like pull_request, push, release |
PR reviews, automated release note generation |
The focus of this post is the GitHub trigger. Install the Claude GitHub App on your repository, and Anthropic's webhook server receives events directly and launches the agent. There's no need to create a .github/workflows/ file like with GitHub Actions.
How the GitHub Trigger Works
GitHub Repository
└─ Event fires (PR opened, push, release...)
└─ Claude GitHub App (installation required)
└─ Anthropic webhook server receives event
└─ Mapped Routine launches
└─ Agent accesses repository + performs task
└─ PR comment / branch push / API callNothing runs locally. By default, pushes are only allowed to branches with the claude/ prefix, which structurally prevents the agent from accidentally pushing directly to main. This guardrail can be changed in Routine settings, but I recommend leaving it at the default when first adopting it.
When installing the GitHub App, repository read/write permissions are granted. Teams sensitive to security should limit the App installation scope to specific repositories and explicitly control which branches and files the agent accesses at the prompt level.
Research Preview: A pre-general-release stage, accessible on Pro/Max/Team/Enterprise paid plans. API specs, limits, and behavior may change without notice. Currently activatable with any of those plans without a separate application process.
Practical Application
Example 1: Automated Code Review the Moment a PR Opens
Honestly, this was the most well-received case on our team. When a junior developer opens a PR, review comments appear within seconds. PRs opened in the evening after seniors have left for the day already have a first-pass review completed by the next morning. It doesn't replace human review — it filters out items that can be checked mechanically in advance, so there was no resistance either.
The YAML below is a conceptual representation of how to configure in Claude Code's Routine settings screen (UI form or CLI claude routine create). For the actual interface, it is recommended to refer to the official documentation.
trigger:
type: github
event: pull_request.opened
repository: your-org/your-repo
prompt: |
Review this PR according to the team checklist.
Check the following items and leave inline comments and a summary comment on GitHub:
- Test coverage gaps (new functions without tests)
- Security anti-patterns (hardcoded credentials, SQL injection possibilities)
- Missing documentation (README not updated when public API changes)
Write comments in a specific, improvement-oriented form.
Leave all results only as GitHub PR comments; do not commit to the branch.
connectors:
- github| Component | Description |
|---|---|
pull_request.opened |
Triggers immediately when a PR is created |
pull_request.labeled |
Triggers only when a specific label is added (enables selective execution) |
Do not commit to the branch |
Explicitly limits the output form to comments |
Using a label-based filter (pull_request.labeled) lets you control execution so it only runs when the team adds an "ai-review" label. This is especially useful in the current research preview environment with daily execution limits. It also maintains higher trust because the agent is only used on PRs the team has decided need review.
Example 2: Automatic Changelog Generation from Release Events
What if the changelog was already complete the moment you apply a version tag and publish a release? At first I underestimated how tedious this work is, but digging through commit lists for every release actually gets tiring.
trigger:
type: github
event: release.published
repository: your-org/your-repo
prompt: |
Analyze the commits included in this release.
Write a changelog based on the following criteria:
- Breaking Changes (at the top if any)
- New Features
- Bug Fixes
- Dependencies
Write in user-facing language and exclude internal refactoring.
Update the GitHub release notes with the completed changelog.
connectors:
- githubWhether you can use context variables like {{ release.tag_name }} inside prompts is recommended to verify first in the official documentation for the list of supported variables. The available variable scope differs by trigger type.
The output is a clear artifact (release notes), and no human judgment is needed during execution — making it a perfect fit for Routines. The clearer the input (commit list) and output (release notes update), the less room there is for the agent to make mistakes.
Example 3: Detecting Code Quality Drift with Push Events
This pattern was introduced on our team with the goal of "making technical debt visible." It automatically tracks patterns missed in individual PR reviews — such as accumulating TODO comments or public functions added without tests. At first I worried there would be too many issues created, but a single condition — "if there are no issues, do nothing" — caught most of the noise.
trigger:
type: github
event: push
branch: main
repository: your-org/your-repo
prompt: |
Analyze the commits just merged.
Check the following items and create a GitHub Issue if there are issues:
1. List of newly added TODO/FIXME comments
2. Public functions added without tests
3. Direct environment variable references (using process.env without a config module)
Attach a 'tech-debt' label to issues and include the discovered file path and line number.
If there are no issues, do nothing.
connectors:
- githubThe last line "If there are no issues, do nothing" matters more than you'd think. Without it, cases actually arise where the agent opens an issue saying "Confirmed: no anomalies found." It is recommended to also specify in the prompt what to do when the input has no anomalies.
Using push as a trigger without any conditions can exhaust the daily limit on an active development day. It is better to restrict execution to only after merges with a filter like branch: main.
Example 4: Slack → Linear Ticket Pipeline with API Trigger
Here's one example using an API trigger instead of a GitHub event. This pattern automatically converts a message with a specific emoji reaction in Slack into a bug ticket. The API trigger structure has an external system calling the Routine first, so the flow is: a Slack app detects an event → calls the Routine API. It's a case that shows just how practical the MCP connector ecosystem is, and it's a pattern I personally use often.
# Call Claude Routine API from Slack app
curl -X POST https://api.anthropic.com/v1/claude-code/routines/{routine_id}/fire \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "Content-Type: application/json" \
-d '{
"input": {
"slack_message": "500 error occurring on payment page, 100% reproducible",
"channel": "#bugs",
"reporter": "alice"
}
}'The endpoint URL and beta header (
experimental-cc-routine-2026-04-01) above are based on the research preview. The spec may change, so it is recommended to check the latest spec in the official API documentation before actual integration.
trigger:
type: api
prompt: |
Analyze the following Slack message and create a Linear bug ticket:
Message: {{ input.slack_message }}
Channel: {{ input.channel }}
Reporter: {{ input.reporter }}
Content to include in the ticket:
- Title: concise bug description
- Priority: estimated based on message content (500 error = High)
- Reproduction steps: information extractable from the message
- Reporter and original Slack link
connectors:
- slack
- linearWhat makes this pattern particularly effective is the ability to connect Slack and Linear — two external systems — without a separate webhook server or authentication bridge. Previously, this kind of integration required at least one Lambda function, but the connector handles authentication.
Pros and Cons Analysis
Here's an honest summary of what I've felt after using it for a few months. It's not all upside — and given the research preview nature, there are parts that aren't quite ready to recommend unconditionally to an entire team.
Pros
| Item | Content |
|---|---|
| Zero infrastructure | No servers, runners, or cron daemons needed. Anthropic's cloud handles the execution environment |
| GitHub native | Use PR/push/release events as triggers simply by installing the App |
| Built-in MCP connectors | Slack, Linear, Google Drive integrations work without a separate auth server |
| Branch guardrails | Default push only allowed to claude/ prefix branches — main protection automated |
| Identity consistency | Commits, PRs, and Slack messages are all created under your own account |
Cons and Caveats
| Item | Content | Mitigation |
|---|---|---|
| Daily execution limit | Pro: 5, Max: 15, Team/Enterprise: 25 (per official docs, subject to change) | Reduce unnecessary triggers with label-based filters |
| Hourly webhook cap | Excess events are dropped during research preview | Lower firing frequency by specifying trigger conditions precisely |
| No mid-run approval | No step to ask a human during execution | Restrict output to PR drafts or comments; prohibit direct merges in the prompt |
| No local MCP | Only Anthropic cloud-hosted MCPs supported | Check supported connector list in advance |
| GitHub App permissions | Read/write scope granted to repositories at install time | Limit App installation to only the repositories needed |
| Research preview instability | API specs, limits, and behavior may change | Maintain critical workflows in parallel with GitHub Actions |
MCP (Model Context Protocol): A tool integration protocol for AI agents defined by Anthropic. Routine connectors use this protocol to communicate with external services like Slack and Linear. Local MCP servers are not currently supported; only connectors hosted in Anthropic's cloud can be used.
Most Common Mistakes in Practice
-
Not specifying the output format in the prompt — Writing just "review this" leaves the agent to decide on its own whether to commit to a branch, leave a comment, or open an issue. It is recommended to clearly specify output boundaries like "Leave results only as GitHub PR comments. Do not commit."
-
Omitting the "if nothing found, do nothing" condition — Agents tend to want to show results. Without this condition, cases arise where "No issues confirmed" comments or empty PRs get created.
-
Trigger design without considering daily limits — Using
pushas a trigger without any conditions will exhaust the limit on the team's active development days. It is good to combine a branch filter (branch: main) or label condition.
Closing Thoughts
The core value of Claude Code Routines lies not in "what the agent can do" but in "whether repetitive work with clear outputs can be automated without infrastructure."
It's still a research preview with low daily limits and a fluid spec, but this is actually a good time to experiment with patterns that fit your team. Rather than trying to automate everything from the start, it's safer to begin with the single simplest thing that has the clearest outcome.
Three steps you can start right now:
-
Install the Claude GitHub App — Navigate to the Routines settings at claude.ai/code and connect the App to your repository. This prepares it to receive GitHub events via webhook. Without this step, GitHub triggers will not work.
-
Create one PR code review Routine — Start with a
pull_request.openedtrigger, but add "Do not commit to the branch; leave results only as GitHub PR comments" at the end of the prompt. This prevents unintended branch creation. -
Adjust execution frequency with label-based filters — Using
pull_request.labeled+ai-reviewlabel combination lets you control the agent to run only when the team wants it. You can adopt it progressively, building trust while conserving your daily limit.
References
- Automate work with routines | Claude Code Official Documentation
- Trigger a routine via API | Claude API Official Documentation
- Claude on X — Routines Launch Announcement (2026-04-14)
- Anthropic adds routines to redesigned Claude Code | 9to5Mac
- Claude Code can now do your job overnight | The New Stack
- Claude Code Routines: Anthropic's Answer to Unattended Dev Automation | DevOps.com
- Claude Code Routines: From Assistant to Autonomous Agent | Medium
- Claude Code Routines: A Practical Guide (2026) | Nimbalyst
- Claude Code Routines Tutorial | Builder.io
- Claude Code Routines: 8 Prompts + What Breaks | Linas Substack
- Week 16 Release Notes (2026-04-13~17) | Claude Code Docs
- How I Turned Slack Chaos Into Linear Tickets With Claude Code | Samuel Lawrentz