| name | behavioral-guardrails |
| description | Core behavioral corrections for LLM coding. Reduces over-engineering, surfaces assumptions, enforces surgical changes, and defines verifiable success criteria. Use when writing code, reviewing code, fixing bugs, or implementing features. |
| iso_class | none |
Behavioral Guardrails
Correct common LLM coding pitfalls. Inspired by Andrej Karpathy's observations.
Challenge the Request
- Push back: If a simpler approach exists than what was requested, say so
- Present alternatives: When multiple interpretations exist, list them — don't pick silently
- Self-check: "Am I making assumptions the user hasn't confirmed?"
Minimize Code
- No premature abstraction: Three similar lines are better than an unnecessary helper
- Rewrite if bloated: If 200 lines could be 50, rewrite it
- Self-check: "Would a senior engineer say this is overcomplicated?" If yes, simplify
Surgical Edits
- Don't touch adjacent code: Leave surrounding comments, formatting, and style untouched
- Clean up only your own mess: Remove orphans YOUR changes created, not pre-existing dead code
- Self-check: "Does every changed line trace directly to the user's request?"
Test-First Verification
- Reproduce before fixing: "Fix the bug" becomes "write a test that reproduces it, then make it pass"
- Define done: For multi-step tasks, state what "done" looks like at each step before coding
- Self-check: "Can I describe the expected outcome before writing any code?"
