Skip to content
Lesson 12 of 14

Real-World Patterns and Workflows

8 min read

From Features to Workflows

You have learned individual Claude Code features throughout this course. This lesson shows you how professionals combine those features into complete workflows that solve real development challenges. Each pattern includes when to use it, what setup it requires, and a step-by-step walkthrough.

Pattern 1: Code Review Pipeline

When to use it: Before merging any pull request, especially in teams without dedicated reviewers.

Setup: A skill that defines your review criteria, plus MCP server for GitHub integration.

Create skills/code-review.md:

---
triggers:
  - slash_command
name: review-pr
description: Comprehensive code review pipeline
---

Execute these checks in order:

1. Run the linter: `npm run lint` — report any violations
2. Run the test suite: `npm test` — confirm all tests pass
3. Check for security issues: `npm audit --production`
4. Review the diff for:
   - Logic errors and edge cases
   - Missing error handling
   - Performance concerns
   - Naming and readability
5. Summarize findings with severity ratings: critical, warning, info

Workflow:

# In Claude Code with GitHub MCP server configured
/review-pr

# Claude runs linter, tests, security audit, then reviews the diff
# Output: structured review with actionable items

This pattern replaces the ad-hoc "can you look at my code" request with a repeatable, consistent review process that covers the same checklist every time.

Pattern 2: PR Automation

When to use it: After receiving feedback on a pull request that requires multiple rounds of changes.

Setup: GitHub MCP server for fetching PR comments.

Workflow:

# Fetch all review comments from the PR
You: Fetch the review comments from PR #42 and address each one.

# Claude reads each comment, understands the requested change,
# makes the edit, and marks the comment as resolved

# After addressing all comments
You: Run the tests to verify nothing is broken, then push the changes.

For teams that handle many PRs, wrap this into a skill:

---
triggers:
  - slash_command
name: pr-comments
description: Fetch and address all PR review comments
---

1. Use the GitHub MCP server to fetch all unresolved review comments on the current PR
2. For each comment:
   a. Read the comment and understand the requested change
   b. Make the change in the relevant file
   c. Run affected tests to verify the fix
3. After all comments are addressed, run the full test suite
4. Show a summary of all changes made

Pattern 3: Documentation Generation

When to use it: When your codebase lacks documentation, or when documentation has drifted from the code.

Setup: Print mode for batch processing.

#!/bin/bash
# generate-api-docs.sh

for file in src/api/**/*.ts; do
  module=$(basename "$file" .ts)
  echo "Documenting: $module"

  claude -p "Generate API documentation for this module. Include:
    - Module purpose (one paragraph)
    - All exported functions with signatures, parameters, return types
    - Usage examples for each function
    - Error cases and how to handle them
    Output as markdown." \
    --max-turns 3 \
    < "$file" > "docs/api/${module}.md"
done

Run this script periodically or integrate it into your CI pipeline to keep documentation in sync with code.

Pattern 4: Test-Driven Development

When to use it: When building new features where correctness is critical.

Setup: A skill that enforces the TDD cycle.

---
triggers:
  - slash_command
name: tdd
description: Test-driven development — write tests first, then implement
---

Follow the TDD cycle strictly:

1. Ask the user to describe the feature or function
2. Write comprehensive test cases FIRST:
   - Happy path tests
   - Edge cases (empty input, null, boundary values)
   - Error cases (invalid input, network failures)
3. Run the tests — confirm they all FAIL (red phase)
4. Implement the minimum code to make tests pass (green phase)
5. Run the tests — confirm they all PASS
6. Refactor the implementation for clarity and performance (refactor phase)
7. Run the tests — confirm they still PASS
8. Show the user the final test file and implementation

Workflow:

/tdd

You: I need a function that validates email addresses. It should support
     standard formats, reject obvious fakes, and handle edge cases like
     plus-addressing and international domains.

# Claude writes 12 test cases first, runs them (all fail),
# then implements the validator, runs tests (all pass),
# then refactors for readability

Pattern 5: Debugging Workflow

When to use it: When facing a bug that is not immediately obvious.

Setup: Extended thinking enabled, effort set to high.

Workflow:

1. Reproduce
   You: This test is failing intermittently: tests/auth/session.test.ts
        Run it 5 times and tell me the pattern.

2. Isolate
   Claude: [runs test 5 times, analyzes output]
   "The test fails when tests run in parallel because they share
    a database connection. The session table has a race condition
    on concurrent inserts."

3. Fix
   You: Fix the race condition. Use database-level locking or
        unique constraints instead of check-then-insert.

   Claude: [modifies the session service, adds unique constraint migration]

4. Verify
   You: Run the test 20 times to confirm it is stable.

   Claude: [runs test 20 times — all pass]
   "20/20 passes. The fix is stable."

The key is the systematic approach: reproduce, isolate, fix, verify. Claude's ability to run tests repeatedly and analyze patterns makes it exceptionally good at finding flaky test root causes.

Pattern 6: Refactoring With Safety

When to use it: When restructuring code that is working correctly and must continue to work correctly.

Setup: Checkpoints for rollback, test suite for verification.

Workflow:

1. Checkpoint (automatic)
2. Run full test suite — baseline all passing
3. Refactor step by step:
   a. Extract module → run tests → pass? continue : rewind
   b. Rename interfaces → run tests → pass? continue : rewind
   c. Reorganize imports → run tests → pass? continue : rewind
4. Final review: run full suite + linter
5. If everything passes → commit
6. If anything fails → /rewind to last good checkpoint

This pattern treats refactoring as a series of small, verifiable steps. Each step is validated by the test suite, and any failure triggers an immediate rollback to the last known-good state.

You: Refactor the user service into separate modules: authentication,
     profile management, and authorization. After each extraction,
     run the test suite and only proceed if all tests pass.
     If any test fails, rewind and try a different approach.

Pattern 7: Multi-Repo Coordination

When to use it: When a change spans multiple repositories (API server, client library, documentation).

Setup: Subagents in separate worktrees for each repo.

You: I need to add a new "teams" endpoint to the API, update the JS client
     library to support it, and add the endpoint to the API documentation.

# Claude spawns subagents:
# - Agent 1: works on api-server repo (add endpoint + tests)
# - Agent 2: works on js-client repo (add client method + tests)
# - Agent 3: works on api-docs repo (add endpoint documentation)

# Each agent works in its own worktree, independently
# Main session coordinates and reviews all changes

Pattern 8: Database Migration

When to use it: When you need to change a database schema in a way that could break existing queries.

Setup: Planning mode for safety, MCP server for database access.

Workflow:

# Start with a plan — no changes yet
/plan I need to split the "users" table into "users" and "profiles".
     The migration must be backwards-compatible and support zero-downtime deployment.

# Claude explores the codebase, finds all queries that touch the users table,
# and produces a migration plan:
#
# Phase 1: Add profiles table, copy data
# Phase 2: Update queries to read from profiles
# Phase 3: Add triggers for dual-write during transition
# Phase 4: Remove deprecated columns after verification

# Review and approve the plan, then execute phase by phase

Combining Features

The most effective workflows layer multiple Claude Code features:

| Feature | Role in Workflow | |---------|-----------------| | Skills | Define the process and checklist | | Hooks | Enforce guardrails automatically | | MCP Servers | Connect to external data sources | | Subagents | Parallelize and isolate work | | Checkpoints | Enable safe rollback | | Planning | Design before building | | Print mode | Automate in CI/CD |

A production-grade PR workflow might use a skill to define the review process, a hook to block merges without review, an MCP server to fetch PR data from GitHub, a subagent to run security analysis in isolation, and a checkpoint before applying any suggested changes.

Anti-Patterns to Avoid

Over-delegating without review. Giving Claude full autonomy on critical systems without reviewing the plan first. Always use planning mode for high-impact changes.

Skipping checkpoints on risky operations. If you would not do it without a Git stash, do not do it without a checkpoint.

Ignoring cost signals. Long-running sessions with extended thinking on every request burn tokens fast. Use /cost regularly and adjust effort levels appropriately.

Monolithic prompts. Asking Claude to "refactor the entire codebase" in one prompt. Break large tasks into focused, sequential steps with verification between each one.

Not testing automation in isolation. Deploying a CI pipeline with Claude Code steps without testing the exact commands locally first. Always verify with claude -p before committing to a workflow.

These patterns are not theoretical -- they represent the workflows that experienced Claude Code users have refined through daily practice. Start with the ones closest to your current needs and adapt them to your specific codebase and team.