Last week, a teammate mentioned that a PR had been reviewed automatically overnight. Nobody had requested a review—Claude had opened the PR during the night, left inline comments aligned with our team's coding conventions, and added a summary. That was my first real encounter with Claude Code Routines.
Anthropic released Routines as a research preview on April 14, 2026. It's still in beta, but it genuinely changes how you think about automating recurring work. In this guide, I'll walk through how Routines actually work, how to set them up, and—honestly—where they fall short. This is based on direct experience, not just reading the docs.
What Is Claude Code Routines? — The Prompt + Repository + Connector Model
The official documentation puts it this way: "A routine is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically."
In practice, there are three pieces:
Prompt: The instructions Claude follows on each run. The key constraint is that this prompt must be completely self-contained. "Do what we did last time" won't work—every execution starts fresh with no memory of previous runs.
Repository: The GitHub repository (or repositories) Claude clones and works in. It starts from the default branch. There's one important restriction: by default, Routines can only push to branches prefixed with claude/. This is a deliberate safety guard against accidentally modifying protected branches.
Connectors: External service integrations built on MCP (Model Context Protocol). Slack, Linear, Google Drive, and GitHub are currently supported. Connectors are what allow routines to read from and write to external systems—not just manipulate code.
Put these three together and you get an AI agent that runs on Anthropic's infrastructure without needing your laptop open or your own servers running.
Prerequisites
To use Routines, you'll need:
- A Pro, Max, Team, or Enterprise plan with Claude Code enabled on the web
- A GitHub account for repository integration
- Any MCP connectors (Slack, Linear, etc.) pre-configured before creating routines
Daily run limits by plan:
| Plan | Daily Routine Runs |
|---|---|
| Pro | 5 runs/day |
| Max | 15 runs/day |
| Team | 25 runs/day |
| Enterprise | 25 runs/day |
Honestly, the Pro plan's 5 runs/day feels tight. A team with more than 10 PRs a day will hit that ceiling quickly. For serious use, Team plan or above is the realistic starting point.
Step 1 — Creating Your First Routine
Three methods are available.
Web UI (Most Intuitive)
- Navigate to
claude.ai/code/routines - Click "New routine"
- Name the routine and write the prompt
- Select one or more GitHub repositories
- Choose a cloud environment (controls network access, env vars, setup scripts)
- Select trigger(s): Schedule / API / GitHub Event
- Review connector configuration
- Create
The prompt is the most critical part. Write it specifically and self-containedly:
You are a code reviewer for this repository.
Find PRs opened today and perform the following:
1. Verify the PR title and description follow [repository name] conventions
2. Check changed files for obvious bugs or security issues
3. Confirm test coverage is adequate (at least one test per new function)
4. Leave inline comments for specific issues and a summary comment on the PR
After completing the review, send "Review complete: [PR title]" to the Slack #code-review channel
Avoid vague phrases like "review appropriately" or "in team style." Routines don't ask follow-up questions.
CLI Method
From within a Claude Code session, use the /schedule command:
/schedule daily PR review at 9am
Claude walks through the setup conversationally. Management commands afterward:
/schedule list # View all routines
/schedule update # Edit an existing routine
/schedule run # Run immediately (for testing)
Desktop App Method
Go to Schedule → New task → New remote task. This redirects to the web UI.
Step 2 — Configuring Triggers
Routines support three trigger types, and a single routine can combine all three simultaneously.
Schedule Triggers
Set a recurring cadence. Options:
- Hourly / Daily / Weekdays / Weekly
- Custom cron expressions
# Run daily at 9am (local timezone, auto-converted)
cron: 0 9 * * *
# Every Monday at 10am
cron: 0 10 * * 1
The minimum interval is one hour—no per-minute polling.
I tested a weekly schedule for documentation drift detection, running every Monday morning to scan the previous week's merged PRs and open update PRs for stale API docs. It worked reasonably well, though Claude occasionally missed cases where API changes were only reflected in code comments. More specific prompts are the fix.
API Triggers
Each routine gets a dedicated HTTP endpoint with per-routine bearer token authentication.
# Trigger a routine via API
curl -X POST \
https://api.anthropic.com/v1/claude_code/routines/{routine_id}/fire \
-H "Authorization: Bearer {routine_token}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "Content-Type: application/json" \
-d '{"text": "api/users endpoint changed in this deploy. Docs verification needed."}'
The text field lets you pass run-specific context. This is particularly useful for monitoring systems that trigger routines when anomalies are detected.
For example: when a Sentry alert fires, it could trigger a routine that analyzes the stack trace, correlates it with recent commits, and opens a draft fix PR. CD pipelines can trigger smoke test routines via API after each deployment.
If you've built an MCP server from scratch before, you already understand how this connector ecosystem extends. Routines bring those same connectors into an automated execution environment.
GitHub Event Triggers
This is the most powerful trigger type. Routines run automatically when PR or release events occur.
Supported events:
- PR: opened, closed, assigned, labeled, synchronized, updated
- Release: created, published, edited, deleted
Filtering options are granular—by PR author, title/body text, branch name, labels, draft status, merge status, or regex pattern.
# GitHub event trigger config for PR review routine
trigger:
type: github_event
event: pull_request.opened
filters:
- author_not_in: ["dependabot[bot]", "renovate[bot]"] # Exclude bots
- base_branch: "main"
- labels_not_contains: ["skip-review"]
Step 3 — Integrating External Services with MCP Connectors
Connectors are how routines communicate with the outside world. Currently supported:
- Slack: Read/write channel messages
- Linear: Create/update issues
- Google Drive: Read/write documents
- GitHub: PR comments, issue management (included by default)
All currently connected MCP connectors are included by default when you create a routine. Remove connectors you don't need to limit the routine's access scope—this is a basic security hygiene practice.
A practical integration example:
[Slack + Linear issue triage routine]
Read new messages from Slack #bug-reports from the last 24 hours and:
1. Determine if it's a reproducible bug report
2. If it's a bug, create a Linear issue (severity: infer from content)
3. Reply in the Slack thread with the Linear issue link
4. For unclear cases, send a message asking for more information
If you're already familiar with Claude Code's five agentic workflow patterns, Routines map most cleanly onto the "Autonomous Agent" pattern—running on cloud infrastructure on a schedule rather than interactively.
Four Real-World Use Cases
Here are the Routine types I've found to work well in practice.
Case 1: Automated PR Review
The use case with the most immediate impact. Set a trigger on pull_request.opened, put your team's coding conventions in the prompt, and Claude starts reviewing every PR automatically.
[Core PR review routine prompt]
Referencing the style guide in CONTRIBUTING.md:
- Verify variable names follow camelCase or snake_case conventions
- Check for CHANGELOG.md updates when public APIs change
- Confirm OpenAPI spec additions for new endpoints
Leave specific issues as GitHub inline comments, overall summary as PR comment
Do NOT leave "LGTM" or "Request Changes" verdicts—that decision belongs to humans
That last line matters. Giving Claude final approval authority makes team members uncomfortable and erodes trust in the review process. Keep Routines in the "find and explain" role; let humans decide.
Case 2: Nightly Backlog Triage
A routine that classifies newly opened issues every night.
Run daily at midnight:
1. Fetch all GitHub issues opened today
2. Add type tags (bug, feature-request, question, documentation)
3. Auto-assign by code area (reference CODEOWNERS file)
4. Create Linear issues with results (send summary to Slack #triage)
One thing I learned from running this: if CODEOWNERS isn't kept up to date, the routine assigns to the wrong people. Routines don't create good automation out of thin air—they amplify whatever quality your underlying data already has.
Case 3: Post-Deploy Smoke Test
Trigger a routine via API at the end of your CD pipeline.
# Trigger after deploy completes
curl -X POST \
https://api.anthropic.com/v1/claude_code/routines/{smoke_test_routine_id}/fire \
-H "Authorization: Bearer {token}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-d '{
"text": "v2.3.4 deployed. Environment: production. Deploy time: 2026-04-22T14:30:00Z"
}'
The routine calls key API endpoints, scans error logs, and posts a go/no-go verdict to #releases.
I covered how to deploy MCP servers to Kubernetes in production previously. Adding this smoke test routine as the final step in that pipeline connects the two setups cleanly.
Case 4: Weekly Documentation Drift Detection
Every Monday morning, scan last week's merged PRs, find where API documentation has diverged from code, and open update PRs.
This one genuinely impressed me. Manually catching the gap between code changes and documentation updates every week is unrealistic for most teams. Having a routine handle this continuously is a meaningful quality improvement. The important caveat: never auto-merge Claude's generated update PRs. Always keep a human review step.
Honest Assessment — Limitations and Cautions
Routines are genuinely useful, but the research preview status shouldn't be dismissed.
It's too early for production-critical paths. The API requiring the experimental-cc-routine-2026-04-01 header signals exactly where this feature stands. The API surface can change, with only the previous two versions maintaining compatibility. Critical automation needs more validation time.
Audit trails are insufficient. Tracing why Claude made a specific decision is difficult. When a routine leaves a comment or creates an issue automatically, reconstructing the full reasoning from logs is currently close to impossible. Teams operating in regulated environments or requiring strong accountability should wait.
No approval checkpoints. Routines run fully autonomously. Mistakes can be committed to the repository before anyone notices. The default branch push restriction (claude/ prefix) provides some protection, but bad changes can still accumulate within those branches.
GitHub event processing has rate limits. During the research preview, GitHub events are subject to per-routine and per-account hourly caps. Attaching event triggers to high-volume monorepos can cause events to be dropped.
No session continuity. Two GitHub events mean two independent sessions. There's no way to carry context from one execution to the next.
My personal rule: I only use Routines for work where it doesn't matter if the run fails or produces an imperfect result. Tasks where mistakes are easily reversible. Tasks where failures are naturally corrected by the next execution. That's where Routines consistently deliver value.
If you've mastered parallel Claude Code sessions with git worktrees, think of Routines as extending that parallelism across time—while you're doing one thing, a routine is handling something else in a different repository.
Conclusion — Which Teams Should Try This?
My honest position: Routines are currently best suited as an experimental tool for teams already comfortable with AI automation.
Start with three categories of work:
First, repetitive tasks humans need to do regularly but where the rules are clear (backlog triage, label classification).
Second, tasks where failures are naturally corrected by the next run (documentation drift detection).
Third, tasks whose outputs still go through human review before taking effect (review drafts, update PR drafts).
Anthropic's investment in Routines is clearly accelerating. Better logging, higher GitHub event throughput, and session continuity support are likely coming soon. Starting now with lower-stakes use cases lets you find the patterns that work for your team—so when the feature stabilizes, you already have validated routines ready to expand.
Reference Links:
Top comments (0)