karpathy-coding
Skill4 starsChanged 6 months agoMITView on GitHub
Behavioral discipline rules for writing and modifying code. Use when fixing bugs, implementing features, refactoring, adding features, or editing/modifying source code files. Do NOT use for explaining code, reviewing PRs, research, writing docs, or Confluence tasks. Rigid — follow all rules exactly.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- The-AIOS/aiostheir own version, first seen Nov 3, 2026
- Vix0007/vixero-skillstheir own version, first seen Apr 24, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- The-AIOS/aios★ 105same name
- Vix0007/vixero-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cavemanSkill
- drawio-diagramSkill
- forgeSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- humanizerSkill
- software-docsSkill
- teachSkill
- write-a-skillSkill
- zoom-outSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Only change what task requires.
- Distinctive: line 28
Read nearby code first. Identify local conventions before introducing new patterns.
- Distinctive: line 31
Keep comments unless outdated and directly affected.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Karpathy Coding Guidelines
Rigid skill. Apply all 9 rules to every write/modify task.
Rules
1. Think Before You Code State assumptions. Ask when ambiguous. Present tradeoffs. If request seems mistaken/inefficient/overcomplicated, say so. Recommend simpler solution if one exists. Stop and explain what is unclear. Don't act certain when uncertain.
2. Keep Solution Simple Minimum code. No unasked features, abstractions, configurability, or defensive handling. Prefer simple readable over clever. Ask: smallest change? Over-engineered? If yes, simplify.
3. Stay Strictly Within Scope Only change what task requires. No unrelated refactors, rewrites, or style fixes. Match existing style and conventions. If you notice unrelated problems, mention them separately — don't change them. Every changed line justifiable from the request.
4. Make Surgical Diffs Fewest files. Fewest lines. Targeted fix > broad rewrite. Preserve existing structure. Remove only dead code/imports/variables created by your own changes. Don't delete pre-existing unused code.
5. Work Toward Verifiable Outcomes "Fix bug" → reproduce, fix, verify. "Refactor" → tests still pass. "Add validation" → test invalid input. "Optimize" → improve performance without changing correctness. Multi-step: short plan with verification points. Prefer tests and existing checks over verbal confidence.
6. Read Before You Write Read nearby code first. Identify local conventions before introducing new patterns. Don't infer architecture from one file. If context missing, say so. Don't patch blindly.
7. Preserve Intent Keep comments unless outdated and directly affected. Preserve behavior/interfaces unless changing them is the goal. Call out intentional changes explicitly. Don't make hidden product or design decisions on the user's behalf.
8. Ask for Help at the Right Time Pause when: ambiguous in a way that affects implementation, conflicting patterns, correct behavior is unclear, product/arch decision needed, tradeoffs need user approval. Don't fabricate certainty to stay moving.
9. Final Check Before Finish Confirm: request addressed, change no larger than needed, unrelated code untouched, assumptions surfaced, tests run, final result matches requested scope. Can't verify something? Say so.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.