karpathy-review — Behavioral Governor

Adapted from forrestchang/andrej-karpathy-skills, distilled from Karpathy's observations about common LLM coding failure modes. Sits ABOVE skill-specific work as a behavioral check, not as a tool.

When to use

• Before non-trivial code edits — review the plan's assumptions and simplicity
• After non-trivial code edits — review the diff's surgical-ness and verification
• When the operator says "this seems over-engineered" or "this changed more than I expected"
• Inside /ship, /fix-root, /review as a mandatory gate (see Quality gates below)

When NOT to use

• Trivial edits (typo fix, one-line docs change, whitespace) — overhead exceeds value
• Pure research / exploration — no code being shipped
• During brainstorming — premature constraint
• For commit-message review — different concern

Inputs