CC-301a · Module 3

Rule Discovery from Errors

3 min read

Every recurring mistake is a rule waiting to be written. The error-to-rule pipeline is the most reliable method for building a high-quality CLAUDE.md, because it is driven entirely by observed failures rather than speculative anticipation. You do not guess what rules you need. You wait for Claude to make a mistake, fix it manually, and then encode the correction as a rule so it never happens again.

The process is mechanical. Claude generates code that imports from the wrong path. You correct it. You add a rule: "Always import shared types from src/types/index.ts, not from individual component files." Claude generates a component with inline styles instead of Tailwind classes. You correct it. You add a rule: "Never use inline styles. Always use Tailwind utility classes." Each correction is a data point. Each rule is a permanent fix.

The discipline is in the word "recurring." A single mistake does not justify a rule. One-off errors are noise — they happen because of context limitations, unusual prompts, or edge cases that are not worth codifying. But the second time Claude makes the same mistake, it is a pattern. And patterns demand rules.

The pipeline has three stages. Stage one: detect the error during code review or testing. Stage two: fix the error manually and note the correct behavior. Stage three: tell Claude to add a rule to CLAUDE.md that prevents this specific error. Do not write the rule yourself — let Claude write it, because Claude will phrase the rule in a way that Claude can follow. Your job is to approve or refine the phrasing, not to author it.