karpathy-guidelines

Provides behavioral guidelines for LLMs writing, reviewing, or refactoring code to reduce mistakes.

Updated Apr 1, 2026
One-click install
npx skills add https://github.com/RugkeyPro/agent-skills --skill karpathy-guidelines-rugkeypro
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: karpathy-guidelines
Source: https://github.com/RugkeyPro/agent-skills/tree/main/karpathy-guidelines
Command: npx skills add https://github.com/RugkeyPro/agent-skills --skill karpathy-guidelines-rugkeypro

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Behavioral guidelines to reduce common LLM coding mistakes, helping teams avoid overcomplication, surface hidden assumptions, and define verifiable success criteria when writing, reviewing, or refactoring code.

Core Features & Use Cases

  • Surface assumptions explicitly before implementing.
  • Surface tradeoffs and push back when warranted to avoid unnecessary changes.
  • Surgical changes: modify only what's needed to preserve existing behavior.
  • Define and verify success criteria with clear plans.

Quick Start

Apply these guidelines before starting a coding task to surface assumptions and define verifiable success criteria.

Frequently Asked Questions about karpathy-guidelines

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent LLM coding mistakes during code refactoring?

Prevent LLM coding mistakes during refactoring by enforcing surgical changes that modify only what is needed, surfacing hidden assumptions explicitly, and defining verifiable success criteria before implementation.

What are surgical changes in LLM code generation?

Surgical changes in LLM code generation mean modifying only what is needed to fix an issue or add a feature, intentionally preserving existing behavior to avoid overcomplication and reduce unintended side effects.

How do I surface hidden assumptions when using LLM to write code?

Surface hidden assumptions when using an LLM to write code by requiring explicit assumption statements before implementation, pushing back on unnecessary changes, and defining measurable success criteria.

Does this approach work for both writing new code and reviewing existing code?

Yes, these guidelines apply during writing, reviewing, or refactoring code, providing behavioral rules to surface tradeoffs, push back when warranted, and define verifiable success criteria across all stages.

What is the best way to define verifiable success criteria for LLM coding tasks?

Define verifiable success criteria for LLM coding tasks by establishing a clear plan with measurable checks before implementation, ensuring goal-driven execution and avoiding overcomplication.

Why do LLMs make unnecessary changes when refactoring code?

LLMs make unnecessary changes when refactoring because they lack behavioral guidelines for surgical changes, leading to overcomplication. Applying explicit tradeoff surfacing and goal-driven execution prevents this.