Simplicity first
Stop Claude Code from hallucinating — Karpathy-grade discipline in 8 skills
npx -y skills add fbsmna-coder/karpathy-pro-max --skill simplicity-firstAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write the minimum code that solves the stated problem. Use when implementing features, fixing bugs, or refactoring — to prevent speculative abstractions, configurability nobody asked for, and error handling for impossible scenarios.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.6 KB, as published. Nobody here has run it
Simplicity First
LLMs overengineer by default. They add factories, options bags, plugin hooks, and graceful degradation for failure modes that cannot occur in the actual environment. This skill enforces minimum viable code.
The test
Before submitting a diff, ask: "Would a senior engineer say this is overcomplicated?" If yes, rewrite.
What to cut
- Features beyond what was asked. ("While I'm here, I added retry logic.")
- Abstractions for single-use code. (No
BaseHandlerfor one handler.) - Configurability nobody requested. (No env vars, no options dict, no strategy pattern.)
- Error handling for impossible scenarios. (No
try/exceptaround code that cannot raise. No null checks on values guaranteed by the type system.) - Comments that restate the code. (
# increment counterabovecounter += 1.) - Backwards-compatibility shims for code with one caller you control.
What to keep
- Validation at real system boundaries: user input, external APIs, file I/O.
- Comments that explain why something non-obvious is the way it is.
- Abstractions with ≥3 actual current callers (not "future" callers).
Heuristic
If the diff is 200 lines and you can imagine a 50-line version, write the 50-line version. Ship that. The 200-line version is not "more robust" — it is more surface area for bugs.
When NOT to apply
- Production systems with hard reliability requirements (banking, medical, infra) — extra defensive coding is the job.
- Code that is genuinely a framework / library with multiple downstream consumers.
- Performance-critical paths where the "complex" version is measurably faster.
Example
Bad (47 lines):
class UserFetcher:
def __init__(self, db, cache=None, logger=None, retry_count=3):
self.db = db
self.cache = cache or NoOpCache()
self.logger = logger or logging.getLogger(__name__)
self.retry_count = retry_count
def fetch(self, user_id):
if not isinstance(user_id, int):
raise TypeError(...)
# ... 35 more lines
Good (3 lines):
def fetch_user(db, user_id):
return db.execute("SELECT * FROM users WHERE id = ?", (user_id,)).fetchone()
The first version anticipates needs that do not exist. The second can be expanded when those needs appear.