# Karpathy Discipline

> 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: `mrbaeksang/karpathy-discipline` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mrbaeksang/karpathy-discipline`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrbaeksang/karpathy-discipline/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Mrbaeksang (https://skillmd.com/u/mrbaeksang)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrbaeksang/karpathy-discipline

---


# Karpathy Discipline

Source: [Andrej Karpathy on LLM coding pitfalls](https://x.com/karpathy/status/2015883857489522876).

## 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.