返回技能列表
编程开发github

andrej-karpathy-skills

Andrej Karpathy 推荐的 Claude Code 技能配置文件,通过一个 CLAUDE.md 文件提升 AI 编程助手的代码质量。涵盖最佳实践、常见陷阱规避、代码审查规则等,是使用 Claude Code 的必备配置。

166,944
Stars
2026-06-04
更新时间
4
标签数
10
阅读分钟
agentllmclauderag
查看 GitHub 仓库

详细介绍

项目简介

Andrej Karpathy 推荐的 Claude Code 技能配置文件,通过一个 CLAUDE.md 文件提升 AI 编程助手的代码质量。涵盖最佳实践、常见陷阱规避、代码审查规则等,是使用 Claude Code 的必备配置。

主要特性

  • State assumptions explicitly — If uncertain, ask rather than guess
  • Present multiple interpretations — Don't pick silently when ambiguity exists
  • Push back when warranted — If a simpler approach exists, say so
  • Stop when confused — Name what's unclear and ask for clarification
  • No features beyond what was asked
  • No abstractions for single-use code

适用场景

代码审查与优化
自动化测试编写
文档生成与维护
代码重构建议

快速开始

# 克隆仓库
git clone https://github.com/multica-ai/andrej-karpathy-skills
# 进入目录
cd andrej-karpathy-skills
# 查看文档
cat README.md

原文 README

Karpathy-Inspired Claude Code Guidelines

Check out my new project Multica — an open-source platform for running and managing coding agents with reusable skills.

Follow me on X: https://x.com/jiayuan_jy

A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.

English | 简体中文

The Problems

From Andrej's post:

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

"They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task."

The Solution

Four principles in one file that directly address these issues:

Principle Addresses
Think Before Coding Wrong assumptions, hidden confusion, missing tradeoffs
Simplicity First Overcomplication, bloated abstractions
Surgical Changes Orthogonal edits, touching code you shouldn't
Goal-Driven Execution Leverage through tests-first, verifiable success criteria

The Four Principles in Detail

1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

LLMs often pick an interpretation silently and run with it. This principle forces explicit reasoning:

  • State assumptions explicitly — If uncertain, ask rather than guess
  • Present multiple interpretations — Don't pick silently when ambiguity exists
  • Push back when warranted — If a simpler approach exists, say so
  • Stop when confused — Name what's unclear and ask for clarification

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

Combat the tendency toward overengineering:

  • 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 200 lines 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.

When editing existing code:

  • 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

When your changes create orphans:

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

Transform imperative tasks into verifiable goals:

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]

Strong success criteria let the LLM loop independently. Weak criteria ("make it work") require constant clarification.

Install

Option A: Claude Code Plugin (recommended)

From within Claude Code, first add the marketplace:

/plugin marketplace add forrestchang/andrej-karpathy-skills

Then install the plugin:

/plugin install andrej-karpathy-skills@karpathy-skills

This installs the guidelines as a Claude Code plugin, making the skill available across all your projects.

Option B: CLAUDE.md (per-project)

New project:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Existing project (append):

echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

Using with Cursor

This repository includes a committed Cursor project rule (.cursor/rules/karpathy-guidelines.mdc) so the same guidelines apply when you open the project in Cursor. See CURSOR.md for setup, using the rule in other projects, and how this relates to Claude Code.

Key Insight

From Andrej:

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

The "Goal-Driven Exec