How to Use Claude Code Routines to Automate Your Workflows
Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu
Get started at: https://claude.ai/code/routines
Claude Code on the web must be enabled. Routines are available on Pro, Max, Team, and Enterprise plans.
Daily run limits: Pro: 5 runs per day Max: 15 runs per day Team: 25 runs per day Enterprise: 25 runs per day
You can go beyond these limits with extra usage enabled. Each routine run counts against your subscription usage the same way an interactive session does.
Existing /schedule tasks automatically converted to routines with no manual migration needed.
THE THREE TRIGGER TYPES
Every routine needs at least one trigger. You can combine multiple triggers on the same routine. A PR review routine can run nightly on a schedule, trigger from a deploy script via API, and also react to every new PR via GitHub events. All three use the same prompt and configuration.
TRIGGER 1: SCHEDULED
Give Claude a cadence. Hourly, nightly, weekly. It runs on that schedule automatically.
How it works: You write a prompt that describes what to check, what counts as important, and what to do about it. Claude executes that prompt on the schedule you set, reads whatever context it finds in your repos and connectors, and takes action.
Example prompt for nightly bug triage:
"Pull all issues opened since yesterday from Linear. For each issue, read the linked code if available. Apply labels based on the area of code referenced. Assign owners based on the CODEOWNERS file. If the issue looks like a regression from a recent PR, flag it as high priority and link the PR. Post a summary to the #engineering-triage Slack channel with the count of new issues, assignments made, and any flagged regressions."
Example prompt for weekly docs drift:
"Scan all PRs merged into main since the last run. For each PR that changes a public API endpoint, check if the corresponding documentation in /docs references the old behavior. If it does, open a new PR against the docs repo with the updated information. Post a summary of docs PRs opened to the #docs Slack channel."
TRIGGER 2: API
Every routine gets its own endpoint and a bearer token. Send an HTTP POST with an optional message parameter, get back a session URL. You can fire routines from anywhere that can make an HTTP request: your alerting stack, your deploy pipeline, Zapier, n8n, a custom script, or any internal tool.
The API endpoint uses the experimental-cc-routine-2026-04-01 beta header. Request and response formats may change during the research preview. Anthropic guarantees the two most recent previous header versions keep working so you have time to migrate.
Example: deploy verification
Your CD pipeline calls the routine's API endpoint after each production deploy. The routine runs smoke checks against the new build, scans error logs for regressions introduced since the last deploy, and posts a go or no-go to the release Slack channel before the deploy window closes.
Example: alert triage
Your monitoring tool detects an error threshold and sends the alert body as text in the POST request. The routine pulls the stack trace, correlates it with recent commits in the repo, identifies the likely cause, and opens a draft PR with a proposed fix and a link back to the alert. Your on-call engineer reviews the PR instead of starting from a blank terminal at 3am.
Example: feedback pipeline
A customer submits feedback through your app. Your backend fires the routine with the feedback text. Claude reads the feedback, checks the relevant codebase for the feature being discussed, determines if it is a bug or a feature request, creates the appropriate issue in Linear with labels and context, and posts to Slack if it is urgent.
TRIGGER 3: GITHUB EVENTS
Subscribe a routine to fire automatically in response to GitHub repository events. Supported events include: pull request, push, issue, check run, workflow run, discussion, release, and merge queue.
For pull requests specifically, you can filter by: author, title, body, base branch, head branch, labels, draft state, merged state, and whether it comes from a fork.
Each matching event starts its own independent session. For pull requests, Claude opens one session per PR and continues to feed updates from that PR to the same session. So if someone leaves a review comment or CI fails, Claude picks it up in the existing session and can address follow-ups.
Example: automated code review
A routine triggers on pull_request.opened. Claude reads the diff, applies your team's review checklist, leaves inline comments for security issues, performance concerns, and style violations, and adds a summary comment so human reviewers can focus on architecture and design instead of catching mechanical issues.
Anthropic uses a version of this internally. Every time a PR merges into their release branch, a routine fires to synthesize and update documentation.
Example: PR filter for specific areas
Set the filter to base branch main, head branch containing "auth-provider", and is_draft set to false. This routes any ready-for-review auth PR to a focused security review routine with a prompt specifically designed for authentication code.
HOW TO CREATE YOUR FIRST ROUTINE
Option 1: Through the browser
Go to claude.ai/code/routines. Click new routine. Give it a clear name. Write your prompt. Choose the model. Link the repos and connectors you want it to access. Add one or more triggers. The routine is live immediately.
Option 2: Through the CLI
Type /schedule in Claude Code. Provide a description and it registers the routine. The same command lets you list current routines or modify existing ones.
WRITING GOOD ROUTINE PROMPTS
Each routine execution is stateless. The prompt carries the entire job specification. There is no memory between runs unless you explicitly write state to a file in your repo.
Include these in every routine prompt:
What to check: Be specific about the data source. "Read issues opened since the last run" is better than "check for new issues."
What counts as important: Define your criteria. "Flag as high priority if the issue mentions a production endpoint and was opened by a customer-facing team" gives Claude clear decision rules.
What to do about it: Describe the actions. "Open a draft PR with the fix" or "Post to the #alerts channel with the issue link and a one-sentence summary."
When to stop or escalate: "If the fix requires changes to more than 3 files, create the issue but do not attempt a PR. Post to Slack asking for human review instead."
Failure modes: "If you cannot access the repo or a connector fails, post an error message to #routines-errors with the routine name and the failure reason."
Test your prompt in a normal Claude Code session first. Run it manually a few times and check the output. Once it produces reliable results, convert it to a routine.
10 WORKFLOWS WORTH BUILDING
These are the most practical routines based on what Anthropic is using internally and what early adopters are reporting.
- NIGHTLY BUG TRIAGE
Trigger: Scheduled, every weeknight at 11pm What it does: Reads all issues opened since the last run from your issue tracker. Labels them by area of code. Assigns owners based on CODEOWNERS. Flags regressions by cross-referencing recent PRs. Posts a summary to Slack so the team starts the day with a groomed queue. Why it matters: Most teams start their morning triaging yesterday's issues. This routine does it overnight and the team walks in to a clean board.
- AUTOMATED CODE REVIEW
Trigger: GitHub event, pull_request.opened What it does: Reads the diff, applies your team's review checklist, leaves inline comments for security and performance issues, and posts a summary comment. Continues to respond if CI fails or reviewers leave comments. Why it matters: Human reviewers spend less time on mechanical checks and more time on architecture and design decisions.
- DEPLOY VERIFICATION
Trigger: API, called by your CD pipeline after each deploy What it does: Runs smoke checks against the new build. Scans error logs for regressions. Posts a go or no-go to the release channel before the deploy window closes. Why it matters: Your team gets immediate confirmation that a deploy is clean instead of waiting for users to report issues.
- DOCS DRIFT DETECTION
Trigger: Scheduled, weekly What it does: Scans merged PRs since the last run. Identifies PRs that changed public APIs. Checks if documentation references the old behavior. Opens update PRs against the docs repo for an editor to review. Why it matters: Documentation goes stale the moment code changes. This routine catches it before users notice.
- ALERT TRIAGE AND AUTO-FIX
Trigger: API, called by your monitoring tool when an error threshold is crossed What it does: Receives the alert body. Pulls the stack trace. Correlates with recent commits. Opens a draft PR with a proposed fix linked back to the alert. Why it matters: On-call engineers review a proposed fix instead of debugging from scratch at 3am.
- DEPENDENCY UPDATE CHECK
Trigger: Scheduled, weekly What it does: Checks for outdated packages across your repos. For each outdated dependency, reads the changelog for breaking changes. If the update looks safe, opens a PR with the version bump and runs your test suite. If tests pass, marks the PR as ready for review. If they fail, posts the failure details. Why it matters: Dependency updates are tedious but critical for security. This routine handles the boring part and only surfaces what needs human judgment.
- STALE PR CLEANUP
Trigger: Scheduled, every Monday morning What it does: Finds all PRs that have been open for more than 7 days with no activity. Posts a comment on each one asking if it is still active. If a PR has been stale for more than 14 days, posts a summary to Slack tagging the author and reviewer. Why it matters: Stale PRs clog your review queue and create merge conflicts. This keeps the pipeline moving.
- RELEASE NOTES GENERATOR
Trigger: GitHub event, release.published What it does: When a new release is published, reads all PRs merged since the last release tag. Groups them by type (feature, fix, refactor, docs). Writes human-readable release notes. Opens a PR adding them to CHANGELOG.md. Why it matters: Nobody likes writing release notes manually. This produces them automatically from the actual work that shipped.
- ONBOARDING DOCUMENTATION
Trigger: Scheduled, monthly What it does: Scans the repo for new files, new directories, and significant structural changes since the last run. Updates the project's onboarding documentation and architecture overview to reflect the current state of the codebase. Why it matters: Onboarding docs are always out of date. This routine keeps them current so new team members do not start with stale information.
- CUSTOMER FEEDBACK TO ISSUE PIPELINE
Trigger: API, called when a customer submits feedback through your app What it does: Reads the feedback text. Checks the codebase for the feature being discussed. Determines if it is a bug report, feature request, or general feedback. Creates an issue in your tracker with appropriate labels, priority, and context. Posts to Slack if it is urgent. Why it matters: Customer feedback often sits in a queue for days before someone reads it. This triages it in real time.
ROUTINES VS GITHUB ACTIONS VS CRON JOBS
GitHub Actions runs set commands you write. It is deterministic. The same input produces the same output every time. Best for builds, tests, linting, and deployments.
A cron job runs a fixed shell command on a fixed schedule. No reasoning, no context awareness. Best for simple recurring tasks like clearing logs or rotating keys.
A routine runs a Claude Code configuration that reads context, reasons about what it finds, and decides what to do. Best for tasks that require judgment: should this PR be flagged? Is this alert worth waking someone up for? Does this documentation need updating based on what changed?
They are complementary. Use Actions for your CI/CD pipeline. Use cron for simple maintenance. Use routines for anything that requires reading, reasoning, and deciding.
TIPS FOR GETTING THE MOST OUT OF ROUTINES
Start with one. Pick the routine that saves you the most repetitive time. Nightly bug triage or automated code review are the best starting points for most teams.
Test your prompts manually first. Run the prompt in an interactive Claude Code session 3 to 5 times. Check the output each time. Only convert to a routine once you are confident in the results.
Be explicit about failure modes. Tell the routine what to do when something goes wrong. "If you cannot find the file, skip it and note it in the summary" prevents silent failures.
Keep prompts focused. One routine, one job. A routine that tries to triage bugs, update docs, and review PRs in the same run will produce worse results than three separate routines that each do one thing well.
Use connectors. Connect Slack, Linear, Google Drive, and GitHub so your routines can read from and write to the tools your team already uses. A routine that posts to Slack is useful. A routine that only writes to a file nobody checks is not.
Monitor your runs. Check the session URLs returned by your routines. Read the output occasionally to make sure the quality stays high. Adjust prompts when you notice recurring issues.
Combine triggers when it makes sense. A code review routine can fire on every PR and also run nightly to catch anything that slipped through. Same prompt, multiple entry points.
GETTING STARTED TODAY
Go to claude.ai/code/routines Or type /schedule in the Claude Code CLI
Pick one workflow from the list above. Write the prompt. Set the trigger. Let it run. Check the output tomorrow morning. Adjust and repeat.
The teams getting the most out of Claude Code in 2026 are not the ones writing the best prompts in interactive sessions. They are the ones who packaged their best prompts into routines and let them run automatically. Configure it once. It handles the rest.
You just read the full playbook. Most people will close this tab and never implement it. The ones who do usually hit a wall around the technical setup and quit.
Inside the Skool, I walk you through the exact build step-by-step, troubleshoot your setup live in the community, and share the scripts and templates I use to actually land paying clients.
If you want the shortcut instead of the long way around: