Another confession
In the last post, I went after the bug that every Claude Code discipline plugin seems to share: the rules live in the main session, the work happens in the workers (subagents), and the rules don't make the trip across. I named names. I quoted the maintainer of superpowers closing a related issue as "not planned." And then, with a straight face, I claimed that sonmat was different.
It really wasn't. Not yet, anyway.
For a while, sonmat had this nicely-crafted hook. Every time you opened Claude Code, it would shove 1,239 characters of discipline into additionalContext before you even said hello. "MANDATORY. Apply Break it / Cross it / Ground it. Read project memory. Watch for novel traps…" Every session, every time, before the model got a word in.
I thought this was the strong play. The hook fires before the model speaks, the instruction lands in additionalContext, the discipline can't be skipped. That was the theory.
What I didn't notice — for embarrassingly long — was that I was rebuilding, with my own hands, the exact bug I'd just spent a whole post laughing at.
How I figured it out
Here's the awkward bit: additionalContext is delivered to the main session. It is not delivered to subagents.
So picture what was actually happening. The discipline lived in the place I could see (the main session). It was completely absent from the place where the work actually got done (the workers). The main session would dutifully announce "applying Break / Cross / Ground" — and then dispatch a worker. The worker would receive a clean task with a clean context. No discipline. The worker would shrug and go, "this is simple enough, I don't need tests." The result would come back, the main session would format it confidently (still holding all 1,239 characters of rules), and I'd nod along and approve.
It was not fine.
Which is to say: the exact failure mode I'd been mocking in superpowers and karpathy-skills? Same mechanism, different label, mine.
Honestly, I only caught it kind of by accident. I'd started spinning up other CLIs for the same kind of work, and something in the output felt off. So I went poking around. Turns out, every CLI handles hooks slightly differently — different contracts, different injection points, sometimes none at all. And while I was wrestling with making the discipline survive outside Claude Code, the thing that should have been obvious inside Claude Code finally clicked: a hook that lands in one place but not another isn't a guarantee. It's a happy accident that landed in the main session.
The bug wasn't multi-CLI. The bug was that I'd been calling that happy accident a guardrail.
What changed in v0.4.0
I emptied the hook. additionalContext: 1,239 → 0.
The discipline didn't disappear — it just moved. It now lives in CLAUDE.md → discipline/core.md, the same file the agent already reads as part of its prompt context, and the same file you'd put any other instruction in. Workers spawned by the main agent inherit the same CLAUDE.md chain. So the rule lands in the same place, every layer.
The hook still runs. It just sticks to what hooks are good at. Make the .claude/sonmat/ directory. Plant a one-time ## sonmat block in your global CLAUDE.md so the discipline gets referenced. Check for updates. Side effects only. It doesn't try to shape behavior anymore.
BEFORE AFTER
hooks/session-start hooks/session-start
└─ additionalContext: 1,239 chars └─ side effects only
"MANDATORY: sonmat..." ├─ create .claude/sonmat/
(delivered to main session ├─ plant ## sonmat block
only — workers never saw it) └─ git pull if outdated
CLAUDE.md → discipline/core.md
(read by main and by every
worker spawned from it.
visible to the user. editable.)
Same discipline, different path. The behavior didn't get weaker — it just got honest about where it actually lives.
Four things I believe now
1. A guardrail that doesn't reach the worker is a fake guardrail.
If your "mandatory" rule is being delivered through a channel the worker doesn't subscribe to, it isn't mandatory. It's decoration. And the trap is that you can see it sitting in the main session — which is exactly why you stop checking.
2. Visibility is the contract.
A rule sitting in additionalContext is invisible to the user. You can't read it, can't edit it, can't disagree with it. A rule sitting in CLAUDE.md → core.md is just there, in the repo. The agent reads it. You read it. You can disagree with it — and that's a good thing, because that's how drift gets caught before it ships.
3. Hooks are for side effects. They are not for behavior.
Make the directory, plant the marker, pull the update. That's the job. The moment a hook starts trying to shape what the agent does, you're betting that the hook fires in every code path the agent will ever take. It doesn't. It can't.
4. "Strong" enforcement is usually fragile enforcement.
The 1,239-character injection felt powerful because it was automatic. But automatic-and-incomplete is worse than manual-and-complete — the user trusts the automation and stops looking. Moving discipline into a file the user can edit (and ignore) sounds weaker. It isn't. It's where the user actually re-enters the loop.
The hard part
Honestly, emptying the hook felt like giving up control. The hook was the place where I could make sure. If discipline lives in CLAUDE.md, the user can edit it, override core.md, even ignore the whole thing.
Which, yes, is the entire point.
A discipline the user can't see is a discipline the user can't trust. A discipline the user can't edit is a rule, not a tool — and sonmat is supposed to be a tool. Visibility is the price of trust. And there's a bonus: the discipline now reaches the workers, because the workers read the same file the user reads.
Diagnose your own setup
If you're running any Claude Code plugin that promises "guardrails," try asking three questions:
-
Where does the rule physically live? A hook injecting
additionalContext? A skill the model has to remember to invoke? A line inCLAUDE.md? - Who actually reads it? Just the main session? Workers too? Subagents spawned from workers?
- Can you see it yourself? If you can't open a file and read the rule that's supposedly governing your agent, you don't have a guardrail. You have a vibe.
I had to put my own plugin through those three questions before the answer became obvious. Doing the diagnosis in 01 was the easy part. Applying it to sonmat itself took a lot longer.
Try it
/plugin marketplace add jun0-ds/sonmat
/plugin install sonmat@sonmat
After install, the discipline lives at ~/.claude/plugins/marketplaces/sonmat/discipline/core.md. Open it. Read it. Disagree with parts of it if you want — that's actually how you'll know it's doing something real.
Part of the series **Building sonmat. Previous: Your AI is confident. Your AI is wrong. You shipped it anyway.