cs-karpathy-reviewer
Reviews staged git changes against Karpathy's 4 coding principles. Runs complexity_checker on changed files, diff_surgeon on the diff, and produces a verdict with specific fix recommendations. Spawn before committing, when the user says "karpathy check", "review my diff", or when the /karpathy-check command is invoked.
Best use case
cs-karpathy-reviewer is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Reviews staged git changes against Karpathy's 4 coding principles. Runs complexity_checker on changed files, diff_surgeon on the diff, and produces a verdict with specific fix recommendations. Spawn before committing, when the user says "karpathy check", "review my diff", or when the /karpathy-check command is invoked.
Teams using cs-karpathy-reviewer should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/cs-karpathy-reviewer/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How cs-karpathy-reviewer Compares
| Feature / Agent | cs-karpathy-reviewer | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Reviews staged git changes against Karpathy's 4 coding principles. Runs complexity_checker on changed files, diff_surgeon on the diff, and produces a verdict with specific fix recommendations. Spawn before committing, when the user says "karpathy check", "review my diff", or when the /karpathy-check command is invoked.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
Cursor vs Codex for AI Workflows
Compare Cursor and Codex for AI coding workflows, repository assistance, debugging, refactoring, and reusable developer skills.
SKILL.md Source
# karpathy-reviewer ## Role You review code changes against Karpathy's 4 principles. You are opinionated and specific — don't just say "looks fine", point to exact lines and explain which principle they violate. ## Workflow ### 1. Get the diff ```bash git diff --staged ``` If nothing staged, use `git diff HEAD~1..HEAD` (last commit). ### 2. Run the automated tools ```bash # Principle #2 — Simplicity check on changed files python <plugin>/scripts/complexity_checker.py <changed-files> --json # Principle #3 — Surgical changes check python <plugin>/scripts/diff_surgeon.py --json ``` ### 3. Manual review against each principle **Principle #1 (Think Before Coding):** Were any assumptions made without explicit mention? Did the implementation pick one interpretation of an ambiguous requirement without surfacing alternatives? **Principle #2 (Simplicity First):** Are there abstractions that serve only one caller? Classes that could be functions? Error handling for impossible scenarios? Features nobody asked for? **Principle #3 (Surgical Changes):** Does every changed line trace directly to the task? Any comment changes, style drift, drive-by refactors, or "improvements" to adjacent code? **Principle #4 (Goal-Driven Execution):** Is there evidence the work was verified? Test additions/modifications? Clear success criteria? Or did the implementation just "look right" without testing? ### 4. Produce a report ```markdown ## Karpathy Review — <date> ### Tool Results - Complexity: <score>/100 (<N> findings) - Diff Noise: <ratio>% (<verdict>) ### Principle-by-Principle #### #1 Think Before Coding - [PASS/WARN] <specific observation or "no hidden assumptions detected"> #### #2 Simplicity First - [PASS/WARN] <specific observation> #### #3 Surgical Changes - [PASS/WARN] <specific lines cited> #### #4 Goal-Driven Execution - [PASS/WARN] <test coverage or verification evidence> ### Verdict: <PASS / PASS WITH WARNINGS / NEEDS WORK> ### Specific fixes (if any) 1. <file:line — what to change and why> ``` ## Rules - **Cite specific lines.** "The diff has noise" is useless. "Line 42: comment changed in untouched function" is actionable. - **Don't re-run the user's task.** You review, not implement. - **Be proportional.** A typo fix doesn't need the same rigor as a 200-line feature. - **Run the tools.** Don't skip automated checks — your manual review supplements them.
Related Skills
karpathy-coder
Use when writing, reviewing, or committing code to enforce Karpathy's 4 coding principles — surface assumptions before coding, keep it simple, make surgical changes, define verifiable goals. Triggers on "review my diff", "check complexity", "am I overcomplicating this", "karpathy check", "before I commit", or any code quality concern where the LLM might be overcoding.
karpathy-check
Run Karpathy's 4-principle review on staged changes or the last commit. Checks complexity, diff noise, hidden assumptions, and goal verification. Usage /karpathy-check [--last-commit]
code-reviewer
Code review automation for TypeScript, JavaScript, Python, Go, Swift, Kotlin. Analyzes PRs for complexity and risk, checks code quality for SOLID violations and code smells, generates review reports. Use when reviewing pull requests, analyzing code quality, identifying issues, generating review checklists.
api-design-reviewer
API Design Reviewer
adversarial-reviewer
Adversarial code review that breaks the self-review monoculture. Use when you want a genuinely critical review of recent changes, before merging a PR, or when you suspect Claude is being too agreeable about code quality. Forces perspective shifts through hostile reviewer personas that catch blind spots the author's mental model shares with the reviewer.
wiki-query
Query the LLM Wiki — reads index.md first, drills into 3-10 relevant pages, synthesizes an answer with inline [[wikilink]] citations, and offers to file the answer back as a new comparison or synthesis page. Usage /wiki-query "<question>"
wiki-log
Show recent entries from the LLM Wiki log (wiki/log.md). Uses the standardized
wiki-lint
Run a health check on the LLM Wiki vault — mechanical checks (orphans, broken links, stale pages, missing frontmatter, log gap, duplicates) plus semantic checks (contradictions, cross-reference gaps, concepts missing their own page). Outputs a markdown report with suggested actions. Usage /wiki-lint [--stale-days N] [--log-gap-days N]
wiki-init
Bootstrap a fresh LLM Wiki vault with the three-layer structure, schema files, and starter templates. Usage /wiki-init <path> --topic "<topic>" [--tool all|claude-code|codex|cursor|antigravity]
wiki-ingest
Ingest a source file from raw/ into the LLM Wiki — read, discuss, write summary page, update cross-references across 5-15 pages, regenerate index, append to log. Usage /wiki-ingest <path-to-source>
tc
Track technical changes with structured records, a state machine, and session handoff. Usage: /tc <init|create|update|status|resume|close|export|dashboard> [args]
tc-tracker
Use when the user asks to track technical changes, create change records, manage TC lifecycles, or hand off work between AI sessions. Covers init/create/update/status/resume/close/export workflows for structured code change documentation.