Claude Code is the fastest coder I've ever worked with. You can develop a feature, write tests, and open a PR in minutes. But I kept running into the same problem: the code worked and then it didn't.
A race condition in a status transition. An encoded string that should have been a constant. A transaction that rolled back an audit record that was supposed to be preserved. Evidence that claimed to be true
instead of asserting the correct value.
The solutions were also always quick. But each solution came with a secondary mission: the incident, the regression, the "why don't we get this?" retro The speed was high. The net speed, after accounting for errors, was not.
And even with a decent CLAUDE.md
, I continued to babysit children in each session. Please don't forget TDD this time. Hey, you forgot to check Bug Bot. Can you actually run the tests before opening the PR? Every message felt like a conversation with someone extremely talented who also had the short-term memory of a goldfish. The problem was not Claude's ability. It was that good habits written somewhere in a markdown file do not automatically become practiced habits. I was the process. Which meant the process was inconsistent, forgetful, and increasingly annoyed with itself.
So I tried something different. Instead of arranging Claude's departure, I changed the way Claude thinks.
The problem is not intelligence. It's a process.
Watch how a junior developer works: read the ticket, open the file, and start typing. They are fast. They are also the ones who forget to check if the method they are calling actually exists or if the database column they are referencing was renamed three weeks ago. (The name was changed three weeks ago. It's always three weeks ago.)
Now watch a senior developer: he reads the ticket, reads the code around it, reads the tests, checks the git history, and then starts writing. They are slower to start but faster to finish, because they don't have to go back and fix what they broke.
Claude Code defaults to junior mode. Not because he lacks knowledge, but because he lacks process. You don't have an internal checklist telling you to check assumptions, write tests first, or think about what happens when two requests hit the same endpoint at the same time. He is enthusiastic. It is sent. And it turns out that enthusiasm doesn't catch nullable datetime bugs.
I built that checklist.
Presenting/assistant
/assistant
is a Claude Code skill, a markdown file that resides in your project and is activated when you type /wizard
in the CLI. Transform Claude from a fast coder to a methodical software architect. Think of it as the senior engineer looking over Claude's shoulder, except Claude never asks him if he's tried turning it off and on again.
It's an 8-phase methodology and works best with some things already in place: CLAUDE.md
define your project conventions, a GitHub issue created before work begins (/wizard
can help you write one), a real commit to TDD and a clean feature branch per task. For CI, I use GitHub Actions, but skill doesn't care. You just need something to respond to in Phase 8. More on that shortly.
This is how the 8 phases work.
Phase 1: Plan before touching anything
Claude reads your CLAUDE.md
, find the linked GitHub issue and create a structured to-do list before writing a single line of code. Evaluate complexity: how many files are likely to be affected, whether there is architectural impact, and how much could go wrong. Then size the job accordingly.
This sounds obvious. It's obvious. It's also the step most often skipped when you're in a hurry, which is exactly when you need it most. It's funny how that works.
Phase 2: Explore before assuming
With a plan in motion, Claude explores the actual code base. Look for each model, method, relationship and constant you intend to use and verify.
