solid-principles
Installation
SKILL.md
SOLID Principles — Learn · Apply · Verify
Purpose
Help a developer understand why a design choice matters and help a coding agent make only justified, testable changes. This skill is a design lens, not a mandate to introduce interfaces, layers, or patterns.
Route the request
- LEARN: The user asks to explain, compare, practice, quiz, or understand SOLID. Start with their language and experience level. Use
references/principles.mdand the examples. Explain one principle at a time if appropriate; teach a concrete failure mode, a minimal improvement, trade-offs, and a check-for-understanding. Do not edit project files. - APPLY: The user asks to implement, review, or refactor real code. Inspect relevant files, tests, callers, project conventions, and observable contracts first. Only then evaluate SOLID and propose the smallest useful change. See
references/review-checklist.md. - VERIFY: The user asks to assess a proposed design, code change, or AI-generated output. Compare before/after behavior, interfaces and consumers, meaningful tests, and unnecessary complexity. See
references/verification.md. - MIXED: Explain a concept briefly, apply it to evidence in the project, then verify. If actual code is unavailable, label examples as hypothetical and do not claim repository findings.
Core definitions, used carefully
- SRP — Single Responsibility: A module should have one coherent reason to change (one actor or policy responsibility), not merely one method.
- OCP — Open/Closed: Stable code should permit needed variations through appropriate extension points; don't introduce abstractions for speculative variations.
- LSP — Liskov Substitution: A subtype must preserve the observable promises of its base contract, including preconditions, postconditions, and invariants.
- ISP — Interface Segregation: Clients should not be forced to depend on operations they do not need; prefer cohesive contracts.
- DIP — Dependency Inversion: High-level policy and lower-level details should depend on suitable abstractions when that boundary has practical value. Dependency injection is one possible technique, not the definition of DIP.