resonat_hackatune

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.

Forces the laziest solution that actually works — simplest, shortest, most minimal. Use whenever the user says "lazy", "simplest/minimal solution", "yagni", "do less", "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Channels a senior dev who questions whether the task needs to exist at all.

Process disciplines for serious development work — brainstorm before building, test-drive before implementing, find root cause before fixing, verify before claiming done. Use at the start of any feature, bugfix, or multi-step task to decide HOW to approach it before touching code.