When I started using Claude Code more seriously, I quickly noticed that a good AI can get you far. It can read code, suggest solutions, write tests and keep quite a bit of context in the same process. But in some situations I do not want a generalist. I want someone who only thinks about security. Or someone who reads the code like a senior reviewer. Or why not two models arguing with each other before I decide how to solve the problem?
That is where Claude Norns started.
Norns is a small plugin with an orchestrator setup for Claude Code that lets me call in 26 different expert personas when I need them. Claude Code is still the arena, but behind the commands there are specialized roles and several AI tools that can work together.
Codex can run a code review. Gemini can be used for quick research at low token cost. Claude can act as a senior architect with an overview of what is happening.
The point is not to replace my judgment. It is to make it easier to get the right kind of resistance at the right moment.
From one broad agent to the right perspective
The simplest way to use Claude Norns is /quick.
I can write something like:
/quick review src/api/auth.tsor:
/quick security the login formand let the system route the question to the right persona. There are roles for code review, security, performance, debugging, architecture, frontend, backend, database, Drupal, Liquid, TypeScript, Python and quite a bit more.
That may sound like yet another list of agents, but for me the important part is not the number. The important question is: will they actually get used, and how easy is it to call them? If I need to write a long prompt to get a good security review every time, I will unfortunately not use it every time. If a short command is enough, it becomes a natural part of my workflow.
It is the same reason I built Norns Companion for tmux sessions. When something requires too much context switching, it happens less often than it should. Norns Companion keeps track of where my agents are while I work. Claude Norns is more about which kind of agent I want to call in at which moment.
When I want models to disagree
The part I find most interesting to tune is not the single-persona commands, but the workflows in /debate and /security-audit.
With /debate, two models can propose separate solutions, critique each other and then summarize a shared recommendation.
That is useful when I am facing a choice without an obvious answer:
/debate REST vs GraphQL for this customer APIor:
/debate should this feature live in the CMS or in the app layer?I do not want the models to simply confirm the first idea that sounds reasonable. I want them to find what I am missing and push my own thinking forward. A debate between two models is not magic, but it makes it harder for a bad assumption to take up space just because it sounded plausible in the first answer.
This is especially useful for architecture decisions. Not because AI should make the decision for me, but because I get to see the arguments develop from several directions before I land on something sustainable myself.
Security audit as blue and red side
/security-audit is built on the same idea, but with more structure.
First there is a blue side that tries to reason toward a secure solution.
Then there is a red side that tries to find weaknesses in the blue side's solution.
After that comes recommendation and validation.
This is the kind of workflow where a normal prompt can easily become too polite. If I ask an agent to "check whether the auth flow is secure", I sometimes get an expected and reasonable answer, but it can still read like a checklist. When I explicitly split the work into defense, attack and fix, I usually experience the result as more stable. Where is the attack surface? Which assumption does the solution depend on? What happens if the user manipulates the input? Which steps can actually be tested?
This does not mean I am replacing real human review. But for everyday development, it is a good extra layer to have close at hand. Especially in projects where I otherwise might have settled for thinking "that probably looks okay".
What disappeared: Double Diamond
An earlier version of Claude Norns was built more around Double Diamond: first explore, then narrow down, then develop, then deliver. On paper, it looked neat. In practice, it was far too many steps for the kind of work I do day to day.
I do not always need a full design process. Sometimes I just need a good reviewer. Sometimes I need a security reviewer. Sometimes I need two models to argue about a solution for a while.
So I slimmed the tool down. Old phase commands and quite a bit of dead code disappeared, and the solution became smaller. That is a fairly important lesson for me when building agent tools in general: more steps do not automatically make the system smarter. A workflow has to be light enough that I actually use it while I am in the middle of the work. Otherwise I might as well throw it away.
Why not just use prompts?
Of course, a lot of this can be done with normal prompts. I can ask Claude to act as a security reviewer. I can ask Codex to review a diff. I can open Gemini separately and ask for research.
But then I have to keep the setup together myself every time. Which model fits? Which persona should be used? How should file references be passed along? Should it be read-only? How should the result be compared?
With Claude Norns, I am trying to package those steps so they become part of the workflow instead of another small planning task that breaks my flow. It is not a replacement for thinking, it is a way to make it easier to think and see more perspectives.
What I want to test more
The next step is collecting better examples from daily use of the tool.
I want screenshots that show the difference between a normal prompt and a more directed persona.
I also want to test /debate on a few architecture choices where I already have a gut feeling, to see if the models find something I overlook.
I have chosen not to use the estimate skill as the main example here. It matters to me, but it is also very specific to how I work with quotes and upgrades. Claude Norns is easier to understand through broader examples: review, security, debugging and architecture.
There is also a practical question around publishing. The tool exists locally for me and in the GitHub repo, but before I point people there I want to make sure installation, provider detection and documentation feel reasonably stable. An article about the tool quickly becomes a kind of promise. I want that promise to be modest.
Experts, not autopilot
What I like most about Claude Norns is that it does not try to take over the entire workflow. It is not built so I can press a button and burn tokens to the max. It is built for those small decisions during the day where an extra perspective can make a big difference for me.
A security-auditor that only thinks about attack surfaces. A reviewer that only looks for regressions. A performance persona that does not care if the solution is elegant if it becomes slow. A debate where two models have to explain why their own solution is better.
That is how I want to use AI in development right now. Not as a replacement for responsibility, but as a way to get more sharp angles on the same problem.
And when it works, it feels less like I have started up a bigger autopilot. It feels more like I have experts close at hand, experts that support me in my work.
