engineering-standardslisted

# engineering-standards The goal is always the same: **solve the problem with the least code and the least complexity that actually solves it.** Not the cleverest solution, not the most extensible one — the one a senior engineer would defend in review. Every rule below is phrased as a *checkable test*, not a slogan: if you can't run the test, the rule doesn't apply; if the test fails, change the code. **The repo overrides.** A documented repo standard (CLAUDE.md, AGENTS.md, `runbooks/`, contributing docs, lint config) always wins over this baseline. This skill fills the gaps; it never argues with the repo. ## The tests 1. **The deletion test** — imagine deleting the module/abstraction/layer. If the complexity vanishes, it was a pass-through: delete it for real. If the complexity reappears spread across N callers, it was earning its keep. 2. **The two-adapters rule** — one implementation behind an interface is a hypothetical seam; two is a real one. Don't introduce an interface, strategy, plugin point, or config flag unless something *actually varies* across it today. "We might need it later" fails this test by definition (YAGNI). 3. **The inline test** — could this helper/wrapper/abstraction be inlined at its call sites with *less total code*? Then inline it. Indirection must pay for itself in removed duplication or hidden complexity. 4. **The diff test** — is every hunk in the diff required by the stated goal? Drive-by refactors, "while I'm here" cleanups, renamed variab