← Item page

Claude Code self-improving loop

Rody’s X Article describes a practical three-file pattern for making Claude Code verify its own work: project instructions, Claude hooks, and a dedicated fixer subagent. The useful idea is not “more prompting”; it is turning “done” into a test-backed stop condition.

Source: X Article by @0x_rody / rody Post: 2026-06-10 Type: Claude Code workflow Public signal at fetch: 535 likes · 1,582 bookmarks · 210k impressions

Source URL: https://x.com/0x_rody/status/2064728139314389073

Executive read

Takeaway: worth adopting selectively for Dab→Claude Code execution loops, especially repo work where tests/type checks are cheap. The pattern matches our existing rule: “not done until verified with real output.”

Best fit: project-specific Claude Code jobs where a fast unit/type check exists. Bad fit: long integration suites, flaky external calls, or tasks where repeated hooks could burn tokens without new evidence.

The loop in one diagram

1. WriteClaude edits code for the requested task.

2. CheckHooks run tests/type checks at edit/stop points.

3. Read failureFailure output is fed back into the same session.

4. Fix causeClaude fixes the root issue, not the symptom.

5. Stop only on proofReport passing output, or stop after a retry/same-error limit.

What the article proposes

File 1 — `CLAUDE.md` loop protocol

Defines “done” as verified, not merely written. It tells Claude to run checks, retry up to a limit, stop when the same error repeats, and never weaken tests to make the scoreboard green.

File 2 — `.claude/settings.json` hooks

Uses Claude Code hooks: PostToolUse after edits for fast type feedback, and Stop when Claude tries to finish for a final test gate.

File 3 — `.claude/agents/fixer.md`

Adds a separate “fixer” subagent for stubborn failures. The article’s version emphasizes reproducing the failure, reading the full path, writing a one-sentence cause, and fixing only that cause.

Core snippets from the source

Hook shape

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npm test --silent 2>&1 | tail -20" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "npx tsc --noEmit --pretty false 2>&1 | head -10" }
        ]
      }
    ]
  }
}

Loop protocol essence

1. Write the change.
2. Run checks: tests, linter, type checker.
3. If anything fails, read the error, fix the cause, go back to step 2.
4. Repeat up to 5 times.

Stop when:
- All checks pass, with output as proof.
- 5 attempts are used.
- The same error appears twice in a row.

Never report done without check output.
Never fix a test by weakening it.

How this maps to Mission Control / Dab

Need	Application	Caveat
Dab as verifier, Claude as executor	Use hooks to make Claude produce stronger evidence before Dab’s independent verification pass.	Dab should still inspect diffs and run the final flow independently. Hooks are not a substitute for review.
Reduce messenger work	For normal repo tasks, Claude can see failing test/type output without Ananth or Dab pasting it back.	Commands must be short and bounded, or the loop becomes expensive/noisy.
Notice Board / Hermes repo changes	Project-specific hooks could run `python3 tools/notice.py validate`, `python3 -m py_compile render.py mc_pages.py`, or targeted tests.	Do not put destructive commands or network deploys in automatic hooks.
Subagent recovery	A “fixer” agent aligns with our recovery pattern when Claude Code hits max turns or repeats the same error.	The fixer needs strict scope: reproduce, diagnose, patch only the cause, return before/after output.

Recommended adaptation for Ananth’s repos

Keep the rule in project instructions: “Done means checked in this session with command output.” This already matches Dab’s operating standard.
Add hooks only per repo, not globally at first. Start with one repo that has cheap checks and low flake rate.
Use bounded commands. Prefer pytest -q, npm test -- --runInBand, tsc --noEmit, ruff check, or a targeted script. Avoid broad deploy/build commands unless explicitly scoped.
Cap retries and stop on repeated errors. This prevents token/time spirals.
Protect tests. The model should not loosen assertions, skip tests, or delete coverage unless the task explicitly asks for test migration and the reviewer accepts it.

Pitfalls / watch-outs

Hook output can be too small. tail -20 is convenient, but sometimes hides the actual stack trace. For hard failures, have the fixer rerun the full command.
Automatic hooks can create false confidence. Passing a narrow unit check does not verify product behavior, UI, auth, migrations, or deployment.
Claude may optimize for hook success. Keep explicit anti-cheat rules: do not skip tests, weaken assertions, or replace real checks with no-ops.
Long suites are a tax. If the check takes 90+ seconds, use targeted tests in the loop and leave the full suite for final verification/CI.
This is Claude Code-specific. The idea generalizes to Codex/OpenCode, but the exact hooks/subagent files do not.

Decision

Treat this as a useful Dab Improvements pattern: not a new product idea, but a reusable execution quality guard. If adopted, make it a per-repo template with safe check commands and a bounded fixer subagent.