Solid Enforcer

SOLID Enforcer (Generation + Review + Refactor)

Purpose

Ensure produced or modified code adheres to SOLID, with designs that are extensible, testable, and maintainable. This skill is used both to:

1. Generate new code that is SOLID by construction, and
2. Refactor/review existing code to become more SOLID without breaking behavior.

When to activate

Activate when the task includes any of:

• refactor / redesign / architecture changes
• “make it SOLID”, “clean up responsibilities”, “reduce coupling”
• adding extension points / plugin systems / strategies / policies
• replacing large conditionals or type switches
• improving testability, DI, interface boundaries, modularity
• PR review focused on design/maintainability

Operating mode (must follow)

1. Clarify (max 1–3 questions) if requirements or constraints are ambiguous (behavioral invariants, extension expectations, performance constraints, public API stability).
2. Plan first for non-trivial changes:
   • identify files/modules to touch
   • state invariants and “must not change” behaviors
   • propose refactor steps with checkpoints (tests/typing/lint)
3. Implement in small, verifiable steps:
   • keep diffs tight
   • preserve stable logic
   • add/adjust tests as proof
4. Prove correctness:
   • add unit tests demonstrating contracts
   • run/describe the minimal commands to validate (tests, typecheck, lint)
5. Return complete output:
   • runnable files (or clear patches)
   • tests
   • short SOLID rationale (how SRP/OCP/LSP/ISP/DIP are satisfied)

SOLID baseline constraints (always enforce)

• Prefer composition over inheritance unless full substitutability is guaranteed.
• Keep classes/modules small; if a unit grows rapidly, challenge responsibilities.
• Make dependencies explicit (constructor/params). Avoid new in business logic; use DI/factories.
• Return complete, runnable files and tests proving the contract.

Principle checklists

SRP — Single Responsibility

Pass if:

1. Each class/module has one reason to change.
2. Logging/validation/error-handling are separated from domain logic.
3. Methods do one thing; if a description needs “and/or”, split it.

Common fixes:

• Extract validation into validators/policies
• Extract I/O (HTTP/DB/files) into adapters/clients
• Split orchestration (use-case/service) from pure domain objects

OCP — Open/Closed

Pass if:

1. New behaviors can be added by adding new implementations, not editing stable logic.
2. Replace type-based switches with polymorphism (strategy/decorator/handlers).

Common fixes:

• Strategy pattern: Policy / Algorithm interface + implementations
• Decorator: wrap behavior without editing core
• Registration/dispatch tables (map keys -> handlers) where appropriate

LSP — Liskov Substitution

Pass if:

1. Subtypes preserve invariants.
2. No tighter preconditions / no looser postconditions.
3. No “noop/throw overrides” that violate expectations.

Common fixes:

• Split base interface into smaller role interfaces (often pairs with ISP)
• Prefer composition if inheritance requires exceptions
• Add contract tests for substitutability (same test suite for all impls)

ISP — Interface Segregation

Pass if:

1. Interfaces are minimal and client-specific.
2. “Fat” interfaces are split; clients depend only on what they use.

Common fixes:

• Break one large interface into role interfaces
• Compose roles into larger façades only where needed

DIP — Dependency Inversion

Pass if:

1. High-level modules depend on abstractions, not concretions.
2. Interfaces are defined near the clients (ports), implementations elsewhere (adapters).
3. Construction is pushed to the composition root; business logic receives dependencies.

Common fixes:

• Constructor/parameter injection
• Factories/providers passed in (not created inside domain logic)
• In TS: avoid importing concrete implementations into core domain/use-cases
• In Python: avoid instantiating clients inside use-case functions; inject them

Refactor playbook (preferred approach)

1. Identify responsibilities and seams:
   • what is domain logic vs infrastructure vs orchestration?
2. Introduce abstractions only where they enable extension/testability:
   • define small interfaces (ports) at the boundary
3. Replace conditionals with strategies/handlers:
   • keep stable logic unchanged; move variability behind an interface
4. Push object creation outward:
   • create a composition root (factory/module) for wiring
5. Lock behavior with tests before/after:
   • contract tests for interfaces
   • regression tests for prior behavior

Output contract (what to return)

Always return:

1. Code + unit tests that demonstrate the contract.
2. A short rationale explicitly answering:
   • SRP: what responsibilities were separated?
   • OCP: what is now extensible without edits to stable logic?
   • LSP: how substitutability is preserved (or why inheritance was avoided)?
   • ISP: how interfaces were slimmed/split?
   • DIP: what dependencies are injected and where is wiring done?
3. If relevant: a minimal example showing how to extend via a new implementation.

Red flags (must call out and fix)

• Business logic instantiates concretes (new, direct client creation) rather than receiving deps.
• Large modules/classes growing in responsibilities.
• Type switches/if-chains driving behavior selection across the codebase.
• Inheritance hierarchies with special-case overrides or exceptions.