카파시 스타일로 Claude Code 다듬기: andrej-karpathy-skills 실전 가이드

AI 코딩 도구가 만드는 가장 골치 아픈 문제는 문법 오류만이 아니다. 요청하지 않은 추상화를 추가하고, 작은 버그를 고치면서 주변 파일까지 정리하며, 모호한 요구사항을 임의로 해석한 뒤 “완료”라고 말하는 경우가 더 위험하다.
andrej-karpathy-skills는 이런 행동을 줄이기 위한 짧은 코딩 지침 모음이다. Andrej Karpathy가 LLM 코딩의 함정을 설명한 X 게시물에서 아이디어를 가져와, Claude Code와 Cursor에서 재사용할 수 있는 네 가지 원칙으로 정리했다.
먼저 이름 때문에 생길 수 있는 오해부터 바로잡자. 이 저장소는 Karpathy가 직접 만든 공식 스킬이 아니다. Karpathy의 관찰을 바탕으로 커뮤니티가 만든 MIT 라이선스 프로젝트이며, 저장소 manifest의 작성자도 forrestchang으로 표시되어 있다. 이 글은 2026년 8월 6일 기준 저장소의 README, SKILL.md, CLAUDE.md, plugin manifest, Cursor rule과 Claude Code 공식 문서를 교차 확인해 작성했다.
이 저장소에는 무엇이 들어 있나
핵심 내용은 같지만 적용 방식이 세 가지로 제공된다.
| 파일 | 대상 | 동작 방식 | 추천 상황 |
|---|---|---|---|
skills/karpathy-guidelines/SKILL.md | Claude Code plugin | 관련 작업에서 불러오거나 명시적으로 실행 | 여러 프로젝트에서 필요할 때만 사용 |
CLAUDE.md | Claude Code | 프로젝트 지침으로 매 세션 로드 | 팀 전체가 항상 적용해야 할 때 |
.cursor/rules/karpathy-guidelines.mdc | Cursor | alwaysApply: true project rule | Cursor 저장소에 상시 적용할 때 |
Claude Code 공식 문서에 따르면 CLAUDE.md는 매 세션 context에 들어가지만, skill 본문은 호출되거나 관련성이 있다고 판단될 때만 로드된다. 따라서 상시 규칙은 CLAUDE.md, 상황별 체크리스트는 skill로 두는 편이 context를 효율적으로 사용한다.
네 가지 핵심 원칙
1. 코딩 전에 생각하기
요구사항의 빈칸을 조용히 상상해서 채우지 않는다. 전제를 먼저 밝히고, 해석이 여러 개라면 선택지와 차이를 설명하며, 확신이 없으면 질문한다.
예를 들어 “검색을 빠르게 만들어 줘”라는 요청을 받았다고 하자. 곧바로 캐시나 검색 엔진을 넣기보다 다음을 먼저 확인한다.
- 느린 구간이 입력 반응, API, 데이터베이스 중 어디인가?
- 목표 응답 시간과 데이터 규모는 얼마인가?
- 최신성이 조금 늦어져도 캐시를 써도 되는가?
- 현재 병목을 보여 주는 측정 결과가 있는가?
좋은 AI 코딩은 답을 빨리 내는 것이 아니라, 틀린 문제를 빠르게 푸는 일을 피하는 것에서 시작한다.
2. 단순성을 우선하기
오늘 필요한 문제만 해결한다. 한 번 쓰는 추상화, 요청하지 않은 설정 옵션, 미래를 가정한 확장 지점은 만들지 않는다. 같은 결과를 200줄 대신 50줄로 명확하게 만들 수 있다면 다시 줄인다.
단, “단순하게”는 오류 처리나 보안을 생략하라는 뜻이 아니다. 필요한 검증은 남기되, 실제 요구사항으로 설명할 수 없는 구조를 걷어내라는 뜻이다.
3. 필요한 부분만 정밀하게 바꾸기
버그 한 개를 고치면서 따옴표 스타일, 타입 힌트, 주석, 주변 함수 이름까지 바꾸지 않는다. 기존 코드의 스타일을 따르고, 사용자가 요청한 결과와 연결되는 줄만 수정한다.
실전에서는 작업 후 다음 질문을 던지면 된다.
Show every changed file and explain how each changed block is required by my request.
Flag any formatting, cleanup, or refactoring that is unrelated.
설명하기 어려운 변경은 대부분 이번 작업의 범위를 벗어난다. 관련 없는 오래된 코드를 발견했다면 삭제하지 말고 별도 항목으로 알려 주는 것이 안전하다.
4. 검증 가능한 목표로 실행하기
“인증을 개선한다” 같은 모호한 목표를 그대로 실행하지 않는다. “비밀번호 변경 후 기존 세션이 무효화되는 실패 테스트를 만들고, 수정 후 통과시키며, 기존 인증 테스트도 통과시킨다”처럼 관찰 가능한 성공 조건으로 바꾼다.
1. 버그를 재현하는 테스트 작성 → 현재 코드에서 실패 확인
2. 최소 수정 구현 → 재현 테스트 통과 확인
3. 관련 회귀 테스트 실행 → 기존 동작 유지 확인
4. diff 검토 → 요청과 무관한 변경이 없는지 확인
이 원칙은 계획을 길게 쓰라는 뜻이 아니다. 각 단계 뒤에 무엇으로 성공을 확인할지 붙이라는 뜻이다.
설치 방법 A: Claude Code plugin으로 사용하기
여러 프로젝트에서 필요할 때 불러오려면 plugin 방식이 가장 편하다. Claude Code 안에서 현재 GitHub 저장소를 marketplace로 추가한 뒤 plugin을 설치한다.
/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
설치 화면에서 범위를 선택할 수 있다.
user: 내 모든 프로젝트project: 저장소 팀원과 공유local: 이 저장소에서 나만 사용
설치 결과에 안내가 표시되면 /reload-plugins를 실행한다. 이 plugin의 명시적 호출 이름은 다음과 같다.
/andrej-karpathy-skills:karpathy-guidelines
skill 설명이 코딩·리뷰·리팩터링 작업을 대상으로 하므로 Claude가 관련성을 판단해 불러올 수도 있지만, 중요한 변경 전에는 위 명령으로 직접 실행하는 편이 확실하다.
검증 메모: 저장소가
multica-ai조직으로 이동했지만, 확인 시점의 README 설치 예시는 이전forrestchang경로를 사용하고 있었다. GitHub 리다이렉트에 기대지 않도록 이 글에서는 현재 canonical 경로인multica-ai/andrej-karpathy-skills를 사용했다.
설치 방법 B: 프로젝트 CLAUDE.md에 적용하기
팀 규칙으로 항상 적용하고 싶다면 저장소의 CLAUDE.md 내용을 프로젝트 지침에 합친다. 기존 CLAUDE.md가 있다면 바로 덮어쓰거나 무조건 이어 붙이지 않는다. 먼저 별도 파일로 받아 충돌과 중복을 검토한다.
curl -fsSL \
https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md \
-o /tmp/karpathy-guidelines.md
diff -u CLAUDE.md /tmp/karpathy-guidelines.md
그다음 필요한 원칙만 기존 문서에 병합한다. 프로젝트별 예외도 함께 적어야 한다.
## Karpathy-inspired coding guidelines
- State assumptions before editing when the request is ambiguous.
- Prefer the smallest implementation that meets the stated requirement.
- Do not reformat or refactor unrelated code.
- Define a verification step for every implementation step.
## Project-specific exceptions
- Changes to authentication must include integration tests.
- Generated API clients may be updated only with `npm run generate:api`.
Claude Code의 CLAUDE.md는 강제 정책이 아니라 모델에 제공되는 지침이다. 반드시 차단해야 하는 배포·보안 규칙은 CI, 권한 설정, hook 같은 실행 가능한 장치로 보완한다.
바로 써먹는 프롬프트 세 가지
기능 구현 전
Apply the Karpathy guidelines to this task.
Before editing, list your assumptions and any ambiguous requirements.
Propose the smallest solution, name the files you expect to change,
and attach a verification method to each step. Wait if a decision changes scope.
버그 수정
Reproduce the reported bug first. Define the failing test or observable check,
then make the smallest change that fixes it. Run the focused test and relevant
regression tests. Do not clean up unrelated code. Summarize the final diff.
코드 리뷰
Review this diff using the Karpathy guidelines.
Find hidden assumptions, speculative abstractions, unrelated edits,
and steps without verification. Separate correctness issues from optional ideas.
Do not modify files.
마지막 문장처럼 “파일을 수정하지 말라”는 범위도 명확히 적어야 리뷰 요청이 구현 작업으로 번지는 일을 막을 수 있다.
실전 운영 루틴
작은 팀이라면 다음 흐름만으로도 효과를 확인할 수 있다.
- 작업 시작 전에 성공 조건을 한두 문장으로 적는다.
- 범위가 모호하거나 영향이 큰 작업에서 skill을 호출한다.
- 구현 전에 예상 변경 파일과 검증 방법을 확인한다.
- 구현 후 focused test와 관련 회귀 테스트를 실행한다.
git diff --stat과 실제 diff에서 무관한 변경을 걷어낸다.- PR 설명에 “요청 → 변경 → 검증”의 연결을 남긴다.
효과는 거창한 점수보다 다음 질문으로 측정하는 편이 낫다.
- 요청하지 않은 파일 변경 수가 줄었는가?
- 구현 후 다시 걷어내는 코드가 줄었는가?
- 중요한 전제를 수정 전에 확인했는가?
- 각 변경을 테스트나 관찰 결과로 설명할 수 있는가?
어디까지 믿어야 할까
이 지침은 좋은 기본값이지만 모든 상황의 정답은 아니다.
- 사소한 문구 수정에도 긴 질문과 계획을 요구하면 속도만 느려진다.
- 최소 diff가 구조적 문제를 영원히 미루는 핑계가 되어서는 안 된다. 리팩터링이 필요하면 별도 범위와 성공 조건으로 합의한다.
- 테스트가 잘못된 동작을 고정하면 “테스트 통과”만으로는 충분하지 않다. 사용자 관점의 결과도 확인한다.
- 보안, 데이터 손실, 결제처럼 실패 비용이 큰 영역에서는 단순성보다 방어와 독립 검증이 우선할 수 있다.
- 제3자 plugin은 설치 전 source, manifest, 권한과 업데이트 정책을 직접 검토해야 한다.
또한 이 저장소의 원칙은 “카파시가 보증한 표준”이 아니라 그의 관찰을 재구성한 커뮤니티 해석이다. 이름보다 실제 지침이 프로젝트에 맞는지를 기준으로 채택해야 한다.
최종 체크리스트
- 이 프로젝트가 Karpathy의 공식 배포물이 아님을 이해했다.
- 상황별 사용은 skill, 상시 팀 규칙은
CLAUDE.md로 구분했다. - 설치 전 repository source와 manifest를 확인했다.
- 코딩 전에 모호한 전제와 선택지를 드러냈다.
- 현재 요구를 넘는 추상화와 설정을 추가하지 않았다.
- 모든 변경 줄을 사용자 요청과 연결해 설명할 수 있다.
- 각 구현 단계에 테스트나 관찰 가능한 검증을 붙였다.
- 강제해야 하는 보안·배포 규칙은 CI나 hook으로 보완했다.
andrej-karpathy-skills의 진짜 가치는 새로운 코딩 기법을 가르치는 데 있지 않다. AI가 코드를 많이 쓰는 방향이 아니라, 먼저 생각하고, 필요한 만큼만 바꾸고, 결과를 증명하는 방향으로 작업 리듬을 되돌려 준다는 데 있다.
참고 자료

The hardest problems created by AI coding tools are not always syntax errors. More dangerous patterns include inventing abstractions nobody requested, refactoring neighboring files during a small bug fix, silently interpreting ambiguous requirements, and declaring success without verification.
andrej-karpathy-skills is a compact set of behavioral guidelines designed to reduce those mistakes. It turns ideas from Andrej Karpathy's observations about LLM coding pitfalls into four reusable principles for Claude Code and Cursor.
One clarification matters: this is not an official skill authored by Karpathy. It is an MIT-licensed community project inspired by his observations, and its manifest identifies forrestchang as the author. This guide was verified against the repository's README, SKILL.md, CLAUDE.md, plugin manifest, Cursor rule, and the current Claude Code documentation on August 6, 2026.
What is included?
The same guidance is packaged in three ways.
| File | Target | Behavior | Best use |
|---|---|---|---|
skills/karpathy-guidelines/SKILL.md |
Claude Code plugin | Loaded when relevant or explicitly invoked | On-demand use across projects |
CLAUDE.md |
Claude Code | Loaded as project instructions in every session | Always-on team rules |
.cursor/rules/karpathy-guidelines.mdc |
Cursor | Project rule with alwaysApply: true |
Always-on Cursor guidance |
Claude Code's documentation explains that CLAUDE.md enters every session's context, while a skill body loads only when invoked or considered relevant. Use CLAUDE.md for persistent rules and the skill for situational checklists.
The four principles
1. Think before coding
Do not silently fill gaps in a request. State assumptions, explain competing interpretations, and ask when uncertainty changes the scope.
For “make search faster,” first ask where the delay occurs, what response-time target matters, how large the dataset is, whether stale cached results are acceptable, and what measurement identifies the current bottleneck. Good AI coding begins by avoiding a fast solution to the wrong problem.
2. Prefer simplicity
Solve today's requirement. Avoid a one-use abstraction, an unrequested configuration system, or extension points based only on imagined future needs. If the same result can be expressed clearly in 50 lines instead of 200, reduce it.
Simplicity does not mean skipping necessary validation, error handling, or security. It means removing structure that cannot be justified by the current requirement.
3. Make surgical changes
Do not change quote style, type annotations, comments, or nearby names while fixing one bug. Follow the existing style and modify only lines that are traceable to the request.
After implementation, ask:
Show every changed file and explain how each changed block is required by my request.
Flag any formatting, cleanup, or refactoring that is unrelated.
If a change is difficult to justify, it probably belongs in a separate task. Report unrelated dead code instead of deleting it opportunistically.
4. Execute toward verifiable goals
Replace “improve authentication” with an observable outcome: “write a failing test proving old sessions remain active after a password change, invalidate them, then pass both the new test and existing authentication tests.”
1. Write a reproducing test → confirm it fails
2. Implement the smallest fix → confirm the test passes
3. Run relevant regression tests → confirm existing behavior
4. Review the diff → confirm no unrelated changes
The point is not a long plan. It is attaching a concrete verification method to every step.
Install as a Claude Code plugin
For on-demand use across projects, add the current GitHub repository as a marketplace and install the plugin inside Claude Code:
/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
Choose user for all your projects, project to share with repository collaborators, or local for private use in the current repository. Run /reload-plugins if the installation summary asks you to reload.
Invoke the skill explicitly with:
/andrej-karpathy-skills:karpathy-guidelines
Claude may also load it automatically for relevant coding, review, or refactoring work, but explicit invocation is clearer before high-impact changes.
Verification note: the repository moved to the
multica-aiorganization, while the README still used the olderforrestchangpath when reviewed. This guide uses the current canonical repository path rather than relying on GitHub redirects.
Apply it through CLAUDE.md
To make the rules persistent for a team, merge the repository's CLAUDE.md guidance into your project instructions. Do not overwrite or blindly append to an existing file. Download it separately and review conflicts first.
curl -fsSL \
https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md \
-o /tmp/karpathy-guidelines.md
diff -u CLAUDE.md /tmp/karpathy-guidelines.md
Then keep only the applicable rules and document project-specific exceptions:
## Karpathy-inspired coding guidelines
- State assumptions before editing when the request is ambiguous.
- Prefer the smallest implementation that meets the stated requirement.
- Do not reformat or refactor unrelated code.
- Define a verification step for every implementation step.
## Project-specific exceptions
- Authentication changes must include integration tests.
- Generated API clients may be updated only with `npm run generate:api`.
CLAUDE.md guides model behavior; it is not an enforcement mechanism. Back mandatory deployment and security rules with CI, permissions, or hooks.
Three practical prompts
Before implementing a feature
Apply the Karpathy guidelines to this task.
Before editing, list your assumptions and any ambiguous requirements.
Propose the smallest solution, name the files you expect to change,
and attach a verification method to each step. Wait if a decision changes scope.
For a bug fix
Reproduce the reported bug first. Define the failing test or observable check,
then make the smallest change that fixes it. Run the focused test and relevant
regression tests. Do not clean up unrelated code. Summarize the final diff.
For review
Review this diff using the Karpathy guidelines.
Find hidden assumptions, speculative abstractions, unrelated edits,
and steps without verification. Separate correctness issues from optional ideas.
Do not modify files.
The final scope sentence prevents a review request from turning into an implementation task.
A useful operating routine
- Write one or two observable success criteria before starting.
- Invoke the skill for ambiguous or high-impact work.
- Confirm expected files and verification methods before editing.
- Run focused and relevant regression tests afterward.
- Inspect
git diff --statand the actual diff for unrelated changes. - Connect “request → change → verification” in the pull request description.
Measure improvement with practical questions: Are fewer unrelated files changed? Is less code removed after overengineering? Were important assumptions checked before implementation? Can each change be explained with a test or observable result?
Limits and tradeoffs
- Long clarification and planning slows down trivial edits; use judgment.
- A minimal diff should not become an excuse to defer structural problems forever. Agree on a separate refactoring scope and success criteria.
- Passing tests are insufficient when tests encode the wrong behavior; verify the user-visible result.
- Security, payments, and destructive data operations may require more defense and independent verification than the simplest design.
- Review any third-party plugin's source, manifest, permissions, and update policy before installation.
Most importantly, these guidelines are a community interpretation, not a Karpathy-endorsed standard. Adopt them because the actual behavior fits your project, not because of the name.
Final checklist
- I understand this is not an official Karpathy release.
- I use the skill on demand and
CLAUDE.mdfor persistent team rules. - I reviewed the repository source and manifest before installing.
- Ambiguous assumptions and choices were surfaced before coding.
- No abstraction or configuration exceeds the current requirement.
- Every changed line can be traced to the request.
- Every implementation step has a test or observable verification.
- Mandatory security and deployment rules are enforced by CI or hooks.
The real value of andrej-karpathy-skills is not a new coding technique. It restores a disciplined rhythm: think first, change only what is needed, and prove the result.
References

AI 编程工具最麻烦的问题并不总是语法错误。更危险的是:擅自增加抽象、修复小 Bug 时顺手重构周边文件、默默猜测含糊需求,以及没有验证就宣布完成。
andrej-karpathy-skills 是一套用于减少这些错误的简洁行为准则。它根据 Andrej Karpathy 对 LLM 编程陷阱的观察,整理出四项可供 Claude Code 与 Cursor 复用的原则。
首先要澄清:这不是 Karpathy 亲自发布的官方 skill,而是受其观点启发、采用 MIT 许可证的社区项目;manifest 中的作者为 forrestchang。本文于 2026 年 8 月 6 日核对了仓库 README、SKILL.md、CLAUDE.md、插件 manifest、Cursor rule 及 Claude Code 官方文档。
仓库包含什么
同一套准则提供了三种形式。
| 文件 | 适用工具 | 工作方式 | 推荐场景 |
|---|---|---|---|
skills/karpathy-guidelines/SKILL.md |
Claude Code 插件 | 相关时加载或手动调用 | 多项目按需使用 |
CLAUDE.md |
Claude Code | 每次会话都作为项目指令加载 | 团队长期规则 |
.cursor/rules/karpathy-guidelines.mdc |
Cursor | alwaysApply: true 项目规则 |
Cursor 中持续启用 |
Claude Code 官方文档说明,CLAUDE.md 会进入每次会话的上下文,而 skill 正文只在被调用或判断为相关时加载。因此,长期规则放 CLAUDE.md,情境式检查表放 skill 更合适。
四项核心原则
1. 编码前先思考
不要默默补全需求中的空白。先说明假设;如果存在多种解释,就展示选项和差异;不确定性会改变范围时,先提问。
例如收到“让搜索更快”时,不应立刻加入缓存。先确认瓶颈在输入、API 还是数据库,目标响应时间和数据规模是多少,是否允许短暂过期的缓存,以及现有测量结果是什么。优秀的 AI 编程首先要避免快速解决错误的问题。
2. 简单优先
只解决今天的需求。不要加入只用一次的抽象、未被要求的配置系统,或基于未来想象的扩展点。如果 50 行能清楚完成 200 行的工作,就删减。
简单不等于省略必要的校验、错误处理或安全措施,而是移除无法由当前需求解释的结构。
3. 只做精确修改
修一个 Bug 时,不要顺便改引号风格、类型标注、注释或周边命名。保持现有风格,只修改能追溯到用户请求的行。
Show every changed file and explain how each changed block is required by my request.
Flag any formatting, cleanup, or refactoring that is unrelated.
难以解释的修改通常应属于另一项任务。发现无关的旧代码时,报告它,而不是顺手删除。
4. 面向可验证目标执行
把“改善认证”改写为可观察结果,例如:“先写一个失败测试,证明修改密码后旧会话仍有效;再让旧会话失效,并确保新测试和现有认证测试全部通过。”
1. 编写复现测试 → 确认当前代码失败
2. 实现最小修复 → 确认测试通过
3. 运行相关回归测试 → 确认原有行为
4. 检查 diff → 确认没有无关修改
重点不是写很长的计划,而是为每一步附上明确的验证方式。
作为 Claude Code 插件安装
在 Claude Code 中加入当前 GitHub 仓库作为 marketplace,再安装插件:
/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
user 适用于你的所有项目,project 与仓库协作者共享,local 只在当前仓库由你使用。如果安装摘要要求重载,执行 /reload-plugins。
显式调用名称为:
/andrej-karpathy-skills:karpathy-guidelines
Claude 可能在相关编码、审查或重构任务中自动加载它,但在高影响变更前显式调用更清楚。
核对说明:仓库已迁移到
multica-ai组织,但检查时 README 仍使用旧的forrestchang路径。本文使用当前 canonical 路径,避免依赖 GitHub 重定向。
通过 CLAUDE.md 长期应用
若要把准则作为团队长期规则,请将仓库中的 CLAUDE.md 内容合并到项目指令中。已有文件时不要直接覆盖或盲目追加,应先下载到临时文件并比较。
curl -fsSL \
https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md \
-o /tmp/karpathy-guidelines.md
diff -u CLAUDE.md /tmp/karpathy-guidelines.md
只保留适用规则,并加入项目例外:
## Karpathy-inspired coding guidelines
- State assumptions before editing when the request is ambiguous.
- Prefer the smallest implementation that meets the stated requirement.
- Do not reformat or refactor unrelated code.
- Define a verification step for every implementation step.
## Project-specific exceptions
- Authentication changes must include integration tests.
- Generated API clients may be updated only with `npm run generate:api`.
CLAUDE.md 只是行为指导,不是强制机制。必须执行的安全和部署规则应由 CI、权限或 hooks 保证。
三个实用提示词
功能开发前
Apply the Karpathy guidelines to this task.
Before editing, list your assumptions and any ambiguous requirements.
Propose the smallest solution, name the files you expect to change,
and attach a verification method to each step. Wait if a decision changes scope.
修复 Bug
Reproduce the reported bug first. Define the failing test or observable check,
then make the smallest change that fixes it. Run the focused test and relevant
regression tests. Do not clean up unrelated code. Summarize the final diff.
代码审查
Review this diff using the Karpathy guidelines.
Find hidden assumptions, speculative abstractions, unrelated edits,
and steps without verification. Separate correctness issues from optional ideas.
Do not modify files.
最后一句明确了边界,防止审查请求变成实现任务。
推荐工作流程
- 开始前写一到两个可观察的成功标准。
- 对含糊或高影响任务显式调用 skill。
- 修改前确认预计涉及的文件和验证方法。
- 完成后运行聚焦测试及相关回归测试。
- 用
git diff --stat和实际 diff 排除无关变更。 - 在 PR 中连接“请求 → 修改 → 验证”。
可以用这些问题衡量效果:无关文件是否变少?因过度设计而返工删除的代码是否变少?重要假设是否在实现前得到确认?每项变更能否用测试或可观察结果解释?
限制与取舍
- 对微小文字修改也要求长计划会拖慢速度,应根据风险判断。
- 最小 diff 不能成为永远回避结构问题的借口;需要重构时,应另行确定范围和成功标准。
- 如果测试固化了错误行为,仅“测试通过”仍不够,还要验证用户结果。
- 安全、支付和破坏性数据操作可能需要比最简单设计更多的防御和独立验证。
- 安装第三方插件前,应检查 source、manifest、权限和更新策略。
这些准则是社区解释,不是 Karpathy 背书的标准。应根据实际行为是否适合项目来采用,而不是只看名称。
最终检查表
- 理解这不是 Karpathy 的官方发布。
- 按需使用 skill,长期团队规则放入
CLAUDE.md。 - 安装前检查了仓库 source 和 manifest。
- 编码前暴露了含糊假设和选项。
- 没有超出当前需求增加抽象或配置。
- 每一行修改都能追溯到请求。
- 每一步都有测试或可观察验证。
- 强制安全与部署规则由 CI 或 hooks 执行。
andrej-karpathy-skills 的真正价值并非新的编程技巧,而是让工作节奏回归纪律:先思考,只改必要部分,并证明结果。
参考资料

AIコーディングツールが生む厄介な問題は、構文エラーだけではありません。依頼されていない抽象化を追加する、小さなバグ修正で周辺ファイルまでリファクタリングする、曖昧な要件を黙って推測する、検証せずに完了と宣言する、といった行動のほうが危険です。
andrej-karpathy-skills は、こうしたミスを減らすための簡潔な行動指針です。Andrej KarpathyによるLLMコーディングの落とし穴に関する観察を、Claude CodeとCursorで再利用できる4原則にまとめています。
最初に明確にしておくと、これは Karpathy本人が公開した公式skillではありません。彼の観察に着想を得たMITライセンスのコミュニティプロジェクトで、manifestの作者はforrestchangです。本記事は2026年8月6日時点でREADME、SKILL.md、CLAUDE.md、plugin manifest、Cursor rule、Claude Code公式ドキュメントを照合して作成しました。
リポジトリに含まれるもの
同じ指針が3つの形式で提供されています。
| ファイル | 対象 | 動作 | おすすめ用途 |
|---|---|---|---|
skills/karpathy-guidelines/SKILL.md |
Claude Code plugin | 関連時または明示呼び出し時に読み込み | 複数プロジェクトで必要な時だけ使う |
CLAUDE.md |
Claude Code | 毎セッションのプロジェクト指示として読み込み | チームの常設ルール |
.cursor/rules/karpathy-guidelines.mdc |
Cursor | alwaysApply: true のproject rule |
Cursorで常時適用 |
Claude Code公式文書によれば、CLAUDE.mdは毎セッションのcontextに入り、skill本文は呼び出された時や関連すると判断された時だけ読み込まれます。常設ルールはCLAUDE.md、状況別チェックリストはskillに置くと効率的です。
4つの原則
1. コーディング前に考える
依頼の空白を黙って補完しません。前提を明示し、複数の解釈があれば選択肢と違いを示し、不確実性が範囲を変えるなら質問します。
「検索を速くして」と言われたら、すぐキャッシュを入れるのではなく、遅い箇所、目標応答時間、データ量、古いキャッシュを許容できるか、現在の計測結果を確認します。優れたAIコーディングは、間違った問題を素早く解くことを避けるところから始まります。
2. シンプルさを優先する
今必要な問題だけを解きます。一度しか使わない抽象化、依頼されていない設定、想像上の将来向け拡張点を追加しません。200行を50行で明快に表現できるなら減らします。
シンプルさは必要な検証、エラー処理、セキュリティを省く意味ではありません。現在の要件で説明できない構造を取り除くという意味です。
3. 必要な箇所だけを精密に変更する
1つのバグを直すついでに引用符、型注釈、コメント、周辺の名前まで変更しません。既存スタイルを守り、依頼に直接つながる行だけを修正します。
Show every changed file and explain how each changed block is required by my request.
Flag any formatting, cleanup, or refactoring that is unrelated.
説明しにくい変更は別タスクに分けるべきです。無関係な古いコードを見つけたら、勝手に削除せず報告します。
4. 検証可能な目標に向かって実行する
「認証を改善する」を観察可能な成果に変えます。たとえば「パスワード変更後も旧セッションが有効であることを示す失敗テストを作り、無効化を実装し、新旧の認証テストを通す」と定義します。
1. 再現テストを書く → 現在のコードで失敗を確認
2. 最小修正を実装 → テスト成功を確認
3. 関連回帰テストを実行 → 既存動作を確認
4. diffを確認 → 無関係な変更がないことを確認
長い計画ではなく、各ステップに具体的な確認方法を付けることが重要です。
Claude Code pluginとして導入する
Claude Code内で現在のGitHubリポジトリをmarketplaceとして追加し、pluginをインストールします。
/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
userは自分の全プロジェクト、projectはリポジトリの共同作業者と共有、localは現在のリポジトリで自分だけが使う範囲です。案内が出たら/reload-pluginsを実行します。
明示的な呼び出し名は次のとおりです。
/andrej-karpathy-skills:karpathy-guidelines
関連する実装・レビュー・リファクタリングでClaudeが自動的に読み込む場合もありますが、影響の大きい変更前は明示呼び出しが確実です。
検証メモ:リポジトリは
multica-ai組織へ移動しましたが、確認時のREADMEは旧forrestchangパスを使っていました。本記事ではGitHubのリダイレクトに頼らず、現在のcanonicalパスを使用しています。
CLAUDE.mdで常設する
チームの常設ルールにする場合は、リポジトリのCLAUDE.mdを既存のプロジェクト指示へ統合します。既存ファイルを上書きしたり無条件に追記したりせず、一度別ファイルへ取得して比較します。
curl -fsSL \
https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md \
-o /tmp/karpathy-guidelines.md
diff -u CLAUDE.md /tmp/karpathy-guidelines.md
適用する項目だけを残し、プロジェクト固有の例外も記載します。
## Karpathy-inspired coding guidelines
- State assumptions before editing when the request is ambiguous.
- Prefer the smallest implementation that meets the stated requirement.
- Do not reformat or refactor unrelated code.
- Define a verification step for every implementation step.
## Project-specific exceptions
- Authentication changes must include integration tests.
- Generated API clients may be updated only with `npm run generate:api`.
CLAUDE.mdはモデルの行動を導く文脈であり、強制ポリシーではありません。必須のセキュリティ・デプロイルールはCI、権限、hooksで担保します。
すぐ使える3つのプロンプト
機能実装前
Apply the Karpathy guidelines to this task.
Before editing, list your assumptions and any ambiguous requirements.
Propose the smallest solution, name the files you expect to change,
and attach a verification method to each step. Wait if a decision changes scope.
バグ修正
Reproduce the reported bug first. Define the failing test or observable check,
then make the smallest change that fixes it. Run the focused test and relevant
regression tests. Do not clean up unrelated code. Summarize the final diff.
コードレビュー
Review this diff using the Karpathy guidelines.
Find hidden assumptions, speculative abstractions, unrelated edits,
and steps without verification. Separate correctness issues from optional ideas.
Do not modify files.
最後の一文で範囲を明確にすると、レビュー依頼が実装作業へ広がるのを防げます。
実用的な運用ルーティン
- 開始前に観察可能な成功条件を1〜2文で書く。
- 曖昧または影響の大きい作業でskillを呼び出す。
- 編集前に変更予定ファイルと検証方法を確認する。
- 実装後にfocused testと関連回帰テストを実行する。
git diff --statと実際のdiffで無関係な変更を除く。- PR説明に「依頼 → 変更 → 検証」の対応を残す。
効果は、無関係な変更ファイルが減ったか、過剰設計による手戻りが減ったか、重要な前提を実装前に確認したか、各変更をテストや観察結果で説明できるかで測れます。
限界とトレードオフ
- 小さな文言修正にも長い確認と計画を求めると遅くなるため、リスクに応じて判断します。
- 最小diffを構造問題の永続的な先送りに使ってはいけません。必要なリファクタリングは別の範囲と成功条件で合意します。
- テストが誤った挙動を固定している場合、通過だけでは不十分です。ユーザーから見た結果も確認します。
- セキュリティ、決済、破壊的データ操作では、最小設計より防御と独立検証が優先される場合があります。
- 第三者pluginは、導入前にsource、manifest、権限、更新方針を確認します。
これはコミュニティによる解釈であり、Karpathy公認の標準ではありません。名前ではなく、実際の行動指針がプロジェクトに合うかで採用を判断しましょう。
最終チェックリスト
- Karpathy公式リリースではないことを理解した。
- 状況別にはskill、常設チームルールには
CLAUDE.mdを使う。 - 導入前にリポジトリのsourceとmanifestを確認した。
- コーディング前に曖昧な前提と選択肢を示した。
- 現在の要件を超える抽象化や設定を追加していない。
- すべての変更行を依頼に結び付けて説明できる。
- 各実装ステップにテストまたは観察可能な検証がある。
- 必須のセキュリティ・デプロイルールをCIやhooksで強制する。
andrej-karpathy-skillsの本当の価値は新しいコーディング手法ではありません。先に考え、必要な箇所だけを変え、結果を証明するという規律あるリズムを取り戻す点にあります。
参考資料

Los problemas más peligrosos de las herramientas de programación con IA no siempre son errores de sintaxis. También pueden inventar abstracciones no solicitadas, refactorizar archivos vecinos al corregir un fallo pequeño, interpretar requisitos ambiguos sin avisar y declarar el trabajo terminado sin verificarlo.
andrej-karpathy-skills es un conjunto breve de pautas de comportamiento para reducir esos errores. Convierte las observaciones de Andrej Karpathy sobre los riesgos de programar con LLM en cuatro principios reutilizables para Claude Code y Cursor.
Una aclaración importante: no es un skill oficial creado por Karpathy. Es un proyecto comunitario con licencia MIT inspirado en sus observaciones, y el manifest identifica a forrestchang como autor. Para esta guía, el 6 de agosto de 2026 se verificaron el README, SKILL.md, CLAUDE.md, el manifest, la regla de Cursor y la documentación oficial de Claude Code.
Qué incluye el repositorio
La misma guía se distribuye de tres formas.
| Archivo | Destino | Comportamiento | Uso recomendado |
|---|---|---|---|
skills/karpathy-guidelines/SKILL.md |
Plugin de Claude Code | Se carga cuando es relevante o se invoca | Uso bajo demanda en varios proyectos |
CLAUDE.md |
Claude Code | Se carga como instrucción en cada sesión | Reglas permanentes del equipo |
.cursor/rules/karpathy-guidelines.mdc |
Cursor | Regla con alwaysApply: true |
Aplicación permanente en Cursor |
La documentación de Claude Code indica que CLAUDE.md entra en el contexto de cada sesión, mientras que el cuerpo de un skill solo se carga cuando se usa o se considera relevante. Conviene reservar CLAUDE.md para reglas permanentes y el skill para listas de control situacionales.
Los cuatro principios
1. Pensar antes de programar
No rellenes silenciosamente los huecos de una petición. Expón las suposiciones, muestra interpretaciones alternativas y pregunta cuando la incertidumbre cambie el alcance.
Ante “haz que la búsqueda sea más rápida”, primero identifica dónde está la demora, cuál es el objetivo de respuesta, cuánto crecen los datos, si se acepta una caché temporalmente obsoleta y qué medición demuestra el cuello de botella. Programar bien con IA empieza por evitar resolver deprisa el problema equivocado.
2. Priorizar la simplicidad
Resuelve la necesidad actual. Evita una abstracción de un solo uso, configuraciones no solicitadas o puntos de extensión basados en un futuro imaginario. Si 50 líneas expresan con claridad lo que hacen 200, simplifica.
Simplicidad no significa eliminar validación, tratamiento de errores o seguridad necesarios. Significa retirar estructura que el requisito actual no justifica.
3. Hacer cambios quirúrgicos
No cambies comillas, anotaciones de tipo, comentarios o nombres cercanos al corregir un solo fallo. Respeta el estilo existente y modifica únicamente líneas trazables a la petición.
Show every changed file and explain how each changed block is required by my request.
Flag any formatting, cleanup, or refactoring that is unrelated.
Un cambio difícil de justificar suele pertenecer a otra tarea. Informa del código obsoleto no relacionado en vez de borrarlo de paso.
4. Ejecutar hacia objetivos verificables
Convierte “mejorar la autenticación” en un resultado observable: “crear una prueba fallida que demuestre que una sesión antigua sigue activa tras cambiar la contraseña, invalidarla y pasar tanto la nueva prueba como las pruebas existentes”.
1. Escribir una prueba de reproducción → confirmar que falla
2. Implementar la corrección mínima → confirmar que pasa
3. Ejecutar regresiones relevantes → confirmar el comportamiento existente
4. Revisar el diff → confirmar que no hay cambios ajenos
No se trata de escribir un plan largo, sino de añadir una verificación concreta a cada paso.
Instalarlo como plugin de Claude Code
Dentro de Claude Code, añade el repositorio actual como marketplace e instala el plugin:
/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
Elige user para todos tus proyectos, project para compartirlo con colaboradores o local para usarlo solo tú en este repositorio. Ejecuta /reload-plugins si el resumen de instalación lo solicita.
La invocación explícita es:
/andrej-karpathy-skills:karpathy-guidelines
Claude también puede cargarlo automáticamente en tareas relevantes de implementación, revisión o refactorización, pero una llamada explícita es más clara antes de cambios importantes.
Nota de verificación: el repositorio pasó a la organización
multica-ai, pero el README aún usaba la ruta anteriorforrestchangal revisarlo. Esta guía utiliza la ruta canónica actual para no depender de redirecciones de GitHub.
Aplicarlo mediante CLAUDE.md
Para convertirlo en una regla permanente del equipo, integra el contenido de CLAUDE.md del repositorio en las instrucciones del proyecto. No sobrescribas ni anexes ciegamente un archivo existente; descárgalo por separado y revisa primero los conflictos.
curl -fsSL \
https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md \
-o /tmp/karpathy-guidelines.md
diff -u CLAUDE.md /tmp/karpathy-guidelines.md
Conserva solo las reglas aplicables y documenta excepciones del proyecto:
## Karpathy-inspired coding guidelines
- State assumptions before editing when the request is ambiguous.
- Prefer the smallest implementation that meets the stated requirement.
- Do not reformat or refactor unrelated code.
- Define a verification step for every implementation step.
## Project-specific exceptions
- Authentication changes must include integration tests.
- Generated API clients may be updated only with `npm run generate:api`.
CLAUDE.md orienta al modelo; no impone una política. Refuerza las reglas obligatorias de seguridad y despliegue con CI, permisos o hooks.
Tres prompts prácticos
Antes de implementar
Apply the Karpathy guidelines to this task.
Before editing, list your assumptions and any ambiguous requirements.
Propose the smallest solution, name the files you expect to change,
and attach a verification method to each step. Wait if a decision changes scope.
Para corregir un fallo
Reproduce the reported bug first. Define the failing test or observable check,
then make the smallest change that fixes it. Run the focused test and relevant
regression tests. Do not clean up unrelated code. Summarize the final diff.
Para revisar código
Review this diff using the Karpathy guidelines.
Find hidden assumptions, speculative abstractions, unrelated edits,
and steps without verification. Separate correctness issues from optional ideas.
Do not modify files.
La última frase fija el alcance y evita que una revisión se convierta en implementación.
Rutina de trabajo recomendada
- Escribe uno o dos criterios de éxito observables.
- Invoca el skill en tareas ambiguas o de alto impacto.
- Confirma archivos previstos y métodos de verificación antes de editar.
- Ejecuta pruebas enfocadas y regresiones relevantes al terminar.
- Examina
git diff --staty el diff real para detectar cambios ajenos. - Conecta “petición → cambio → verificación” en la descripción del PR.
Mide la mejora con preguntas concretas: ¿se modifican menos archivos no relacionados?, ¿se elimina menos código después por exceso de diseño?, ¿se validan las suposiciones importantes antes de implementar?, ¿cada cambio se explica con una prueba o resultado observable?
Límites y compromisos
- Una planificación larga ralentiza cambios triviales; aplica criterio según el riesgo.
- Un diff mínimo no debe servir para aplazar problemas estructurales indefinidamente. Acuerda un alcance y criterios separados para la refactorización.
- Las pruebas no bastan si fijan un comportamiento incorrecto; verifica también el resultado visible para el usuario.
- Seguridad, pagos y operaciones destructivas pueden necesitar más defensas y verificación independiente que el diseño más simple.
- Antes de instalar un plugin externo, revisa source, manifest, permisos y política de actualización.
Estas pautas son una interpretación comunitaria, no un estándar respaldado por Karpathy. Adóptalas porque su comportamiento encaja con tu proyecto, no por el nombre.
Lista final
- Entiendo que no es una publicación oficial de Karpathy.
- Uso el skill bajo demanda y
CLAUDE.mdpara reglas permanentes. - Revisé el source y el manifest antes de instalar.
- Expuse suposiciones y opciones ambiguas antes de programar.
- No añadí abstracciones ni configuración más allá del requisito actual.
- Cada línea modificada se puede vincular con la petición.
- Cada paso tiene una prueba o verificación observable.
- CI o hooks imponen las reglas obligatorias de seguridad y despliegue.
El valor real de andrej-karpathy-skills no es una técnica nueva. Recupera un ritmo disciplinado: pensar primero, cambiar solo lo necesario y demostrar el resultado.