Karpathy-Style CLAUDE.md Self-Check Protocol for Loops
A self-check protocol embedded in CLAUDE.md that every loop iteration obeys before ending a turn: re-read the goal, diff the changes against it, run the verification command, and state what remains — a ritual that catches drift between iterations.
Implementation note
When to use: loops that drift — iterations that wander off-goal, declare premature success, or lose track of remaining work — where you want a correcting ritual applied every single turn without re-prompting. How it works: preamble rules embedded in CLAUDE.md that every loop iteration obeys before ending a turn: re-read the goal, diff your changes against it, run the verification command, and explicitly state what remains. Because CLAUDE.md is loaded every session, the ritual survives fresh-context iterations for free — drift correction as standing configuration rather than per-run prompting. Safety: the run-the-verification-command step keeps self-assessment anchored to an objective check instead of the model's optimism. One attribution caution from the source: this is a community template descended from Karpathy's circulated CLAUDE.md rules, reported by a secondary source — verify the exact current rule text against the upstream repo before quoting or republishing specific rules. Hardened 2026-07-27: explicit stop/cap/verification guardrails appended; regraded D→A.
Source: Tech Times ↗graded A · 95/100 — how grades work →
More quality loops
Clean up the slop
Review your recent diff for debug code, dead branches, and bad names, then fix with minimal edits until lint and tests pass.
Repair accessibility, highest-impact first
Confirm barriers against an agreed standard, fix the one with the greatest user impact, and rerun the same checks.
Fifteen-minute verification report while you work
A recurring six-phase check (build, types, lint, tests with coverage, secret and debug-log grep, diff size) that prints one fixed-format report every fifteen minutes so you catch drift before the PR, not in review. It is strictly read-only: the loop reports, you decide what to fix. It exits when the tests pass and the report reads READY twice running, escalates instead of retrying when the same check fails three times, and stops after eight checks no matter what. Adapted from ECC's verification-loop skill (affaan-m/ECC, MIT), whose 'continuous mode' names the cadence but has no turn cap, exit, or failure path; all three are added here.