Claude Code: Part 3 - The Workflow

“Through discipline comes freedom.” — Aristotle

This is Part 3 of a three-part series on Claude Code configuration. Part 1 covers foundation and mixin architecture. Part 2 covers enforcement hooks and plugins.

We’ve built the foundation. We’ve deployed the enforcers. Now the question becomes: how do you actually use all this in daily development?

This post is about workflow—the rhythms, patterns, and practical wisdom that emerge from months of AI-assisted development. Fair warning: some of this advice contradicts conventional wisdom. That’s fine. Conventional wisdom was developed for conventional tools.

Three Projects, Three Personalities

Here are three very different projects that I maintain, each with its own Claude Code configuration. They illustrate how the same foundation can serve radically different needs.

The Meta Project: Claude Code Managing Claude Code

Yes, I use Claude Code to manage my Claude Code configuration. The recursive joy of this never gets old.

Inside ~/.claude/.claude/ (that’s a .claude directory inside ~/.claude), I keep project-specific settings for developing Claude Code plugins, agents, skills, and hooks. When I want to add a new enforcement hook or define a new specialized agent, I fire up a CC session in that directory and let it help me.

This creates a delightfully self-improving loop:

1. I notice a pattern I want to enforce
2. I use CC to write the hook
3. The hook immediately affects all future CC sessions
4. Including the session that will improve the hook

The configuration is minimal—mostly just orchestration and read-only permissions. The real work is plugin development, which follows standard coding patterns.

Isambard: Zero Tolerance TypeScript

Isambard is my agentic AI companion project. It’s TypeScript, it’s complex, and it has zero tolerance for quality issues.

The CLAUDE.md for Isambard is aggressive:

## TDD Mandate (RED-GREEN-REFACTOR)
1. **RED**: Write a failing test first
2. **GREEN**: Write minimal code to pass the test
3. **REFACTOR**: Clean up while keeping tests green

Never write production code without a failing test. Tests are not optional.

## Quality Gates
Before any PR or commit:
- [ ] All tests pass (`bun test`)
- [ ] Zero TypeScript errors (`bun run typecheck`)
- [ ] Zero lint warnings (`bun run lint`)
- [ ] Mutation score at 100% for changed files (`bun run mutate`)

The mutation testing requirement is the key enforcement. 100% mutation score means your tests actually verify the code, not just execute it. This catches the AI’s tendency to write tests that achieve coverage without actually testing anything meaningful.

Isambard also has five specialized TypeScript agents (feature-developer, quality-guardian, etc.), LSP integration for symbol-based editing, and tmux integration for watcher monitoring. It’s the most heavily configured project I have.

Rungie.com: Skill-Based Content Workflows

This blog is a Hugo static site. There’s almost no “code” in the traditional sense—just HTML templates, SCSS styling, and content markdown.

The configuration reflects this: instead of many custom agents, I have six specialized skills:

Skills are lighter than agents—they’re essentially specialized prompts that Claude can invoke when needed. For content work, skills are usually enough.

Important: The orchestrator principle still applies. Even without custom agents, the orchestrator doesn’t implement directly—it delegates to Claude Code’s built-in agents (general-purpose, Explore). The difference isn’t whether delegation happens, but which agents handle the work.

I also have two custom agents (hugo-content-agent and hugo-deploy-agent) for more complex multi-step operations, but most work flows through the generic agents using skills.

The Comparison Matrix

The point isn’t that one configuration is “better.” A Hugo blog doesn’t need mutation testing. A complex TypeScript project absolutely does.

The Development Rhythm: Bursts

Here’s the workflow pattern that’s emerged: bursts of creating followed by bursts of simplifying.

The Creation Burst

During a creation burst, I’m shipping features. The focus is forward progress:

• New functionality
• New tests
• New integrations

Claude Code in creation mode is fast. With the orchestrator delegating to specialized agents, I can implement features that would have taken hours in minutes. The quality gates catch obvious problems, but I’m not obsessing over code elegance. I rarely read the generated code directly—only snippets when Claude asks clarifying questions. I read plans carefully and always tell Claude to ask questions before proceeding. Once the plan is locked, I trust the work—assuming no stray permission prompts interrupt the session.

Typically Claude works for 10-60 minutes depending on the task, and when it completes it’ll be 99% done. Even with all the gates in place, I still generally need to confirm that lint, typecheck and mutation testing are all “clean” and have Claude fix anything that isn’t.

The Simplification Burst

Periodically—usually after 3-5 creation bursts—I shift to simplification mode:

• “Review all the tests in this module. Are any redundant?”
• “Find opportunities to consolidate these similar functions.”
• “Are there any obvious refactoring opportunities?”
• “Review all the lint and stryker disable comments - are they all legit or were you just cheating to pass the gates?”

This is where Claude earns its keep. It can see patterns across files that I’d miss. It can identify tests that are essentially duplicates with different inputs. It can suggest abstractions I didn’t notice.

Even better: use the Codex agent as a second opinion. Claude reviews the code, then consults Codex for an independent assessment. Two models with different training and different blindspots catches things either one alone would miss. It’s like pair programming, except both programmers are AI and they actually disagree productively.

The rhythm is like breathing:

• Inhale: Add features, accumulate complexity
• Exhale: Simplify, reduce, consolidate

You need both. All creation leads to unmaintainable chaos. All simplification leads to stagnation. The rhythm keeps the codebase healthy.

Parallel Sessions: The DJ Approach

I typically run 2-3 Claude Code sessions simultaneously, like a DJ working multiple turntables. Each session handles a different concern:

Session 1: The main feature work

Session 2: A blocking issue discovered during feature work

Session 3: Documentation or test improvements

Why not one session handling everything? Context pollution.

When you’re deep in implementing a database migration and discover a bug in the auth system, context switching is expensive. Your current session has all the migration context loaded. Starting an auth investigation means either losing that context or polluting the session with unrelated information.

Parallel sessions give you isolation. Each session maintains focus. When the auth fix is done, that session closes cleanly while the migration session continues unaware.

You can use /resume¹ to switch back to an older session and pick up where you left off—the context is preserved. But finding old sessions is surprisingly hard. The /rename command helps (give your sessions meaningful names!), but I still lose track of which session had the context I need. Parallel sessions in separate terminal tabs, actively running, are easier to manage than a graveyard of suspended sessions you’ll never find again. Use git worktrees if you want to develop superpowers.

When to Split

Split into a new session when:

• You discover an unrelated issue that needs immediate attention
• You want to explore an approach without affecting current work
• You’re context-switching to a different area of the codebase

When to Stay

Stay in the current session when:

• The new task is directly related to current work
• You need context from the current session for the new task
• The task is small enough to not pollute context significantly

It’s also fine to let a session compact² between related tasks. You’ve finished the primary file edits but still need to finalize tests? Stay in the session. Completed the server-side API and now need the client-side? Same session. The compacted summary retains enough context for closely related work—you don’t need to start fresh for every sub-task.

Session Hygiene

• Name your terminal tabs so you know which session is which
• Use plan mode to understand state before diving in
• Close sessions cleanly when work is done (don’t let them linger)
• Don’t share sessions across days—start fresh

Practical Tips & Gotchas

After months of daily use, here are the lessons that stuck:

Always Start in Plan Mode

The global settings set defaultMode: "plan" for a reason. Before Claude does anything, it should understand what it’s working with. Read first, act second. This reinforces the OODA principles from Part 1: Observe and Orient before you Decide and Act.

When you skip plan mode, you get:

• Edits that technically work but miss the architectural context—Claude sees the tree but not the forest
• Assumptions that don’t match reality
• Confident implementations of the wrong thing

The quality gates will generally catch these issues—but at the cost of time and, worse, precious orchestrator context tokens. Better to spend a few thousand tokens on planning than tens of thousands on fixing.

Read Before You Edit

This seems obvious, but Claude (like any eager junior developer) will sometimes try to edit files it hasn’t read. The orchestrator pattern helps—the planning phase forces reading—but stay vigilant.

If you see Claude proposing changes to a file without first having read it, stop. Make it read the file. The 30 seconds this costs prevents 30 minutes of gate failures and retries/corrections later, along with all the wasted context from failed attempts polluting the orchestrator’s limited memory.

Use TodoWrite Religiously

The TodoWrite tool tracks tasks visibly and persistently. Encourage Claude to use it:

• At the start of complex work, to plan steps
• During work, to mark progress
• At the end, to verify nothing was missed

It’s tempting to skip this overhead. Don’t. The forced structure catches dropped tasks and provides a record of what happened.

Don’t Let AI Create “Helpful” Documentation

Left to its own devices, Claude will create README files, add excessive comments, and generate documentation you didn’t ask for. This is rarely helpful and often wrong.

There’s a deeper problem: because Claude cranks out code, features, and refactors so rapidly, out-of-band documentation gets stale fast. Within days, sometimes hours. And if that documentation is scattered across dozens of files, it becomes chaff—Claude reads a few docs, finds partial information, assumes it has enough context, and stops looking. The more “helpful” documentation exists, the harder it is for Claude to find what actually matters.

I learned to be explicit about this: “Don’t create documentation unless I ask.” It took a few stale ARCHITECTURE-REVISED-NEW-VERSION.mds to make that stick.

Symbol-Based Edits When Possible

When LSP is working (see Part 2 for caveats) or if you have installed something like Serena , prefer symbol-based operations:

• “Rename this function” (not “find and replace this string”)
• “Find all usages of this type” (not “grep for this name”)

Symbol operations understand code structure. Text operations understand strings. The former is usually what you want.

Let Watchers Run

If you’re using the tmux plugin with watcher integration:

• tsc-watch for TypeScript compilation
• test-watch for continuous testing

Never close these windows. They’re your feedback loop. The quality-guardian agent monitors them. You benefit from instant error detection and incremental re-compiles/re-tests.

Closing a watcher to “clean up” is false economy. You lose immediate feedback and have to re-run full builds to catch issues. Tmux windows will even persist across Claude Code sessions if you don’t kill them.

The “Three Attempts” Rule

When Claude fails at a task three times, stop. The problem isn’t Claude’s capability—it’s context or approach.

Ask:

• “What files do you think are relevant here?”
• “What assumptions are you making?”
• “What alternative approaches could we try?”

Usually one of these questions reveals the misunderstanding. Then you can correct course instead of watching Claude fail the same way repeatedly.

Tell Claude to Ask You

Always tell Claude to ask if it has any doubts, or if there are multiple valid approaches. “If you’re unsure about anything, or if there are tradeoffs I should weigh in on, ask me before proceeding.”

Claude Code has a built-in AskUserQuestion tool that presents options with descriptions and collects your choice. When Claude uses it well, you get a clear summary of the tradeoffs and can make an informed decision in seconds. Much better than Claude guessing wrong and you discovering it three iterations later.

Even better: tell Claude to consult Codex first when it hits a decision point. “If there are multiple approaches, consult Codex, synthesize both perspectives, then present me with the options, their pros and cons, and use AskUserQuestion to get my input.” Now you’re getting two AI opinions synthesized before you make the call. It’s like a mini standup: the lead developer, a peer reviewer, and the product owner huddling on a decision. Team input beats solo guessing every time.

You wouldn’t tell a junior developer “figure it out yourself, don’t bother me with questions.” You’d say “if you hit a decision point where you’re not sure, come ask—I’d rather spend 30 seconds now than debug your guess for an hour later.” Same principle, different employee.

Encouraging questions costs almost nothing and prevents expensive mistakes. The orchestrator’s job is to make decisions; let it make them when they matter.

The Meta-Lesson

What months of this workflow have taught me:

More automation requires more rigor.

This sounds paradoxical. Shouldn’t AI reduce the need for discipline? Make everything easier?

No. Easy access to power makes discipline more important, not less. A hand tool can only do so much damage. A power tool wielded carelessly can ruin everything.

Claude Code is a power tool. Configured well, with appropriate enforcement, it’s transformative. Configured poorly, or used without discipline, it generates plausible-looking code that accumulates technical debt faster than you can pay it down.

The configuration in this series—the smart wrappers, the orchestrator philosophy, the hooks and gates and specialized agents—isn’t overhead. It’s insurance. It’s what lets you use the power safely.

The Series Conclusion

Over three posts, we’ve covered:

Part 1: The Foundation

• Smart wrapper scripts with auto-detection
• The orchestrator-only philosophy
• Mixin system for per-project customization
• Global safety settings

Part 2: The Enforcers

• Hook-based enforcement preventing bad patterns
• Custom plugins: Codex, TypeScript, tmux
• LSP integration (and its limitations)
• Quality gates for verification

Part 3: The Workflow (this post)

• Three projects with different configurations
• The “bursts” rhythm of creating and simplifying
• Parallel sessions for isolation
• Practical tips from daily use

The through-line is thoughtful configuration serving specific needs. There’s no one-size-fits-all setup. But there are patterns that work, principles that hold, and discipline that pays off.

If you want to explore my actual configuration, check out my Claude Code config repository . If you want to see these patterns applied to a real project, explore Isambard .

Happy configuring. May your mutations be caught and your context never exhausted.