Apply Andrej Karpathy-style coding discipline: think before coding, prefer simplicity, make surgical changes, and stay goal-driven.
This skill adapts the ideas from the `andrej-karpathy-skills` repository into a Codex-friendly workflow.
Use it when you want disciplined execution with less overengineering, smaller diffs, and tighter alignment to the actual goal.
<Use_When>
The user asks for "Karpathy-style", "simple and surgical", or "don't overengineer"
The task is easy to overcomplicate with abstractions or broad refactors
You are about to modify a codebase with unclear side effects and want tighter discipline
You need to keep changes minimal while still finishing the job end-to-end
</Use_When>
<Do_Not_Use_When>
The user explicitly wants broad redesign, large-scale refactor, or exploratory architecture work
The task is purely creative writing with no engineering decision-making
A larger systems redesign is already approved and minimalism would be counterproductive
</Do_Not_Use_When>
<Core_Principles>
1. Think Before Coding
Restate the real goal in one or two sentences before editing
Identify the smallest surface that can solve the problem
Check what already exists before inventing a new pattern
Do not code from a vague hunch when the codebase can answer the question directly
2. Simplicity First
Prefer the simplest solution that fully solves the problem
Reuse existing modules, conventions, and utilities before adding new ones
Avoid speculative abstractions, premature optimization, and "frameworking"
If two approaches work, prefer the one that is easier to explain and easier to delete later
3. Surgical Changes
Touch as few files and symbols as possible
Keep behavior changes narrow and intentional
Avoid drive-by edits unless they are required for correctness
Preserve surrounding code patterns unless there is a strong reason to unify or fix them
4. Goal-Driven Execution
Judge progress by whether the user goal is solved, not by how much code was produced
Verify the concrete outcome after changes
Call out remaining risks or gaps clearly instead of hiding them behind large edits
Stop once the goal is met; do not keep polishing unrelated areas
</Core_Principles>
<Execution_Checklist>
Before editing:
State the target outcome
Identify the smallest likely change set
Inspect existing code paths and constraints
While editing:
Keep diffs compact
Prefer modification over invention
Avoid renaming, moving, or restructuring unless necessary
Before finishing:
Verify the user-facing outcome
Summarize what changed in plain language
Name any residual risks, edge cases, or untested paths
</Execution_Checklist>
<Behavioral_Defaults>
Bias toward deletion over addition when safe
Treat complexity as a cost that must be justified
Avoid introducing new dependencies unless the user asked for them or the task truly requires them
Do not confuse "thorough" with "large"
When unsure, choose the more reversible path
</Behavioral_Defaults>
<Suggested_Phrases>
When activating this skill mentally, aim for these questions:
"What is the smallest change that solves the real problem?"
"Can I reuse what is already here?"
"Am I changing this because it is necessary, or because it is tempting?"
"Does this help the user outcome, or just make the code look different?"
</Suggested_Phrases>
Adapted from:
- https://github.com/vtroisWhite/andrej-karpathy-skills
- repository guidance centered on Think Before Coding, Simplicity First, Surgical Changes, and Goal-Driven Execution
