6 Claude Code patterns we ship every week

A lot of Claude Code content shows you the tool. This post shows you the workflows — the specific chains of commands and agents that turn Claude Code from a novelty into infrastructure. These are patterns our team runs weekly. They're not the only ways to work; they're the ones that survived contact with real projects and stuck.

Each pattern lists the commands, agents, and hooks involved. Everything mentioned is in cctk's catalog, but the patterns matter more than the specific implementations. Adapt them to whatever tools your team uses.

Pattern 1: The morning triage

The morning triage is the first thing most of the team does. Open a terminal, run pr-reviewer against the PR queue, and get a prioritized summary of what needs attention. Not "here are 12 PRs open" — instead: "PR #442 needs a nudge (waiting on you), PR #438 has a merge conflict that'll take 5 min, PR #431 has a test failure you might already know how to fix."

The subagent does the boring work of clicking through each PR and reading the diff. What comes back is a focused list of what to actually do. On a typical morning it turns 30 minutes of PR triage into 5 minutes of triage plus 25 minutes of the work itself.

For this pattern

Pattern 2: The refactor session

When you need to change a subsystem meaningfully — not "rename this function" but "reshape how this module handles state" — the refactor session is the pattern. refactor-agent runs with a clear prompt describing the target state, produces a plan (files to change, order to change them, tests to run between steps), and executes the plan with tests between each step.

The key is the plan-before-execute structure. Naive refactoring ("just change everything") introduces subtle bugs. The plan makes the change reviewable in chunks; when a test fails, you know exactly which step caused it and can decide whether to fix the code or update the test.

Our team does a refactor session about once a week for something moderate-sized. Big refactors (framework migrations, huge module reorganizations) get two or three sessions across days, with human review between.

For this pattern

Pattern 3: The test backfill

Any codebase over a year old has coverage gaps — files that grew without tests, edge cases that only became apparent post-hoc. The test backfill pattern uses /test-coverage to find the gaps (weighted by risk, not just line count), then /test-unit or /test-integration to fill them.

This is one of the highest-ROI patterns because it's work that's easy to defer forever ("we'll write tests when we get to it") and yet compounds — every test you don't have is a bug waiting to slip through. We do one focused test backfill session per week, usually 30-60 minutes, targeting a specific module.

For this pattern

Pattern 4: The incident deep-dive

When something breaks in production, the incident deep-dive pattern is what runs first. incident-investigator subagent connects to Sentry (via MCP), Datadog (via MCP), and your codebase. It reads the recent errors, correlates them with recent deploys and metric changes, and produces a hypothesis for what happened plus a list of things to check.

The critical part isn't that Claude figures out the answer (often it doesn't, incidents are messy). It's that you skip 10-20 minutes of "click through Sentry, then click through Datadog, then grep the code" before you can start the actual investigation. The context is assembled for you.

For this pattern

Pattern 5: The docs sweep

Documentation rot happens silently. The docs sweep is a monthly pattern that runs docs-agent across the README, API docs, and inline JSDoc comments to find things that no longer match the code. It doesn't auto-update — it produces a list of "here's what claims to be true but isn't" for human review.

The subagent format matters here — this is delegated work, not interactive. You fire it off, it takes 5-10 minutes, and you review the report. Not something you'd do line-by-line in the editor.

For this pattern

Pattern 6: The deploy prep

Before every deploy, the deploy prep pattern runs. Not manually — via hooks. The pre-commit-guard hook enforces commit message quality. The block-secrets hook catches anything that looks like an API key or credential before it hits the commit. The auto-format hook makes sure formatting stays consistent. All of these run automatically on tool use; the developer doesn't need to remember them.

This is where hooks earn their keep. Individually, each hook is small. Together, they enforce the "don't deploy something we'd regret" invariants that would otherwise require constant vigilance from the reviewer. Hooks make good practices automatic.

For this pattern

Making patterns fit your team

These six patterns work for our team. Yours might have different ones — different tools, different pain points, different rhythms. What matters isn't adopting these specific patterns; it's recognizing that Claude Code's value comes from repeated workflows, not one-off uses.

A useful exercise: notice what you do repeatedly this week. If you find yourself doing the same three-step thing twice, that's a pattern candidate. Write a slash command. Build a subagent. Add a hook. The 15 minutes of setup pays back within a week.

That's the actual power of Claude Code — not that it's intelligent, but that it makes automating your own workflows almost trivially easy. The patterns that emerge from that automation are what compound over months into real productivity gains.