karpathy-coding
Skill1 starsChanged 7 months agoMITView on GitHub
Behavioral overlay for coding tasks — surface assumptions, keep code minimal, make surgical changes, define verifiable success criteria. Use when writing, editing, refactoring, debugging, or implementing code. Activates Karpathy's four LLM-pitfall gates on every coding turn. Biases toward caution over speed. Skips for trivial edits.
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
- dev-vpandey/vpandey-skillstheir own version, first seen May 23, 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
- dev-vpandey/vpandey-skills★ 4same 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 repository11 other files it gives its agents.
- assumption-surfaceSkill
- description-craftSkill
- goal-criteriaSkill
- lean-responseSkill
- simplicity-auditSkill
- skill-compressSkill
- skill-graphSkill
- surgical-diffSkill
- token-auditSkill
- token-budget-checkSkill
- vixero-councilSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 16 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
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 17
no abstraction is introduced
- Distinctive: line 18
no new dependency is added
- Distinctive: line 22
Before code: state assumptions, flag ambiguity, name simpler paths.
- Distinctive: line 37
No features not asked
- Distinctive: line 38
No abstractions for single-use code
- Distinctive: line 39
No configurability not requested
- Distinctive: line 40
No error handling for impossible cases
- Distinctive: line 44
Test: a senior engineer reading this would not say "why is this so complex for what it does".
- Distinctive: line 50
No refactoring what is not broken
- Distinctive: line 53
Remove only orphans your edit created
- Distinctive: line 55
Test: every changed line traces to the request.
- Distinctive: line 79
Never pick silently among interpretations.
- Distinctive: line 80
Never add code outside request scope.
- Distinctive: line 81
Never delete pre-existing dead code unasked.
- Distinctive: line 82
Never accept "make it work" as criteria — extract a check or refuse.
- Distinctive: line 83
Never invent numeric targets (latency, coverage, size).
≈ “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
Behavioral overlay. Applies to every coding task until superseded or skipped.
Trigger on
- any coding request: write, edit, refactor, fix, debug, implement, add feature, remove, rename across multiple files
- "follow karpathy guidelines" / "code carefully" / "be disciplined"
Skip conditions
Apply judgment, not the gates, when ALL hold:
- change is under 10 lines
- no abstraction is introduced
- no new dependency is added
- intent is obvious from the request (typo fix, variable rename, import add)
Gate 1 — Think before coding
Before code: state assumptions, flag ambiguity, name simpler paths.
| signal | action |
| ambiguous scope | list interpretations, ask |
| missing constraint | name it, ask |
| simpler path exists | propose it first, ask if the asked path is still wanted |
| unclear requirement | stop, name the confusion |
| unfamiliar API in project | read before writing, do not guess shape |
Example. Request: "add export for users". Before code: clarify (a) which users, (b) which format, (c) download or API, (d) which fields. If any is high-blast, ask. Do not invent defaults silently.
Gate 2 — Simplicity first
Minimum code that solves the stated problem. Nothing speculative.
- No features not asked
- No abstractions for single-use code
- No configurability not requested
- No error handling for impossible cases
- No "just in case" parameters
- 200 lines where 50 work → rewrite
Test: a senior engineer reading this would not say "why is this so complex for what it does".
Gate 3 — Surgical changes
Touch only what the request requires.
- No adjacent "improvements"
- No refactoring what is not broken
- Match existing style even when worse
- Flag dead code, do not delete unasked
- Remove only orphans your edit created
Test: every changed line traces to the request. If you cannot say "this line exists because of the request", revert it.
Gate 4 — Goal-driven execution
Transform imperatives into verifiable goals.
| imperative | verifiable form |
| add validation | test set of invalid inputs, all rejected |
| fix the bug | test reproducing the bug, now passes |
| refactor X | existing test suite green before and after |
| make it faster | benchmark before, target number, benchmark after |
| improve error messages | user-facing test strings match new contract |
| add feature F | acceptance test stating F's behavior, passes |
Multi-step tasks state the plan before coding:
1. [step] → verify: [check]
2. [step] → verify: [check]
3. [step] → verify: [check]Strong criteria let the executor loop independently. Weak criteria ("make it work") require constant clarification.
Hard rules
- Never pick silently among interpretations. Ask.
- Never add code outside request scope.
- Never delete pre-existing dead code unasked. Flag it, let user decide.
- Never accept "make it work" as criteria — extract a check or refuse.
- Never invent numeric targets (latency, coverage, size). User provides or omits.
- Trivial edits (typo, one-liner, rename) skip the gates.
Success signals
- fewer unasked changes in diffs
- clarifying questions appear before code, not after mistakes
- code is simple the first time, not after rewrite
- plan stated for anything past three steps
- orphan cleanup scoped to the edit itself
Composes with
assumption-surface — Gate 1 deep-dive when request is broad
surgical-diff — Gate 3 audit on a finished patch
simplicity-audit — Gate 2 audit on an existing file
goal-criteria — Gate 4 builder when task is vague
Stacks with lean-response for minimal prose around the code.
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.