8 Production Claude Code Workflows (With Real Use Cases) in 2026

The Claude Code workflows that matter most: plan-then-build for any task over an hour, the TDD red-green loop for pure logic, a codebase audit pass for inheriting unknown repos, multi-repo refactor for contract changes across services, doc generation from code, a paranoid security review pass, agent-swarm orchestration for parallel scopes, and a locked dependency upgrade flow. Teams that win with Claude Code don't have a smarter model. They have repeatable workflows that lock the right files and verify the output before anything ships.

Claude Code stopped being a chat box in 2025. By 2026, the question is no longer "does the AI write decent code?" but "which workflow do I run for this kind of task?" The hard part is separating workflow theatre from delivery. A lot of what gets posted online is a single prompt with a screenshot. Real production workflows have plan files, agent scopes, lock files, test gates, and rollback paths. They survive across sessions, hand off cleanly between humans and the model, and produce diffs you'd actually merge.

This guide ranks the 8 best Claude Code workflows in 2026. Real use cases from our own delivery work, honest tradeoffs, step-by-step recipes you can copy, and a framework to pick the right workflow for the job in front of you. If you'd rather have a team run them for you, we offer that too via our Claude Code agency.

Best Claude Code workflows: a brief overview

• Plan-then-build (AY /go cycle): Best for non-trivial features: research, plan file, human approval, then locked build with checkpoints.
• TDD red-green loop: Best for pure logic and library code where you can name the function and its inputs upfront.
• Codebase audit pass: Best for inheriting a repo, vendor handoffs, or quarterly code health reviews.
• Multi-repo refactor: Best for monorepo migrations, framework upgrades, or API contract changes across services.
• Doc generation from code: Best for API references, SDK docs, and onboarding guides where source is the truth.
• Security review (paranoid pass): Best for pre-release diffs, auth changes, and anything touching secrets or input validation.
• Agent-swarm orchestration: Best for parallel work across distinct scopes: frontend, backend, infra, tests at the same time.
• Dependency upgrade (locked + tested): Best for major version bumps, framework migrations, and security patch waves.

1. Plan-then-build (the /go cycle), best for any task over an hour

This is the default workflow we run at AY Automate for almost every non-trivial change. The mistake most teams make is sending Claude Code straight into a build for a task that should have been planned. Plan-then-build splits the work into a research and plan phase, a human approval gate, and then a locked build phase with typed checkpoints. The plan file lives in the repo, which means the work survives context loss, agent swaps, and session pauses.

The recipe is short. First, run /plan {task-id}: Claude reads the task file, the relevant directories, and writes a plan folder with steps, files touched, and verification gates. Then a human reads the plan and either approves or asks for revisions. Once approved, run /task-start {task-id} to lock the task and enter build mode. The agent follows the plan step by step, marking [auto], [human-verify], or [decision] checkpoints. When the build finishes, /review runs a self-review pass, and /task-done updates the board.

Key features

• Plan file written to disk before any code changes
• File-based locks prevent two agents from touching the same task
• Typed checkpoints separate what the agent verifies from what a human must
• Survives session pauses via /pause and /resume-ay

Best for

• Features that touch 3+ files or multiple layers
• Refactors where you want a paper trail
• Teams running multiple agents in parallel

Pricing

• Free (workflow pattern, no tooling cost)
• Requires Claude Code subscription for the underlying model

Pros

• Catches scope creep before code is written
• Plan file is reviewable like a PR
• Resumable across days

Cons

• Overkill for one-line fixes
• Plan quality depends on how well the task is described upfront

2. TDD red-green loop, best for verifiable pure logic

Test-driven development with Claude Code is one of the few workflows where the model genuinely outperforms most humans. The reason is mechanical: TDD gives the model an unambiguous specification (the failing test) and a clear exit condition (the test passes). The workflow is most powerful for parsers, validators, transformers, financial calculations, and anything where you can name the function, its inputs, and its expected outputs.

The recipe runs in two beats. Beat one: write the test file yourself or ask Claude to draft tests against a written spec. npm test should fail with a clear error. Beat two: hand the failing test to Claude with the prompt "Make this test pass. Do not modify the test file. Do not add new dependencies." Run the suite. If it passes, run the full suite to check for regressions. If it fails, paste the new error back and iterate. Three to five cycles usually lands a working implementation with full coverage.

Key features

• Failing test is the spec
• No spec drift: the test file is the contract
• Forces small, composable functions
• Pairs well with /qa for diff-aware test runs

Best for

• Library code and utilities
• Data transformers and parsers
• Anywhere correctness matters more than speed

Pricing

• Free (workflow pattern)

Pros

• Output is verifiable on every cycle
• No "looks right but breaks in prod" failures
• Builds test coverage as a side effect

Cons

• Slow for UI work where tests are expensive to write
• Requires you to know the function signature upfront

3. Codebase audit pass, best for inheriting unknown code

When you inherit a repo, whether from a freelancer handoff, an acquisition, or a team rotation, you need a fast, structured map of what exists before you touch anything. The codebase audit workflow runs Claude Code as a read-only analyst across the entire repo and produces an AUDIT.md file with architecture, hotspots, tech debt, security smells, and a recommended order of attack.

The recipe: open the repo in Claude Code and run a prompt template: "Audit this codebase. Produce AUDIT.md with: (1) stack and frameworks, (2) directory map with responsibilities, (3) top 5 modules by complexity, (4) tech debt hotspots with line refs, (5) security smells with line refs, (6) test coverage estimate, (7) recommended first 3 tasks." Let it run unattended for 10-20 minutes on a medium repo. Then read the audit, push back on anything you disagree with, and use it as input for /plan on the first real task.

Key features

• Read-only: no code changes during the audit
• Line-referenced findings, not vibes
• Output is a single markdown file you can commit
• Pairs with the best Claude Code skills for repeatable templates

Best for

• Inheriting a codebase
• Quarterly code health reviews
• Pre-acquisition technical due diligence

Pricing

• Free (workflow pattern)

Pros

• Faster than reading 50K lines yourself
• Findings are line-referenced and checkable
• Output doubles as onboarding doc

Cons

• Quality depends on prompt template; generic prompts produce generic audits
• The model can miss subtle business-logic bugs

4. Multi-repo refactor, best for coordinated changes across services

The classic failure mode in service-oriented architectures is shipping an API change in one repo and breaking three downstream consumers. The multi-repo refactor workflow uses Claude Code with a shared plan file that lists every repo touched, the order of changes, and the verification step for each.

The recipe assumes you've already mapped consumers. If you haven't, run a codebase audit first. Step one: write a REFACTOR.md in the producer repo listing the contract change, the consumer list, and the rollout order (usually consumers first with backwards-compatible reads, then producer, then consumer cleanup). Step two: open Claude Code in the first consumer, hand it REFACTOR.md, and let it implement and test. Step three: commit, move to the next consumer, repeat. Step four: ship the producer. Step five: open a sweep PR per consumer to remove the backwards-compat shim.

Key features

• Single source of truth (REFACTOR.md) shared across repos
• Backwards-compatible rollout order
• Each repo gets its own plan file
• Pairs with the best Claude Code GitHub repos for shared prompt libraries

Best for

• Monorepo migrations
• API contract changes
• Framework version bumps across services

Pricing

• Free (workflow pattern)

Pros

• Reduces "I forgot about that consumer" outages
• Documented change trail across repos
• Reviewable as a series of small PRs

Cons

• Coordination overhead is real; not worth it for 1-repo changes
• Requires up-front consumer mapping

5. Doc generation from code, best for API references and SDK docs

Documentation rots because it lives separately from code. The doc-generation workflow flips that: you keep one source of truth (the code) and have Claude Code regenerate docs on a cadence or pre-release. This works best for API references, SDK method docs, and configuration references where the code is genuinely the truth.

The recipe: pick the docs surface, say docs/api/. Write a prompt template that names the source files, the output format (Markdown with H2 per endpoint, example request/response, error codes), and the style rules (no marketing words, no "we believe", no future tense). Run it on a cadence: pre-release, weekly, or via a GitHub Action triggered on changes to the source files. Review the diff, accept or push back, commit.

Key features

• Source files are the spec
• Prompt template enforces house style
• Output is a markdown diff, reviewable like code
• Can run in CI on file change

Best for

• REST/GraphQL API references
• SDK method documentation
• Configuration and CLI references

Pricing

• Free (workflow pattern)

Pros

• Docs stay in sync with code
• House style enforced by prompt
• Reduces the "stale docs" failure mode

Cons

• Works poorly for conceptual docs (tutorials, explainers)
• Generated examples need a human pass for clarity

6. Security review (paranoid pass), best for auth and input validation

The security review workflow runs Claude Code in a deliberately paranoid mode against a specific diff or module. The framing matters. Generic "find security issues" prompts produce a generic OWASP list. Specific framings ("trace every user input from entry to sink and flag missing validation") produce findings you can actually act on, the kind of gap our rundown of Claude Code security risks covers in more depth.

The recipe: pick the diff (git diff main..HEAD) or the module (a directory path). Run a prompt template that lists the threat models in scope (input validation, secrets in logs, missing authz checks, IDOR, SSRF, path traversal) and asks for line-referenced findings with severity and a suggested fix. Read the output. For each finding, either fix in the same session or open an issue with the line reference.

Key features

• Diff-scoped or module-scoped
• Threat model is named in the prompt
• Line-referenced findings with severity
• Pairs cleanly with PR review

Best for

• Pre-release diffs
• Auth, session, and secrets changes
• Anything handling user input

Pricing

• Free (workflow pattern)

Pros

• Catches issues humans skim past on PR review
• Findings are checkable, not vibes
• Cheap to run on every meaningful diff

Cons

• Not a replacement for a real security audit on regulated workloads
• False positives need triage

7. Agent-swarm orchestration, best for parallel scope-isolated work

For large tasks that decompose cleanly into scopes (frontend, backend, infra, tests) you can run multiple Claude Code agents in parallel, each scoped to a directory, with file-based locks preventing collisions. This is how we run sprint work at AY Automate when a feature touches 4+ layers and a single-threaded build would take days.

The recipe needs setup. Define agents in .claude/agents/, each with a scope (directories owned), skills (domain knowledge packs), and a handoff protocol. For a given task, decompose into subtasks by scope. Each agent picks up its subtask, creates a lock file, builds within its scope only, writes a handoff entry to HANDOFFS.md, and releases the lock. The orchestration layer is just markdown files and lock files, no external tool needed. A human reviews handoffs and approves merges.

Key features

• Scope-isolated agents prevent cross-talk
• File-based locks (no external mutex)
• Async handoff via HANDOFFS.md
• Survives session pauses

Best for

• Full-stack features
• Sprint work with multiple parallel tracks
• Teams running 2+ agents simultaneously

Pricing

• Free (workflow pattern, requires Claude Code per agent)

Pros

• True parallelism, not theatrical "multi-agent"
• Each agent stays in its lane
• Coordination state is in git

Cons

• Setup overhead; not worth it for solo work
• Requires discipline on scope definitions

8. Dependency upgrade (locked and tested), best for major version bumps

Dependency upgrades are where most "AI wrote my code" projects break. The naive workflow ("upgrade React to 19") produces a half-working diff with subtle behavioural changes. The locked-and-tested workflow forces a paper trail: changelog review, breaking-change list, codemod application where available, manual fixes for the rest, and a full test pass.

The recipe: step one, Claude reads the changelog and produces UPGRADE.md with breaking changes, codemod availability, and an estimated effort per change. Step two, you approve the plan. Step three, Claude runs any available codemod (npx react-codemod, next/codemod, etc.) and commits. Step four, Claude works through remaining manual changes one at a time, running the test suite between each. Step five, full smoke test of the running app. Step six, ship behind a feature flag if the surface area is large.

Key features

• Changelog-derived plan file
• Codemod-first, manual-fix-second
• Test suite between each change
• Feature-flag rollout for large surface area

Best for

• Major version bumps (React, Next, Vue, Django, Rails)
• Framework migrations
• Security patch waves

Pricing

• Free (workflow pattern)

Pros

• Reversible at every step
• Test suite catches regressions early
• Plan file is auditable

Cons

• Slower than a "yolo upgrade", but the yolo upgrade is the one that breaks prod
• Codemod gaps still need human judgment

How to choose the best Claude Code workflow

1) How big is the task?

For anything under 30 minutes (a one-file fix, a small refactor, a config tweak) just prompt directly. Workflow overhead isn't worth it. For tasks 30 minutes to a few hours, run plan-then-build (workflow 1); the plan file is the difference between a clean diff and a sprawling mess. For tasks measured in days or sprints, decompose into scopes and run agent-swarm orchestration (workflow 7) with one agent per scope.

2) What kind of work is it?

• Pure logic with clear inputs and outputs: TDD red-green loop (workflow 2)
• Inheriting unknown code: codebase audit pass (workflow 3)
• Coordinated changes across services: multi-repo refactor (workflow 4)
• Documentation that drifts: doc generation from code (workflow 5)
• Security-sensitive diffs: security review (workflow 6)
• Framework or library upgrades: dependency upgrade (workflow 8)

If you're picking workflows often, build a playbook. See best Claude Code skills for reusable templates.

3) How much human review is realistic?

Workflows differ in human-gate density. Plan-then-build and dependency upgrade have explicit approval gates. TDD has implicit gates (the test suite). Codebase audit and doc generation produce reviewable artifacts (markdown files) you can read on your own time. If your team has bandwidth for two reviews per task, plan-then-build is the safest default. If review bandwidth is thin, lean on TDD and security review where the verification is mechanical.

4) Are you running solo or as a team?

Solo developers can run any of these workflows, but the ROI is highest on plan-then-build and TDD where the workflow compensates for the lack of a second reviewer. Teams benefit most from agent-swarm and multi-repo refactor where coordination overhead is the bottleneck. If you want a team that already runs these workflows on production codebases, book a consultation with AY Automate.

Workflows are how you scale Claude Code

A model is not a workflow. A prompt is not a workflow. A workflow is a repeatable sequence with named files, locked scopes, human gates, and verification steps that survives across sessions and team members. The 8 workflows above are the ones we actually run at AY Automate. They're in our .claude/ config, our CLAUDE.md, and our delivery process.

If you want to run these workflows on your own codebase, copy the recipes above and adapt the prompt templates to your domain. If you want a team that ships features using these workflows on production code (Claude Code, the Claude Agent SDK, agent-swarm orchestration with file-based locks, and honest human gates), that's what our Claude Code agency does. For broader automation, AI workflow, and chatbot work, see our service pages or book a consultation and we'll map the right workflow to the task in front of you.

FAQ

What is a Claude Code workflow?

A Claude Code workflow is a repeatable, named sequence of steps for using Claude Code on a specific kind of task. A workflow names the files it touches, the prompts or commands it runs, the human gates, and the verification step. The difference between a workflow and a prompt is that a workflow survives across sessions and team members. It lives in your repo, not your head.

How is a workflow different from a prompt template?

A prompt template is one step inside a workflow. A workflow is the whole sequence: setup, prompt, output check, next prompt, gate, verification, commit. The plan-then-build workflow uses three or four prompt templates plus a human-approval gate plus a lock file plus a test gate. Prompts alone don't survive context loss; workflows do.

Are these workflows specific to Claude Code or do they work with other AI coding tools?

The patterns transfer, but the implementation details (file-based locks, /go commands, plan folders) are Claude Code-specific. The underlying ideas (plan files, scope isolation, verification gates) work with any agentic coding tool. We've found Claude Code's longer context window and stronger instruction-following make these workflows more reliable than equivalents on other models in 2026.

How much does it cost to run these workflows?

The workflows themselves are free. They're patterns, not products. The cost is the Claude Code subscription and any underlying API usage. Most of the workflows here run inside a normal Claude Code subscription. Agent-swarm with multiple parallel agents adds cost proportional to the number of agents running concurrently.

How long does it take to learn these workflows?

Plan-then-build and TDD are usable in a day. Codebase audit, doc generation, security review, and dependency upgrade need a week of practice to build solid prompt templates. Multi-repo refactor and agent-swarm orchestration need a couple of weeks because they require setting up scopes, agents, and shared plan files for your specific repo layout.

Do I need to use the AY Framework to run these workflows?

No. The AY Framework is one implementation of plan-then-build and agent-swarm with file-based locks, but you can run all 8 workflows with just Claude Code and a CLAUDE.md file; the Claude Code setup guide covers the full config. The framework helps if you're running multiple agents in parallel or want strict pre-commit gates, but it's optional. For hooks that enforce those gates, see Claude Code hooks examples.

Should we use workflows or just prompt directly?

For short tasks, prompt directly. For anything over an hour, use a workflow. The break-even is when the cost of a wrong direction (re-doing work, broken merges, untested code shipping) exceeds the cost of writing a plan file. For most production teams, that break-even is around 30-60 minutes of work.

Can these workflows train my internal team?

Yes, that's part of why we wrote them down. The workflows are documented enough that an engineer who hasn't used Claude Code can read them and start running plan-then-build on their next ticket. For a reference of the full production Claude Code setup, from settings and hooks through MCP and CI integration, see the production Claude Code breakdown. For team training and Claude Code adoption on existing codebases, our Claude Code agency runs on-site and async enablement engagements.