| name | kiss |
| description | When writing or reviewing code to reduce complexity and improve readability. Use when the user says "simplify this," "too complex," "hard to read," "clean up," "what does this do," or "can't follow this code." For over-engineering concerns, see yagni. For structural clarity, see separation-of-concerns. |
| metadata | {"version":"1.0.0"} |
KISS — Keep It Simple
Before Applying
If .agents/stack-context.md exists, read it first. Apply this principle using idiomatic patterns for the detected stack. For framework-specific details, use context7 MCP or web search — don't guess.
Principle
Given two solutions that produce the same result, prefer the one that is easier to read, understand, and change.
Why This Matters in Production
Simple code survives contact with production. Complex code breaks in ways that are hard to diagnose, hard to fix, and hard to verify the fix didn't break something else. Every incident response starts with someone reading code under pressure — if they can't understand it quickly, the outage gets longer.
Complexity compounds. A "slightly clever" solution today becomes an "incomprehensible" solution after six months of patches by three different developers.
The most dangerous bugs hide in code that's too complex for any single person to hold in their head.
Rules
- Optimize for reading, not writing. Code is read 10x more often than it's written. A few extra lines of clear code beats a one-liner that requires a comment to explain.
- Use boring technology. Prefer well-understood tools, patterns, and libraries over novel ones. Novel solutions carry hidden costs in debugging, hiring, and documentation.
- Limit nesting depth. If a function has more than 3 levels of nesting, flatten it with early returns, guard clauses, or extraction into helper functions.
