019ee5f7-ef5c-7a10-bb29-a5094a6c5939 post Testing this self-improvement rule for my Claude Code setup: Stefan Wintermeyer wintermeyer https://vutuv.de/wintermeyer https://vutuv.de/wintermeyer/posts/019ee5f7-ef5c-7a10-bb29-a5094a6c5939 https://vutuv.de/wintermeyer/posts/019ee5f7-ef5c-7a10-bb29-a5094a6c5939.json https://vutuv.de/wintermeyer/posts/019ee5f7-ef5c-7a10-bb29-a5094a6c5939.txt https://vutuv.de/wintermeyer/posts/019ee5f7-ef5c-7a10-bb29-a5094a6c5939.md https://vutuv.de/wintermeyer/posts/019ee5f7-ef5c-7a10-bb29-a5094a6c5939.xml ClaudeCode Agents 2026-07-08T21:28:13Z 3 2026-06-20 0 1 0 0 Testing this self-improvement rule for my Claude Code setup: > - Treat every mistake as a trigger to improve the rules, so they self-improve over time. Whenever you get something wrong (caught by me, by a failing test, by CI, by a linter or formatter, or noticed yourself), don't just fix the one instance. Ask what rule, had it existed, would have prevented it, then add or sharpen that rule so the same or a very similar mistake can't recur. Put it at the right scope: project-specific lessons go in that project's `CLAUDE.md` or `.claude/rules/`, general lessons go here in my global `CLAUDE.md`, and durable per-project facts can also go to memory. Write each new rule as a concrete instruction that says what to do and why, not a vague reminder, and fold it into an existing bullet when one already covers the area instead of duplicating. Keep the signal high: only codify mistakes that are generalizable and likely to recur, and skip one-off slips or things already covered elsewhere. In the same turn that you fix the mistake, tell me which rule you added or changed and why.