65% to 94%: What Bad Habits of Claude Does One CLAUDE.md Keep in Check?

On GitHub trending, a CLAUDE.md file has been forwarded repeatedly. The original tweet claims it shot to No. 1, got 228,000 stars, and raised Claude agent accuracy from 65% to 94%. Don't rush to believe the numbers; replies already ask what the measurement task was. The file is still worth reading because it turns several old habits of LLMs writing code into executable constraints.

Its source and installation are not complicated. The repository is called andrej-karpathy-skills. It says these rules come from Andrej Karpathy's observations about problems with LLMs writing code: the model will make wrong assumptions for you, over-abstract, and casually change code it does not fully understand. The repository condenses the responses into four principles: Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution. The tweet further breaks the four into six operational rules. You can install it as a Claude Code plugin, or download CLAUDE.md into your project; the repository also provides Cursor rules.

The six rules are: write assumptions explicitly, and ask when unsure; cut scope, do not abstract code used once, and if 200 lines can be compressed to 50, rewrite it; keep diffs surgical, and do not refactor things that are not broken; only clean up orphan imports, variables, and functions caused by your own changes, and old dead code should only be marked, not deleted; turn tasks into tests, and when fixing a bug, write a reproduction test first; use a verification loop, where each step is followed by a check, failures loop back, and only passing work is delivered.

These rules sound plain, but their points of action are very specific. By default, the model guesses, expands, and casually makes "improvements" in the diff. CLAUDE.md changes these default actions into requiring asking first, narrowing scope first, and verifying first. The original tweet credits this file with the accuracy improvement, but in the replies Dusan questions "one file can go from 65 to 94," and Xinghai Shizhu also asks what the specific task type was. This doubt is reasonable; the numbers have not been independently verified. A more stable view is: the rules reduce divergence and rework, and the effect depends on the task, model, and project constraints.

There are also two kinds of real feedback in the replies. Chase says his CLAUDE.md is basically a checklist recording what Claude has done wrong and what it is not allowed to do again. Alex Lee says he wants to stick "don't refactor things that aren't broken" onto his monitor and the Agent's head. This is closer to actual usage than "god-tier prompt": rules come from incidents, not inspiration.

Another piece of material comes from Codez's article, about 14 steps for doing graph engineering with Claude. Its opening judgment is direct: most people build multi-step Agents and end up with a straight line. Steps one, two, and three wait in sequence, and much of the waiting has no data dependency. A linear script is a degenerate graph, where nodes are tasks and edges are data flow. Ask every "and then": does the next step really read the previous step's output? If not, there is no edge, and waiting is wasted.

The article's method can be compressed into several things. Give nodes contracts: explicit inputs, outputs validated with a schema, and only one job. Treat edges as data contracts too; if a merge can be done with one flatMap and a Set, do not spin up an Agent. The original has a saying: a graph that puts an Agent on every edge is like paying rent for the wires too. Fan out independent nodes with parallel(); parse failed nodes as null, then filter them out with filter(Boolean). Only set a barrier for stages that need the full result set, such as cross-source deduplication or sorting by impact. Fan-out, processing, and merging form a diamond, which is a common skeleton for reports, audits, and code review.

After that comes control and verification. Routing nodes can use an Agent for classification, but branching is decided by code if or switch. Verification nodes specifically try to kill the conclusion, and can use multiple perspectives, adversarial verification, or a jury. Failures must be isolated; when writing files in parallel, use git worktree, and do not default to isolation for every run. Loops must converge; records from loop-until-dry must be deduplicated against everything seen, not only against confirmed results, otherwise rejected findings will revive every round. Models should also be layered: use cheap models for repetitive nodes, and leave judgment nodes for strong models. Topology directly determines cost and latency; pipeline() is usually preferable to barrier-ized parallel(). The last step is to have Claude write the orchestration script itself, save a good run's script into .claude/workflows/, and run it by name next time.

The article also lists the /deep-research graph already in production: split the question, search in parallel, fetch, adversarial verification, synthesize. It also gives six graphs you can build: security scanning, reports with citations, file-by-file porting, adversarial diff review, ecosystem scanning, and discovery at unknown scale. These examples have engineering detail, not empty "multi-Agent is stronger."

Putting the two materials together, one common point is visible: both move the model from free conversation into checkable structures. CLAUDE.md governs single-node behavior and reduces taking matters into its own hands; graph engineering governs data flow between nodes, reducing pointless waiting and adding verification and isolation. The original tweet's numbers may involve some hype, but the method itself can be checked. Bookmarking a file will not automatically make an Agent stable. What really needs doing is turning the rules into checks in the project, and drawing one fan-out scenario as nodes and edges. Start by adding three: explicit assumptions, minimal diffs, and tasks turned into tests. Then find an audit task that can be parallelized, and see which steps have no data dependency at all.

The original tweet, repository, and Codez's article are here: original tweet / GitHub repository / Codez's article / quoted tweet.