{"slug": "i-made-my-ai-rules-self-verifiable-here-s-how", "title": "I Made My AI Rules Self-Verifiable — Here's How", "summary": "A developer created a self-verifying rule system for AI assistants after discovering that 15 rules for an AI assistant were followed zero times in 30 sessions. The system uses embedded markers like [✓THINK] in rule text, which can be counted via grep on transcripts, turning vague requirements into verifiable constraints. A 350-line Python script, config-health.py, runs as a Claude Code Stop hook to track rule compliance and surfaces pending verifications in a file read on next startup.", "body_md": "**The problem wasn't that my rules were bad. The problem was I had no idea if they were being followed.**\n\nI had 15 rules for my AI assistant. \"Think before acting.\" \"Check context before asking.\" \"Capture learning after complex tasks.\" Good rules. Important rules.\n\nAfter 30 sessions, I finally checked: my \"think before acting\" rule had been followed exactly **zero times**.\n\nNot because the AI was ignoring it. Because the rule was a wish — not a verifiable constraint. It had no teeth.\n\nTest-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.\n\nEvery 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.\n\nI realized my rules were all wishes. Every single one.\n\nHere's the before and after:\n\n```\n# Before (wish):\nThink before acting on any request.\n\n# After (verifiable):\nThink before acting → mark [✓THINK] when done.\n```\n\nThat `[✓THINK]`\n\nisn't decoration. It does two things simultaneously:\n\n`grep -c '\\[✓THINK\\]' transcript.jsonl`\n\nbecomes 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.\n\nThe whole system boils down to three lines of logic:\n\n```\nRule text     → contains its own success criteria ([✓MARKER])\nTranscript    → machine-readable evidence (regex-countable)\nHealth script → mechanical verification (no AI inference)\n```\n\nI wrote `config-health.py`\n\n— 350 lines of Python, zero dependencies, stdlib only. It runs as a Claude Code Stop hook. Every session, it:\n\n`[✓THINK]`\n\n, `[✓CONTEXT]`\n\n, `[✓DELIVERY]`\n\n)`pending-verifications.md`\n\nfile — 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.\n\nAfter 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.\n\nThe surprising part: the markers themselves changed how the AI behaves. `[✓THINK]`\n\nis 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.\n\nAny rule without an embedded success criterion is a wish. Wishes don't execute.\n\nThis 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.\n\nVerifiability isn't about distrust. It's about closing the loop between intention and evidence.\n\nPick one rule in your AI config. Add a verification marker. Write 5 lines of grep to count it:\n\n```\ngrep -c '\\[✓YOUR_MARKER\\]' ~/.claude/transcripts/*.jsonl\n```\n\nYou'll learn more from that grep output than from 10 new rules you never verify.\n\n*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.*", "url": "https://wpnews.pro/news/i-made-my-ai-rules-self-verifiable-here-s-how", "canonical_source": "https://dev.to/yuhaolin2005/i-made-my-ai-rules-self-verifiable-heres-how-19ea", "published_at": "2026-06-30 17:44:20+00:00", "updated_at": "2026-06-30 17:48:54.764835+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents"], "entities": ["Claude Code", "Python", "config-health.py", "delivery-gate", "checkgrow"], "alternates": {"html": "https://wpnews.pro/news/i-made-my-ai-rules-self-verifiable-here-s-how", "markdown": "https://wpnews.pro/news/i-made-my-ai-rules-self-verifiable-here-s-how.md", "text": "https://wpnews.pro/news/i-made-my-ai-rules-self-verifiable-here-s-how.txt", "jsonld": "https://wpnews.pro/news/i-made-my-ai-rules-self-verifiable-here-s-how.jsonld"}}