evilissimo/software-design
Use before implementing or refactoring software. Contains two skills: (1) Modular Software Design — for designing module boundaries, APIs, layers, abstractions, services, repositories, adapters, or architecture, helping reduce total system complexity by creating deep modules, hiding implementation knowledge, avoiding leakage and pass-through APIs, comparing alternative designs, documenting interfaces before coding, and critiquing existing architecture; and (2) Software Testing — for writing unit tests, integration tests, or end-to-end tests, creating mocks/stubs/fakes, designing a testing strategy, doing TDD, reviewing test quality, fixing flaky tests, or refactoring test suites, generating risk-focused test plans, picking appropriate test levels, choosing between mocks/fakes/real dependencies, and applying Arrange-Act-Assert patterns with concrete examples.
88
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
architecture-critique.mdskills/modular-software-design-skill/templates/
Architecture Critique: [System / Feature]
Scope
[Summarize code, modules, files, or architecture being reviewed.]
Current Module Map
| Module | Current responsibility | Public interface | Callers | Dependencies | Decisions owned |
|---|---|---|---|---|---|
| [Name] |
Complexity Symptoms
Change Amplification
- Small change that touches many places:
- Cause:
- Candidate boundary change:
Cognitive Load
- Facts maintainers must know:
- Facts callers should not need to know:
- Candidate simplification:
Unknown Unknowns
- Implicit requirements:
- Hidden sequencing:
- Undocumented side effects:
- Candidate documentation or redesign:
Design Smells
- Shallow modules:
- Pass-through methods:
- Pass-through variables:
- Temporal decomposition:
- Leaked storage/framework/vendor details:
- Duplicated layer abstractions:
- Boolean flag APIs:
- Repeated special-case handling:
- Inconsistent naming:
Recommended Refactorings
Recommendation: [Name]
- Issue:
- Complexity cost:
- Change:
- Modules to split or merge:
- Logic to move downward:
- Interface to redesign:
- Names/comments to update:
- Expected benefit:
- Risk:
- Migration path:
Priority Order
- [Small strategic change with highest complexity reduction]
- [Next change]
- [Deferred / only if needed]