Andrej Karpathy Skills

What it claims

Beyond the four principles the summary already names, the page adds the specific install paths, the self-check heuristics baked into each principle, and an explicit scope caveat: the guidelines "bias toward caution over speed," and for trivial changes (typo fixes, obvious one-liners) you're told to skip the full rigor.

How to use it

Two install routes. As a Claude Code plugin (the repo's recommended path):

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

Or drop the file into a project directly — new project vs. appending to an existing CLAUDE.md:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

The repo also commits .cursor/rules/karpathy-guidelines.mdc so the same rules load in Cursor; see CURSOR.md. The file is meant to be merged with your own project instructions, not to replace them — the page shows a ## Project-Specific Guidelines section (TypeScript strict mode, endpoint tests, existing error-handling patterns) appended below the imported rules. Licence is MIT.

Note a naming mismatch the reader should check: the catalog URL is under multica-ai, but every command and raw link on the page points at forrestchang/andrej-karpathy-skills. Verify which repo you're actually pulling from.

What the principles operationalize

Each principle carries a concrete acceptance test the summary omits:

• Simplicity: "Would a senior engineer say this is overcomplicated? If yes, simplify." Explicit rules include no error handling for impossible scenarios and no config that wasn't requested; "if 200 lines could be 50, rewrite it."
• Minimal edits: "Every changed line should trace directly to the user's request." You remove only the imports/variables your own change orphaned; pre-existing dead code you mention, not delete.
• Goal-driven loops: state a numbered plan where each step pairs with a → verify: [check].

The page also gives observable success signals to judge whether it's working: fewer unnecessary diff changes, clarifying questions arriving before implementation rather than after mistakes, and clean minimal PRs with no drive-by refactoring.

Limits

This is a prompt/instructions artifact, not code — there's no benchmark or measured effect. "Working" is defined only by the qualitative diff signals above; the repo offers no evaluation of whether the principles actually reduce the failure modes Karpathy describes.