Apply Karpathy Guidelines to Reduce LLM Coding Mistakes

This skill sets behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls. It biases toward caution over speed, and trivial tasks still call for judgment rather than mechanical application.

The guidelines run in four parts. Think before coding: do not assume, do not hide confusion, and surface tradeoffs. State assumptions explicitly and ask when uncertain, present multiple interpretations rather than silently picking one, say when a simpler approach exists and push back when warranted, and stop and name the confusion when something is unclear.

Simplicity first: write the minimum code that solves the problem and nothing speculative. Add no features beyond what was asked, no abstractions for single-use code, no flexibility or configurability that was not requested, and no error handling for impossible scenarios. If 200 lines could be 50, rewrite it, and ask whether a senior engineer would call the result overcomplicated.

Surgical changes: touch only what you must and clean up only your own mess. Do not improve adjacent code, comments, or formatting, do not refactor things that are not broken, and match existing style even when you would do it differently. If you notice unrelated dead code, mention it rather than deleting it. When your own changes create orphaned imports, variables, or functions, remove those, but do not remove pre-existing dead code unless asked. The test is that every changed line should trace directly to the user's request.

Goal-driven execution: define success criteria and loop until they are verified. Transform vague tasks into verifiable goals, for example turning "add validation" into writing tests for invalid inputs and then making them pass, or turning "fix the bug" into writing a test that reproduces it and then making it pass. For multi-step tasks, state a brief plan listing each step with its own verification check. Strong success criteria let the work loop independently; weak criteria such as "make it work" require constant clarification.

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.

These are behavioral guardrails, not a replacement for project-specific architecture or style rules. For emergency fixes, the smallest verified correction should take priority over extensive planning. For exploratory prototypes, some caution can be relaxed, but assumptions and verification should still be stated explicitly.

The input is a coding request. The output is code changed according to the four guidelines, plus a short explicit record of assumptions, scope, and a verification plan. Two examples: for "add validation to this form," a better response states the assumption that validation runs before submit with inline errors, plans a small validator with tests for invalid inputs, and scopes the change to the form component and its test file; for "refactor this service," a better response first asks what behavior must remain unchanged, identifies a concrete smell such as duplicated parsing logic, makes the smallest refactor, and runs the existing service tests.

This is a behavioral skill with no external tools or services; it applies directly inside any coding session, listed for use with Claude Code, Antigravity, Cursor, Gemini CLI, and Codex CLI.

It is for developers and teams using LLM coding assistants who want fewer overcomplicated diffs, less scope creep in edits, and code changes that come with explicit assumptions and a verification plan instead of a bare "done."