multica-ai/andrej-karpathy-skills

If your coding agent keeps inventing requirements, expanding a small fix into a refactor, or touching files you never mentioned, this is a low-commitment prompt file worth reading before trying. It is not tooling in the usual sense: four behavioral principles in one Markdown file, adapted from Andrej Karpathy's complaints about LLM coding habits.

The problem

You ask for a validation check or a bug fix. The agent guesses at an ambiguous requirement, builds an abstraction layer, edits neighboring comments, and hands back a diff far larger than the task. Reviewing that diff takes longer than writing the change yourself, and the next session repeats the pattern. This project tries to shift that step: instead of accepting whatever interpretation the agent picks, the file tells it to state assumptions, offer interpretations, push back on unnecessary complexity, and tie work to tests. The intended result is a smaller, more predictable diff that is quicker to review.

What's different

The mechanism is purely instructional, which is both the appeal and the catch. The four principles map directly to observed failure modes: thinking before coding addresses silent assumptions and missing tradeoffs, simplicity first counters overengineering, surgical changes limits edits to the requested scope, and goal-driven execution converts imperatives like "fix the bug" into verification loops. The README is explicit about the bias: it favors caution over speed and says trivial one-liners should use judgment rather than full rigor project instructions. The principles are drawn from Karpathy's post on models that don't surface confusion or present tradeoffs Karpathy's observations. Because the file is plain Markdown with no dependencies, you can read all of it in minutes and merge only the parts you want — the README describes combining it with project-specific rules customization guidance. The trade-off is that compliance depends entirely on the model and harness honoring instructions; nothing enforces the rules, and an agent can still ignore them under pressure from a large task. There is also a documented path for Cursor users through a committed project rule and a separate guide Cursor guide.

Who should try it

Good fit: developers who use Claude Code daily on existing codebases and keep cleaning up drive-by edits and speculative abstractions, especially those who can articulate project-specific rules and merge them. Poor fit: anyone expecting a linter, hook, or enforced policy that fails a build when the agent misbehaves; or people who mainly ask for large greenfield scaffolding, where a cautious instruction set may clash with the work. Teams that want the same behavior in another editor can use the Cursor rule path, but they should expect to maintain two copies of the guidance.

Requirements and limitations

Adoption is cheap: either install the Claude Code plugin from the marketplace, or copy or append the single CLAUDE.md into a project install instructions. For Cursor, the repository carries a committed rule file and a setup guide Cursor setup. Setup itself is trivial; the ongoing work is keeping generic principles from drowning under project-specific instructions, and remembering that the guidelines deliberately slow non-trivial changes. No license file is present in the repository metadata even though the README lists an MIT license — a discrepancy worth resolving before vendoring the text into a company-managed repo. The README does not document how to measure whether the rules are working beyond diff-size observations such as fewer unnecessary changes and clean PRs. Anyone assessing it should treat the principles as a review checklist rather than a guarantee.

HotRepo's take

HotRepo has one recorded observation: the repository was #13 on the weekly all-languages board with +2,981 stars for the week ending 2026-10-25 project signals. That single dated snapshot supports that it was drawing attention, but no daily-board history exists, so persistence cannot be judged. The file is short enough to evaluate directly: read the CLUADE.md and check whether its four principles conflict with your team's existing agent instructions before adopting it broadly.