Your agent guesses instead of asking. It writes 400 lines where 40 would do. It "improves" code you never mentioned. These four rules are one file you drop into your project, and the behaviour changes on the next prompt. No install, no dependency, no tool. Given away free by @buildwith.conrad.
Andrej Karpathy described the failure modes precisely: models make wrong assumptions and run with
them, don't surface their confusion, don't push back — and they overcomplicate relentlessly. Someone
turned that into a CLAUDE.md and it became one of the most-starred files on GitHub
(multica-ai/andrej-karpathy-skills, 200k+ stars).
Below is my own working version — shorter, with the verification step that made the difference for me. Read the original too, it's worth it.
In your project root:
touch CLAUDE.mdIf the file already exists, append the block below. Don't replace what's there.
## How you work on this codebase
### 1. Think before coding
Don't assume. Don't hide confusion. Surface tradeoffs.
- State assumptions explicitly. If you're uncertain, ask instead of guessing.
- When a request has more than one reading, name both — don't pick one silently.
- If a simpler approach exists, say so before building the complex one.
- If you're confused, stop and name what's unclear.
### 2. Simplicity first
The minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstraction for something used once.
- No configurability nobody requested.
- No error handling for scenarios that cannot occur.
- If 200 lines could be 50, write the 50.
Test: would a senior engineer call this overcomplicated? Then simplify.
### 3. Surgical changes
Touch only what you must. Clean up only your own mess.
- Don't reformat, rename, or "improve" code adjacent to your change.
- Match the existing style even if you'd write it differently.
- Notice unrelated dead code? Mention it. Don't delete it.
- Do remove imports and variables that YOUR change orphaned.
Test: every changed line traces directly back to what I asked for.
### 4. Goal-driven execution
Define success before you start. Loop until it's verified.
- "Add validation" becomes "write tests for invalid input, then make them pass".
- "Fix the bug" becomes "write a test that reproduces it, then make it pass".
- For multi-step work, state the plan as `step → how I'll verify it`.
- Never report something as done that you haven't verified. Show the output.This is the step most people skip, and it's the one that tells you whether it worked.
Give your agent a deliberately underspecified task:
Add caching to the API layer.
Before the file: it picks a cache, picks a TTL, picks a key strategy, and writes 200 lines.
After the file: it should come back with questions — which endpoints, in-memory or shared, what invalidates the entry — or state its assumptions explicitly before writing anything.
If it just starts coding, the file isn't being read. Check that CLAUDE.md sits in the directory
you actually started the agent from.
Every rule you add competes for attention with every other rule. Twenty rules is a document your agent skims. Four rules, each tied to a failure you can name, is a document it follows.
Add a fifth only when you can point at the specific mistake it prevents.
Put the file in one project. Work for a day. Then ask yourself which of the four actually changed something — and delete the ones that didn't. A rule that never fires is noise.
More free setups: @buildwith.conrad