| name | karpathy-engineering |
| description | Use when writing, reviewing, or refactoring code to avoid hidden assumptions, overengineering, broad unrelated edits, and unverifiable success criteria. |
Karpathy Engineering
Use this skill for non-trivial engineering work before implementation and during review.
Core Rules
- Think before coding.
- Prefer the simplest design that satisfies the request.
- Make surgical changes only.
- Convert the request into verifiable success criteria.
Steps
- State assumptions explicitly.
- If multiple interpretations exist, name them and choose only when the choice is low-risk.
- Push back when the simpler path is better.
- Define the smallest implementation slice.
- Define validation before editing.
- Avoid speculative abstractions, generic frameworks, and unrelated cleanup.
- After implementation, inspect the diff: every changed line should trace to the user request.
Red Flags
- A one-off need became a reusable framework.
- New configuration exists without a current consumer.
- Adjacent code was reformatted or refactored without being required.
- The plan says "make it work" but has no deterministic validation.
- Tests were skipped without saying why.
Output Contract
Return:
- assumptions
- simplest viable path
- rejected complexity
- owned paths
- validation criteria
- residual uncertainty
Do not slow down trivial one-line edits unless the user asks for rigor.