Claude Code Routines Practical Guide — Fully Automating Repetitive Dev Tasks with Schedules, Webhooks, and API Triggers

PR reviews, issue triage, documentation updates. We've all had days completely swallowed up by work that doesn't involve writing a single line of code. For a while, I thought "maybe this is just the developer's fate" — but after encountering Claude Code Routines, released by Anthropic in April 2026, my thinking shifted. It's not just about AI writing code for you; it's about building a structure where your workflows keep running even when you're away from your desk.

In this post, I'll cover exactly what Routines are, how they differ from existing Claude Code automation layers, and how you can use them in practice. The key point is that once configured, sessions run autonomously in the cloud — even when your local machine is off. By the end of this post, you'll see that setting up a nightly issue triage routine in under 30 minutes is entirely within reach.

One caveat upfront: Routines are currently in research preview, so the API spec and behavior may change going forward. Some code examples are based on the official spec but written at a pseudo-code level. Before applying them in production, I strongly recommend checking the latest spec in the official Anthropic documentation.

Core Concepts

The 4 Layers of Claude Code Automation

Before Routines, Claude Code already had three layers supporting automation. Understanding those three layers first is the best way to make sense of Routines.

If the first three layers define how something runs, Routines define "when, and triggered by what." And there's one critical difference: they run in the cloud. Close your laptop, lose your internet connection — the routine keeps going.

Three Trigger Types

There are three main ways to start a routine. The examples below are in pseudo-code form for conceptual understanding.

# 1) Schedule-based — runs on a recurring cron expression
# Korea is UTC+9 fixed (no DST), so KST 02:00 = UTC 17:00
schedule: "0 17 * * *"   # runs every day at 2:00 AM KST
 
# 2) GitHub webhook — starts automatically on PR events
trigger:
  event: pull_request.opened
 
# 3) API trigger — called directly from an external system
# The endpoint below is a hypothetical example for illustration purposes. Check the official docs for the real API URL.
# POST https://api.claude.ai/routines/{routine-id}/trigger

MCP (Model Context Protocol) — The standard protocol that connects Claude to external services like GitHub, Slack, and databases. The reason a routine can "read a GitHub issue and send a summary to Slack" is because MCP acts as the bridge between them.

Hooks vs. Routines: What's the Difference?

Honestly, I was confused for a while — "how is this different from Hooks?" — but once I laid it out, the distinction is quite clear.

review-only mode permits only read-level and annotation-level actions — like modifying issue labels or writing PR comments — and blocks code changes or merges. deploy mode expands that scope to include PR creation and pushing. The exact permissions belonging to each mode may change during the preview period, so follow the latest spec in the official documentation.

Note: there is currently no public information about which runtime Routines run on in the cloud (container vs. serverless). If you're in an infrastructure-sensitive environment, this is worth keeping in mind.

Practical Application

Example 1: Nightly Issue Triage Automation

This is a situation I run into regularly in practice — arriving at work to find the entire morning gone because of issues that piled up overnight. My team saved nearly 2 hours a week after introducing this routine, and the setup itself took less than 30 minutes.

Below is an example of a routine prompt file. The actual file path and key structure may differ depending on the official spec.

<!-- .claude/routines/nightly-triage.md (pseudo-code format) -->
# Nightly Issue Triage
 
## Schedule
# Korea (UTC+9, no DST): UTC 17:00 = KST 02:00
schedule: "0 17 * * *"
 
## Permissions
mode: review-only
# review-only: allows issue label/assignee modifications, blocks code changes and PR merges
 
## Connectors
connectors:
  - github
  - slack
 
## Task Instructions
1. Fetch all open issues created today
2. Classify each issue with one of the following labels: bug / enhancement / question / duplicate
3. Assess severity from P0 to P3
4. Add a team label (backend / frontend / infra)
5. Send a classification summary to the Slack #dev-issues channel

Example 2: Automatic Code Review When a PR Opens

Integrated with a GitHub webhook, Claude starts a review session the moment a PR is opened. I was skeptical at first — "will an AI review actually be useful?" — but it catches type safety issues and obvious edge cases surprisingly well.

<!-- .claude/routines/pr-review.md (pseudo-code format) -->
# PR Automatic Code Review
 
## Trigger
trigger:
  event: pull_request.opened
  event: pull_request.synchronize
 
## Permissions
mode: review-only
# Only allows reading code and writing PR comments. Cannot merge or modify branches.
 
## Connectors
connectors:
  - github
 
## Task Instructions
1. Analyze the diff of changed files
2. Focus the review on:
   - Type safety and null handling
   - Performance issues (N+1 queries: the pattern of repeatedly querying the DB inside a loop)
   - Security vulnerabilities (based on OWASP Top 10)
   - Missing test coverage
3. Provide specific improvement suggestions as inline comments
4. Leave an overall summary as a PR body comment

Example 3: Fixing Issues with a Custom Slash Command

Here's a slash command example that works well in combination with routines. When a routine automatically classifies issues, it naturally connects to a developer invoking the fix command directly.

<!-- .claude/commands/fix-issue.md -->
Find GitHub issue #$ARGUMENTS, analyze the root cause,
implement a fix, write a test that reproduces the bug,
and open a PR with a clear description.

# Call it from the terminal like this
/project:fix-issue 1234

When multiple routines run simultaneously and touch the same repository, conflicts can occur. Git Worktrees solve this by giving each routine its own isolated workspace. The approach is to create a separate directory with something like git worktree add ../project-routine-1 main.

Pros and Cons

Advantages

Disadvantages and Caveats

Plan Mode — Useful during routine design. It lets you see the plan Claude would form without actually executing any code, so you can safely iterate on your routine prompt before committing to it.

The Most Common Mistakes in Practice

1. Granting merge permissions to a routine — Auto-generated PRs should always be reviewed by a human before merging. It's recommended to allow routines to create PRs at most, and keep merges manual.
2. Forgetting environment variables — The most common reason things work fine locally but fail in cloud routines. It helps to list all required Secrets upfront when configuring a routine.
3. Writing routine prompts too vaguely — The more specific, the more predictable the results. "Handle the issues" is far less reliable than "attach an urgent label to P0 bug issues only and mention the backend team." Running a dry run with Plan Mode first lets you verify the behavior matches your intent.

Closing Thoughts

Claude Code Routines marks a turning point — transforming AI from a one-off tool into a team member that's always on. It's still in research preview, but even applying a single small routine is enough to feel just how much repetitive work disappears.

Three steps you can start with right now:

1. Consider setting up a low-stakes review-only routine like nightly issue triage as your first one. A routine that only classifies labels and sends summaries — with no code-change permissions — is low-risk and great for experimenting. Check the latest spec on the official blog and give it a try.
2. It's worth keeping your project context well-organized in CLAUDE.md. This file is the only project instruction reference available when a routine runs in the cloud. Documenting your code style, branching strategy, and key constraints in advance makes a real difference in the quality of routine output.
3. Try creating a custom slash command and wiring it to a routine. Just add a single .md file to the .claude/commands/ folder and you can invoke it as /project:command-name. It naturally creates a workflow where developers handle issues — already classified by a routine — using a fix command.

Next post: Mastering Claude Code Hooks — Building a Local Automation Pipeline with PreToolUse and PostToolUse Events

References

• Introducing routines in Claude Code | Anthropic Official Blog
• Claude Code Routines: Automate Dev Workflows | DEV Community
• Automate workflows with hooks | Claude Code Official Docs
• Common workflows | Claude Code Official Docs
• We tested Anthropic's Claude Code Routines | VentureBeat
• Claude Code Routines: The Cloud Automation Branch | LaoZhang AI Blog
• awesome-claude-code | GitHub
• Claude Code Custom Commands: 3 Practical Examples | AI Engineering Report
• 7 Claude Code best practices for 2026 | eesel AI