Claude Code Routines: Save and Replay Your Best Coding Workflows

Routines in Claude Code solve the single most frustrating thing about working with AI agents: getting good results once and having no reliable way to reproduce them.

Every developer who uses Claude Code seriously has had this experience. You set up a session perfectly - the right framing, the right behavioral guidelines, the right context. Claude works exactly the way you want. The next day you open a new session and spend the first 20 minutes rebuilding that setup from memory, trying to approximate what worked before. Routines end that. You capture the session configuration once and invoke it by name.

What a Routine actually is

A Routine is a named, saved workflow. More precisely, it is the setup you would normally type manually at the beginning of a Claude Code session: the project context, the behavioral instructions, the task framing, the guardrails. Instead of reconstructing this each time, you define it once and invoke it with a single command.

The effect on session quality is significant. Claude Code's behavior varies based on how a session is framed. A well-set-up session produces different results than a cold start on the same problem. Routines lock in the configuration that produced good results and let you reproduce it reliably, rather than hoping you remember exactly how you set things up last time.

Routines versus CLAUDE.md - a real distinction

CLAUDE.md is a persistent project-level file Claude Code reads automatically at session start. It carries static project context: architecture decisions, naming conventions, dependencies, things Claude should always know. It is passive and universal - always loaded, always present.

Routines are intentional and situational. You invoke them when you are about to do a specific kind of work. A Routine for adding a new API endpoint is different from a Routine for reviewing a pull request. Each one sets up Claude Code with the right priorities and constraints for that task type. You choose which Routine to run based on what you are about to do.

CLAUDE.md	Routines
Loads automatically every session	Invoked deliberately before a task
Project-wide, static context	Task-specific behavioral setup
Always active in background	Active only when you choose it
Architecture, conventions, dependencies	Workflows, priorities, output formats

In practice, CLAUDE.md and Routines complement each other. The file tells Claude about your project. The Routine tells Claude how to approach the current task.

Where Routines deliver the most value

Project onboarding is the most immediate use case. Developers who work across multiple codebases or bring Claude Code into new projects regularly spend significant time at the start of each session establishing context. A Routine that describes the project structure, explains key architectural decisions, and sets working preferences eliminates that ramp-up time. Run the Routine once and the session starts aligned.

Testing workflows benefit from the consistency Routines enforce. A Routine that specifies running tests before and after any change, producing a structured summary of what changed, and surfacing failures before proceeding - this is a behavioral standard that requires consistent reinforcement without Routines. With them, you invoke the workflow and it behaves the same way every time.

Code review is the third natural fit. A Routine focused on a pull request - check for security issues, identify performance problems, flag style violations, produce a structured report - is immediately reusable. You run the same Routine on every PR and get comparable output quality across reviews, not results that vary based on how carefully you set up the session.

The common thread: Routines are worth the setup investment when the workflow is both repeatable and important enough that quality variation is a real cost. One-off experiments do not need Routines. Standard workflows that matter do.

The community was solving this before Anthropic shipped it

The developer community built unofficial approaches to this same problem for months before Routines existed. The caveman skill compressed output to save tokens. Tools like Claudraband created persistent tmux sessions for multi-step work spanning multiple Claude Code invocations. The underlying problem in both cases was the same one Routines address: Claude Code's default behavior is a starting point, and experienced users need to build predictable, reusable workflows on top of it.

Anthropic shipping Routines as a first-class feature signals they are paying attention to what developers actually built and integrating the patterns that worked. That is a healthier development cycle than ignoring the workarounds.

Who is ready for Routines right now

Routines are most useful for developers who have been using Claude Code long enough to know what works for their specific situation. If you are still exploring the tool's capabilities, you do not yet have workflows worth saving. You are in discovery mode, and that is fine.

When you have a session that produces exactly what you need - the framing clicks, Claude's behavior aligns with your expectations, the output quality is high - that is the session to capture. That is when you define a Routine and stop rebuilding that setup from scratch.

Compared to how Cursor handles workflow persistence through IDE-level configuration, Routines take a different approach - they are portable, session-level, and explicitly invoked. Neither approach is objectively better. The right tool depends on whether you work across multiple codebases or live primarily inside one environment.

Which brings it back to where this started: getting good results once and being able to reproduce them. That problem does not sound dramatic. It does not make headlines. But it is the difference between Claude Code being an impressive tool you use when conditions are right and an engineering resource you can count on every day. Routines close that gap.