ramziddin/solid-skills
Overview
This skill transforms junior-level code into senior-engineer quality software by enforcing SOLID principles, test-first development, clean code, and pragmatic architecture. It is meant to be applied on every coding task—features, refactors, reviews, and debugging—to produce maintainable, testable, and change-resilient systems. The focus is practical: small, testable units, clear responsibilities, and incremental design through refactoring.
How this skill works
Start with failing tests (Red-Green-Refactor) and let design emerge during refactor steps. Apply the SOLID checklist to every class/module, wrap primitives in value objects, keep methods and classes tiny, and prefer abstractions over concretions. Use the provided code-smell triggers and pre/during/post coding checklists to guide decisions and stop to refactor when smells appear.
When to use it
- Writing new features or utilities
- Refactoring legacy or junior-written code
- Designing architecture or splitting modules
- Performing code reviews or QA handoffs
- Debugging production issues with long-term fixes
Best practices
- Always write a failing test first; follow Red-Green-Refactor
- One responsibility per class, methods <10 lines, max two instance variables
- Wrap domain primitives in value objects and prefer first-class collections
- Name things using domain language, consistent and specific
- Delay abstractions until the Rule of Three; avoid speculative generality
Example use cases
- Refactor a bloated service into smaller services and repositories with tests
- Convert primitive IDs and money values into validated value objects
- Design a vertical slice for a new feature with unit and integration tests
- Review a pull request and flag code smells such as long methods or primitive obsession
- Introduce dependency inversion to replace a concrete dependency with an interface for easier testing
FAQ
Apply principles pragmatically: use them as questions to guide design, not as rigid templates. Prioritize simplicity and tests; enforce the rules where they reduce coupling and improve clarity.
When should I introduce a design pattern?
Introduce patterns only after evidence—prefer to refactor toward a pattern when duplication or complexity reaches the Rule of Three or a clear smell emerges.