Karpathy Coder
Install when you want your coding agent to enforce Andrej Karpathy-style discipline—surface assumptions, resist bloat, make surgical edits, and aim at verifiable goals before you commit.
Overview
Karpathy Coder is an agent skill most often used in Ship (also Build) that enforces Karpathy’s four coding principles with detectors, a review agent, and a pre-commit hook.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill karpathy-coderWhat is this skill?
- Enforces four Karpathy principles: surface assumptions, stay simple, surgical changes, verifiable goals
- Ships Python detectors plus a review agent, slash command, and pre-commit hook—not prose-only guidance
- Fork context mode for isolated review sessions without polluting main agent state
- Triggers on overcoding concerns: “karpathy check,” complexity review, and anti-pattern bloat
- Compatible with Claude Code, Codex CLI, Cursor, Antigravity, OpenCode, and Gemini CLI
- Four Karpathy coding principles enforced as active discipline
- Ships Python violation detectors, review agent, slash command, and pre-commit hook
- Version 2.3.0 with fork context mode
Adoption & trust: 794 installs on skills.sh; 17.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps expanding scope, hiding assumptions, and landing thousand-line solutions when a tight, testable change would do.
Who is it for?
Indie builders who commit frequently with AI assistance and want automated pushback on complexity and vague success criteria.
Skip if: Teams that only need generic style linting with no interest in agent-driven architectural pushback or pre-commit integration.
When should I use this skill?
Writing, reviewing, or committing code; triggers include "review my diff", "check complexity", "am I overcomplicating this", "karpathy check", "before I commit", or any code quality concern where the LLM might be overcod
What do I get? / Deliverables
You get an explicit assumption and tradeoff pass, simpler diffs, and hook-ready checks aligned to verifiable goals before code lands in git.
- Structured review feedback aligned to the four principles
- Pre-commit hook configuration for ongoing enforcement
- Slash-command driven Karpathy checks on demand
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Review and pre-commit are the canonical shelf because the skill explicitly triggers on diff review, complexity checks, and “before I commit,” even though the same habits apply while you are still writing code. Ship → review is where automated review tooling, slash commands, and the bundled pre-commit hook fit the solo builder’s gate before merge or deploy.
Where it fits
Run a Karpathy pass while shaping a new API endpoint so the agent surfaces tradeoffs instead of bolting on a deep abstraction tree.
Check a UI refactor for surgical scope before the agent adds parallel state layers you did not ask for.
Invoke the review agent on a diff when you suspect dead code and bloated constructors slipped in during an agent session.
Use verifiable-goal framing before a small launch fix so the agent loops on measurable acceptance instead of endless polish.
How it compares
Use instead of ad-hoc “please simplify” chat nags when you want bundled tooling and a repeatable review ritual.
Common Questions / FAQ
Who is karpathy-coder for?
Solo and indie developers using Claude Code, Cursor, or Codex who want Karpathy-style coding discipline enforced during reviews and commits.
When should I use karpathy-coder?
During Build while implementing features, during Ship when reviewing diffs or running pre-commit, and whenever you ask the agent to check complexity or run a “karpathy check” before you commit.
Is karpathy-coder safe to install?
It includes Python tooling and a pre-commit hook that touches your repo workflow; review the Security Audits panel on this Prism page and inspect hook scripts before enabling them globally.
SKILL.md
READMESKILL.md - Karpathy Coder
# Karpathy Coder — Active Coding Discipline Derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls. This is **not just guidelines** — it ships Python tools that detect violations, a review agent, a slash command, and a pre-commit hook. > "The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should." > > "They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do." > > "LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go." > > — Andrej Karpathy ## The four principles ### 1. Think Before Coding **Don't assume. Don't hide confusion. Surface tradeoffs.** - State assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them — don't pick silently. - If a simpler approach exists, say so. Push back when warranted. - If something is unclear, stop. Name what's confusing. Ask. ### 2. Simplicity First **Minimum code that solves the problem. Nothing speculative.** - No features beyond what was asked. - No abstractions for single-use code. - No "flexibility" or "configurability" that wasn't requested. - No error handling for impossible scenarios. - If you write 200 lines and it could be 50, rewrite it. **The test:** Would a senior engineer say this is overcomplicated? If yes, simplify. ### 3. Surgical Changes **Touch only what you must. Clean up only your own mess.** - Don't "improve" adjacent code, comments, or formatting. - Don't refactor things that aren't broken. - Match existing style, even if you'd do it differently. - If you notice unrelated dead code, mention it — don't delete it. - Remove imports/variables/functions that YOUR changes made unused. - Don't remove pre-existing dead code unless asked. **The test:** Every changed line should trace directly to the user's request. ### 4. Goal-Driven Execution **Define success criteria. Loop until verified.** | Instead of... | Transform to... | |---|---| | "Add validation" | "Write tests for invalid inputs, then make them pass" | | "Fix the bug" | "Write a test that reproduces it, then make it pass" | | "Refactor X" | "Ensure tests pass before and after" | For multi-step tasks, state a brief plan: ``` 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] ``` ## Slash command `/karpathy-check` — Run the full 4-principle review on your staged changes. ## Python tools (`scripts/`) All tools are stdlib-only. Run with `--help`. | Script | What it detects | |---|---| | `complexity_checker.py` | Over-engineering: too many classes, deep nesting, high cyclomatic complexity, unused params, premature abstractions | | `diff_surgeon.py` | Diff noise: lines that don't trace to the stated goal — comment changes, style drift, drive-by refactors | | `assumption_linter.py` | Hidden assumptions in a plan: unasked features, missing clarifications, silent interpretation choices | | `goal_verifier.py` | Weak success criteria: vague plans