Yesterday I wrote about /goal and /loop, the two Claude Code commands that make bounded autonomy practical. A goal as a stopping condition, a loop as a return mechanism, and a cheap model to verify reality between iterations.
Today I want to talk about another one: /code-review.
On the surface, it is simple. You run /code-review in a Claude Code session and the agent reads through your changes and tells you what looks wrong. Edge cases, error handling, missing tests, inconsistent naming.
But the reason this matters is not the feature itself. The reason is that it is a deliberate framing shift.
From "generate" to "critique"
Most of what we do with LLMs in development is generative. Write this function. Draft this PR description. Rewrite this test. Generate first, fix later.
But generation has blind spots. The model that wrote the code is the same model reviewing it. It tends to like its own work. It misses the same patterns it just created.
The traditional solution is: have a different human review it. Or a linter. Or a CI pipeline that runs tests. All of these are good, but they are slow. They create latency. The feedback loop is measured in hours, not seconds.
/code-review collapses that. In the same session, the same model, but with a different instruction: do not write, critique.
I had a custom skill for this before
And it worked. Mostly. But it was one of those skills I built early on, before I understood the patterns well. It ran a few static checks, sprinkled some prompts, and called it a day.
The new version I have been testing does something different. Instead of asking the model to review everything at once, it:
- Looks at each file individually for structural issues (dead code, unused imports, missing error paths)
- Then looks at the diff as a whole for logical gaps (missing edge cases, inconsistent behavior across files)
- Then assigns severity levels — not just "fix this" but "fix this now" vs "fix this when you touch it next"
That structure makes a difference. A flat list of 30 issues is noise. A prioritized list of 5 real problems is useful.
It does burn tokens
I will not pretend this is free.
Running a strong model through a structured review pass for every meaningful change adds up. The code review itself, if done naively, can cost more than the generation that produced the code.
But there are two things that make the math work.
First, you do not need the strongest model for every review. A cheaper model can catch 80% of problems — missing imports, inconsistent naming, dead variables, missing null checks. The expensive model only comes in for the hard ones: architectural mismatches, security logic, decisions that require understanding intent.
Second, the model that wrote the code knows the context. You do not need to re-explain the project, the conventions, the constraints. The review step is just a reframing of what is already loaded. That saves a massive amount of tokens compared to asking a separate model or a separate session.
Pattern: the critic is a separate persona, not a separate agent
This is the part I find most interesting.
I have tried putting code review in a separate agent. Different model, different prompt, different session. The problem is context loss. The reviewer does not know what the generator was thinking, so it asks dumb questions. Why is this here? What was the intent? It becomes a conversation instead of a review.
The Claude Code approach solves this by making the critic a persona switch inside the same session. The same context, the same model, but with a different instruction: stop being the writer and start being the reviewer.
That is harder to replicate in an orchestration framework like OpenClaw because the context lives inside the session. But it is also a reason to think about sessions differently. Not as ephemeral work units, but as persistent environments where different agents with different roles can operate on the same context.
I am not there yet. But the pattern is clear.
What this means for the architecture
If /code-review is a real improvement and not just a Claude Code gimmick, then the implications are:
- Code review should happen in the same session as generation, not in a separate pipeline
- The review should be structured, not freeform: file-level first, then diff-level, then prioritization
- Cheap models first — escalate to strong models only when the cheap ones find ambiguity
- Separate roles, shared context — the writer and the critic share memory but not the same instructions
None of this is revolutionary. It is just a better arrangement of the same parts.
And that is the thing I keep noticing about these Claude Code commands. They are not magic. They are good architecture wrapped in a two-word command.
Recognizing the architecture behind the shortcut is worth more than the shortcut itself.