Karpathy discipline
Skill Mrbaeksang/ai-project-audit/skills/karpathy-discipline
Karpathy's 4 coding principles + 10-section production audit (OWASP/SOLID/ACID/12-Factor) for Claude Code. Service-profile-driven, grade-aware, multilingual (EN/한국어, responds in any language).
npx -y skills add Mrbaeksang/ai-project-audit --skill karpathy-disciplineAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Enforces Karpathy's 4 LLM-coding principles (Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution). Auto-fires whenever the user requests writing, editing, refactoring, fixing, or adding code. Blocks drive-by refactoring, over-engineering, and speculative changes; demands clarification before implementation, minimum code, surgical edits, and conversion of tasks into verifiable goals. Respond in the user's language.
SKILL.md
2.6 KB, as published. Nobody here has run it
Karpathy Discipline
Source: Andrej Karpathy on LLM coding pitfalls.
Activates on
- Any request to write, edit, refactor, fix, or add code.
- Before opening an Edit/Write tool call on existing code.
Pre-flight checks (must pass before generating code)
① Think Before Coding
- Stated assumptions explicitly?
- Multiple interpretations → presented to the user?
- A simpler path exists → mentioned first?
- Named the unclear parts?
② Simplicity First
- No features outside the request?
- No abstractions for single-use code?
- No error handling for impossible scenarios?
- Reviewed whether 200 lines could be 50?
③ Surgical Changes
- Every line traces to the user's request?
- No "improvements" to adjacent code?
- Existing style preserved (even if you'd write it differently)?
- Pre-existing dead code → mentioned only, not deleted?
- Removed only orphans my changes created?
④ Goal-Driven Execution
- Task converted into a verifiable goal?
- Multi-step work has per-step verify checks?
- Strong success criteria (avoid weak phrases like "make it work")?
Translation table
| Request | Goal |
|---|---|
| "Add validation" | "Write tests for invalid inputs → fail → implement → pass" |
| "Fix the bug" | "Write reproducing test → fail → fix → pass" |
| "Refactor X" | "Confirm tests pass → refactor → tests still pass" |
| "Clean this up" | (ambiguous) → ask: formatting? function split? naming? |
Violation signals — stop and tell the user
- Imports the user didn't ask to change.
- "Bonus" helper functions added.
- "Just in case" try/except.
- Variable renamed for "cleanliness" without request.
- Formatting changes in unrelated regions.
Working signals
- Diffs are small; every line traces to the request.
- Clarification questions arrive before implementation.
- "A simpler approach exists..." appears often.
- "This is outside the requested scope, leaving it" appears when it should.
Language
Respond in the user's language (Korean for Korean prompts, etc.). Code identifiers and file paths stay as-is.