Karpathy Skills
Four rules for AI coding
A community guide inspired by Karpathy's observations: state assumptions, keep implementations simple, focus changes and verify the result.
Clients listed by the author
- Claude Code
- Cursor
- GitHub stars
- 225,625
- Version
- 1.0.0
- Checked
- Categories
- EngineeringProduct & Project
Define what success looks like before coding.
Use this guide when an AI makes decisions without asking, builds a framework for a small feature or changes half a module to fix one bug. Start with a real task, establish scope and acceptance criteria, then inspect the code and verification evidence.
Pick a task and get started
All four scenarios use the same guidelines, configured once. Choose the closest match and replace the example with your code and requirements.
The request is just “export user data.” Scope, fields and delivery still need decisions.
Add the guidelines to your coding assistant
In Claude Code, run the two commands below one at a time in the chat input. For a single project, you can instead merge the author's CLAUDE.md into existing project instructions. Cursor uses a project rule file; see “Before you start” for its setup.
Read the author’s setup guide/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skillsGive your AI this first task
These editorial examples are based on the author's guidelines and cases. They are not separate skill commands. Adapt the scenario and send it to an assistant that has loaded the guidelines.
I want to add “export user data” to this project. Follow karpathy-guidelines to clarify the request first; do not edit code yet. Read the existing user list, permissions and export logic. Separate known facts, assumptions and open questions. Establish whether to export all users or the current filtered set, which fields to include, the format, who may export and the expected volume. Do not ask what the code already answers. For ambiguities that change the implementation, offer options and explain their trade-offs. Finish with the smallest implementation scope and testable acceptance criteria, and wait for the key decisions before implementing.
Check what you receive
- A concrete decision list separates facts from assumptions, without silently choosing the export scope or fields.
- Each unresolved decision has options and an explanation of its implementation consequences.
- Acceptance criteria can be checked, such as row count matching the chosen scope and columns matching the agreed fields. No code has changed yet.
More about this skill
The repository provides the same guidelines as CLAUDE.md, a Claude Code skill and a Cursor project rule. Four working habits apply to writing, reviewing and refactoring code. The skill does not include scripts that implement business features for you.
Think before coding: surface assumptions that affect implementation. If “export users” could mean everyone or the current filtered set, resolve the scope first. Establish facts from existing code, then ask for decisions that genuinely affect direction.
Keep it simple: implement what is needed now. A percentage discount can be a direct calculation, without strategies, factories and registries for hypothetical future discount types. Add structure when a real requirement justifies it.
Make surgical changes: each edit should trace to the request. Fixing blank-email validation does not justify restructuring the form. Remove code made unused by your changes and report unrelated pre-existing issues separately.
Verify against a goal: turn “fix it” into a check that reproduces the failure and proves the correction; turn “clean this up” into a before-and-after behavior comparison. Look for fewer unrelated changes, important questions raised before implementation and actual verification records.
Sources and verification
Sources checked
Usage notes are based on author documentation. We have not tested every skill’s generated output.