@Saccc_c: Haven't configured Agents.md in Codex yet? You can directly copy Karpathy's homework — a 65-line minimal configuration that is concise and effective, perfect as a starting point for your global Agents.md rules. How to do it: directly copy this specification from the repository into Codex App's global custom...
Summary
Sharing Andrej Karpathy's 65-line minimal Agents.md configuration that can be directly copied into Codex App's global custom instructions as a starting point to improve AI coding agent behavior.
View Cached Full Text
Cached at: 05/24/26, 10:20 AM
If you haven’t set up Agents.md in Codex yet, you can directly copy homework from the great Karpathy.
A minimalist 65-line configuration with concise and effective content—perfect as a starting point for your global Agents.md rules.
How to do it:
Simply copy this set of guidelines from the repo into Codex App’s global custom instructions section. Then, following the methods in the article below, continuously expand and iterate on the rules. Your Codex usage will already surpass most people.
Repo URL: https://github.com/multica-ai/andrej-karpathy-skills
multica-ai/andrej-karpathy-skills
Source: https://github.com/multica-ai/andrej-karpathy-skills
Karpathy-Inspired Claude Code Guidelines
Check out my new project Multica (https://github.com/multica-ai/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 (https://x.com/karpathy/status/2015883857489522876) 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:
``
- [Step] → verify: [check]
- [Step] → verify: [check]
- [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:
bash curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
Existing project (append):
bash 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 Execution” principle captures this: transform imperative instructions into declarative goals with verification loops.
How to Know It’s Working
These guidelines are working if you see:
- Fewer unnecessary changes in diffs — Only requested changes appear
- Fewer rewrites due to overcomplication — Code is simple the first time
- Clarifying questions come before implementation — Not after mistakes
- Clean, minimal PRs — No drive-by refactoring or “improvements”
Customization
These guidelines are designed to be merged with project-specific instructions. Add them to your existing CLAUDE.md or create a new one.
For project-specific rules, add sections like:
``markdown
Project-Specific Guidelines
- Use TypeScript strict mode
- All API endpoints must have tests
- Follow the existing error handling patterns in
src/utils/errors.ts``
Tradeoff Note
These guidelines bias toward caution over speed. For trivial tasks (simple typo fixes, obvious one-liners), use judgment — not every change needs the full rigor.
The goal is reducing costly mistakes on non-trivial work, not slowing down simple tasks.
License
MIT
Similar Articles
@Av1dlive: If you haven't set up Agents.md in Codex yet you can just copy the homework from Andrej Karpathy. Here's the exact setu…
A quick tip showing how to copy Andrej Karpathy's 65-line Agents.md config into Codex Global Custom Instructions for an effective minimalist setup.
@web3chacha: This repo is essentially for Claude Code. As a global Codex prompt, it requires the principle of brevity. If needed in specific projects, add project rules, such as test commands, code style, directory conventions. This way, Codex won't become overly cautious, nor will it conflict with existing system instructions. The principle of brevity is posted in the comments...
Discusses how to use a concise global Codex prompt for Claude Code to avoid over-cautiousness, citing Karpathy's 65-line Agents.md configuration as an example.
@DivyanshT91162: You can clone Andrej Karpathy’s entire AGENTS.md workflow into Codex in under 2 minutes. Just: 1. Open his repo 2. Copy…
A tweet explains how to clone Andrej Karpathy's AGENTS.md workflow into Codex by pasting the 65-line file into Global Custom Instructions, making Codex behave more like a structured autonomous coding agent.
@mylifcc: OpenAI has made the AGENTS.md of the Codex project public on GitHub! This is their internal development guide for the Rust codebase (codex-rs), packed with high-value content including code style, module governance, testing strategies, App-server API design, Mod...
OpenAI has publicly released the AGENTS.md development guide for the Codex project, covering internal specifications and governance details for the Rust codebase.
@ErdalToprak: https://x.com/ErdalToprak/status/2057871169702027462
A detailed guide on setting up custom subagents for Codex, using a grid of six generic agents with varying effort and permission levels, plus a mission card pattern for efficient task delegation.