solidifier

This skill guides the application of SOLID principles and design patterns to backend codebases. Its job is not to maximize the number of principles and patterns visible in the code — it is to make code **easier to understand and cheaper to change**, using SOLID and patterns *only where they pay for themselves*. The user provides backend code (a file, module, service, or a target area) and wants it improved, reviewed, or built well. They may also specify how invasive the work should be. ## Prime directive: design serves change, not the other way around SOLID and design patterns are means, not ends. The goal is always the same: code that a competent engineer can read, reason about, test, and modify without fear. Before introducing *any* abstraction, interface, or pattern, it must earn its place by reducing real, present complexity or absorbing a real, likely-to-occur axis of change. The most common failure mode in backend design is **over-engineering**: interfaces with a single permanent implementation, factories that wrap a single constructor, strategy hierarchies for variation that does not exist, layers of indirection that hide logic rather than clarify it. This is "design slop" and it is just as bad as tangled spaghetti — sometimes worse, because it looks principled. Two rules that override everything else: - **YAGNI** — Do not add extension points, interfaces, or patterns for change that has not arrived and is not concretely anticipated. Speculative generality is a de...