I didn't set out to build a self-healing system. I just wanted to stop forgetting things. What emerged was a feedback loop that fixes itself without me.
After 40+ Claude Code sessions, I noticed a pattern: identify a problem → write a rule → forget about it → rediscover the same problem 5 sessions later → write the same rule again.
The rules folder was growing. But behavior wasn't changing.
Prometheus Alertmanager has a concept that changed how I think about systems: alert → acknowledge → fix → auto-resolve.
Without the "auto-resolve" step, alerts pile up. You get a graveyard of acknowledged-but-never-fixed issues. They're not "open" — they're dead. Nobody looks at them. Nobody fixes them. They just sit there, eroding trust in the entire monitoring system.
My AI config had the same problem. Problems were identified. Rules were written. But nothing tracked whether the rules were actually followed — or whether the problem was actually fixed.
The missing piece wasn't more rules. It was a closed loop.
Three files. That's all it took to close the loop:
config-health.py (Stop hook)
↓ counts markers, detects gaps
pending-verifications.md (persistent memory)
↓ surfaces unresolved items
BODY.md (startup rules, read every session)
↓ tells AI to focus on pending items
↓ AI follows the rule, produces markers
config-health.py (next Stop hook)
↓ detects markers → auto-deletes from pending
The circuit:
[✓THINK]
and [✓CONTEXT]
pending-verifications.md
— they persist across sessionspending-verifications.md
on startup — the AI sees "these rules need attention"I didn't design this loop. It emerged from three independent decisions:
Each decision solved an immediate problem. Together, they formed a complete circuit.
Here's the part I didn't expect: the loop runs without me.
I don't check dashboards. I don't review reports. I don't maintain a tracking spreadsheet. The system surfaces issues when they exist and silences them when they're fixed. My only job is to follow the rules when BODY.md tells me to.
Last week's session: BODY.md surfaced "THINK rule execution: 40% (target: >70%)." I paid extra attention. Hit [✓THINK]
12 times. Next session, pending-verifications.md was clean — config-health had auto-deleted the entry.
I didn't manually "close" anything. The loop closed itself.
Three properties that any self-healing loop needs:
pending-verifications.md
is a file on disk. It doesn't disappear when the AI's context window resets. Problems can't hide by waiting you out.
Closed loops don't require complex architecture. They require a measurement, a memory, and a re-check. Three files, if they form a complete circuit, are enough.
This is the same pattern that makes TDD work (write test → run test → fix → re-run). The same pattern that makes CI work (push → build → test → report). The same pattern that makes any feedback system work.
The insight isn't new. What's new is applying it to personal AI configuration — the rules and habits that govern how you work with AI assistants.
Take one rule in your AI config. Add these three pieces:
grep -c '\[✓YOUR_RULE\]' transcript.jsonl
That's your first closed loop. If you get the circuit right, it might start self-healing without you noticing.
The loop lives in delivery-gate (the mechanical layer) and checkgrow (the methodology layer). Both MIT licensed, both open to contributions.
This article is part of the Engineering Trustworthy AI Output series: