anti-overengineering

Enforces minimal code solutions by applying a YAGNI decision ladder to coding tasks.

Updated Jul 11, 2026
One-click install
npx skills add https://github.com/azishio/coding-skills --skill anti-overengineering-azishio
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: anti-overengineering
Source: https://github.com/azishio/coding-skills/tree/main/skills/anti-overengineering
Command: npx skills add https://github.com/azishio/coding-skills --skill anti-overengineering-azishio

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate unnecessary abstractions, speculative features, redundant dependencies, and boilerplate that increase maintenance cost. This Skill constrains every coding task to the smallest correct solution by forcing a decision ladder before any code is written. ## Core Features & Use Cases - YAGNI Decision Ladder: Before writing code, it checks whether the feature needs to exist, whether the codebase, standard library, platform, or an installed dependency already covers it, and whether a mature library beats a custom implementation. - Root-Cause Bug Fixing: Requires tracing all callers of a function before editing, so fixes land once in the shared path instead of patching individual symptoms. - Dependency Discipline: Enforces one library per job, prefers maintained libraries over hand-rolled implementations for edge-case-heavy logic, and marks deliberate shortcuts with an anti-overengineering: comment naming the ceiling and upgrade path. - Use Case: When asked to add a cache for API responses, it responds with the minimal answer: no cache until profiling proves the need, then @lru_cache rather than a hand-rolled TTL cache class. ## Quick Start Ask the assistant to implement or review a code change using the anti-overengineering skill so it ships the smallest working solution.

Frequently Asked Questions about anti-overengineering

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

FAQPage Schema
How do I avoid over-engineering when writing new code?▼

Apply a decision ladder before coding: check if the feature needs to exist, if the codebase already has it, if the standard library or platform covers it, and if an installed dependency solves it. Write only the minimum code that works after those checks fail.

When should I use a library instead of writing custom code?▼

Use a mature maintained library for anything with edge cases: algorithms, parsers, protocols, formats, and validation. Write your own code only for a few lines of glue or small domain-specific logic, deciding by total maintenance cost rather than dependency count.

How do I fix a bug at the root cause instead of the symptom?▼

Grep every caller of the function you plan to change before editing. Place one guard in the shared function where all callers route through, rather than patching only the path named in the bug report, which leaves sibling callers broken.

What should never be simplified away in minimal code?▼

Never cut input validation at trust boundaries, error handling that prevents data loss, security measures, accessibility basics, or anything explicitly requested. Minimalism applies to solution size, not to correctness or safety.

Does minimal code still need tests?▼

Non-trivial logic such as branches, loops, parsers, or money and security paths needs one small runnable check, like an assert-based self-check or a single test file. Trivial one-liners need no test, and full test frameworks are only added when requested.