Apply Karpathy Guidelines to Reduce LLM Coding Mistakes

This skill applies behavioral guidelines derived from Andrej Karpathy's observations on LLM coding pitfalls, meant to reduce common mistakes when an LLM writes, reviews, or refactors code. The guidelines deliberately bias toward caution over speed, trading some speed for surfaced assumptions and surgical, minimal changes; for trivial tasks the skill notes that judgment can override the full rule set.

Use it when writing, reviewing, or refactoring code with an LLM; when a change needs to stay surgical and avoid speculative abstractions; when assumptions, tradeoffs, and verification criteria should be made explicit; or when code has become overcomplicated and needs simplifying. The skill itself names where to relax it: for emergency fixes, prioritize the smallest verified correction over extensive planning, and for exploratory prototypes some caution can be relaxed, though assumptions and verification should still stay explicit. It is framed as a behavioral guardrail, not a replacement for project-specific architecture or style rules.

Input is a coding request handled by an LLM. Output is behavior shaped by four rules. Think before coding: state assumptions explicitly and ask if uncertain, surface multiple interpretations rather than picking one silently, push back if a simpler approach exists, and stop to name what's confusing rather than guessing. Simplicity first: write the minimum code that solves the problem, add no abstractions for single-use code, no unrequested flexibility or configurability, no error handling for impossible scenarios, and rewrite anything a senior engineer would call overcomplicated - the source's own test is whether 200 lines could be 50. Surgical changes: touch only what the request requires, don't "improve" adjacent code, comments, or formatting, don't refactor things that aren't broken, match existing style even when you'd do it differently, and mention rather than delete unrelated dead code you notice - though imports, variables, or functions that your own change made unused should be removed. Every changed line should trace directly to the user's request. Goal-driven execution: turn a task into a verifiable goal - "add validation" becomes "write tests for invalid inputs, then make them pass"; "fix the bug" becomes "write a test that reproduces it, then make it pass"; "refactor X" becomes "ensure tests pass before and after" - and for multi-step tasks, state a brief numbered plan with a verification check per step, since strong success criteria let work proceed independently while weak criteria like "make it work" require constant clarification. Two worked examples in the source apply this to a validation request (stating the assumption, a small validator plus tests, and a scope limited to the form component and its test file) and a refactor request (asking what behavior must stay unchanged, naming a concrete smell like duplicated parsing logic, then making the smallest refactor and running existing service tests).

Anyone using an LLM to write, review, or refactor code who wants surgical, well-scoped changes with explicit assumptions and verification, rather than speculative or overcomplicated output.