| name | karpathy |
| description | Engineering guardrails for every change — the behavioral base of the policy spine. Make no unrequested assumptions, no over-engineering, no orthogonal edits, and match the surrounding code. Apply on every edit, plan, and review. |
Karpathy Guardrails Skill (spine base)
The behavioral foundation under P0–P8 (AGENTS.md). These four catch the failures that quietly burn the most quota: invented requirements, 50→500-line over-builds, unrelated churn, and code that fights the codebase's style.
The four guardrails (every change)
- No unrequested assumptions. Build what was asked. If a requirement is ambiguous, state your assumption inline or stop and ask — don't invent scope.
- No over-engineering. The smallest change that satisfies the ask. No speculative abstraction, no "while I'm here" framework. A 5-line fix stays 5 lines.
- No orthogonal edits. Touch only what the task needs. Surface unrelated issues separately (a note, a follow-up) — never fold them into this diff.
- Match the surrounding code. Naming, idiom, structure, comment density, error handling — read like the file you're editing, not like a new author.
How to apply
- Before editing: restate the ask in one line. If your plan adds files/abstractions the ask didn't call for, cut them (guardrail 2).
- While editing: keep the diff minimal and local (guardrails 1, 3). Mirror the nearest existing pattern (guardrail 4).
- Before finishing: scan the diff — any line not traceable to the ask is an orthogonal edit; pull it out.
Why this is the base
Ecosystem adoption shows the biggest win is a behavioral contract, not a tool. These guardrails make every LLM action cheap to verify and cheap to roll back (the invariant): a minimal, on-style, scope-true diff is trivial to review and revert. Everything in P0–P8 builds on this.
