The problem wasn't that my rules were bad. The problem was I had no idea if they were being followed.
I had 15 rules for my AI assistant. "Think before acting." "Check context before asking." "Capture learning after complex tasks." Good rules. Important rules.
After 30 sessions, I finally checked: my "think before acting" rule had been followed exactly zero times.
Not because the AI was ignoring it. Because the rule was a wish — not a verifiable constraint. It had no teeth.
Test-Driven Development taught us a hard lesson: requirements without assertions aren't requirements. A test that always passes is useless. But a requirement without a test is just a wish.
Every software team learned this. CI pipelines enforce it. Linters check it. But AI configuration rules? We write them like sticky notes on a monitor — good intentions with no verification mechanism.
I realized my rules were all wishes. Every single one.
Here's the before and after:
Think before acting on any request.
Think before acting → mark [✓THINK] when done.
That [✓THINK]
isn't decoration. It does two things simultaneously:
grep -c '\[✓THINK\]' transcript.jsonl
becomes a health metric. No AI required.The marker is the assertion. The grep is the test runner. And the rule text itself is the specification — self-contained, self-verifying.
The whole system boils down to three lines of logic:
Rule text → contains its own success criteria ([✓MARKER])
Transcript → machine-readable evidence (regex-countable)
Health script → mechanical verification (no AI inference)
I wrote config-health.py
— 350 lines of Python, zero dependencies, stdlib only. It runs as a Claude Code Stop hook. Every session, it:
[✓THINK]
, [✓CONTEXT]
, [✓DELIVERY]
)pending-verifications.md
file — rules that haven't been followed show up as pending itemsThe script never blocks. It only reports. Exit code 0, always. But the data it produces changes behavior — because I read pending-verifications.md on next startup.
After deploying this: my rule execution rate went from "I have no idea" to tracked visibility across every session. I still miss rules sometimes. But now I know when I miss them. The dashboard surfaces exactly which rules need attention.
The surprising part: the markers themselves changed how the AI behaves. [✓THINK]
is a concrete action — not a vague "consider the problem," but a specific thing to output. The AI hits it more often because it's clearer what "done" looks like.
Any rule without an embedded success criterion is a wish. Wishes don't execute.
This applies beyond AI config. Your team's code review checklist? If "check for security issues" doesn't have a verifiable step, it's not happening. Your personal productivity system? If "review weekly goals" isn't measurable, you're not reviewing them.
Verifiability isn't about distrust. It's about closing the loop between intention and evidence.
Pick one rule in your AI config. Add a verification marker. Write 5 lines of grep to count it:
grep -c '\[✓YOUR_MARKER\]' ~/.claude/transcripts/*.jsonl
You'll learn more from that grep output than from 10 new rules you never verify.
The config-health.py script is part of delivery-gate — a dual-layer mechanical gate for Claude Code. MIT licensed. The methodology behind it lives at checkgrow.