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
design-brief.mdskills/modular-software-design-skill/templates/
Design Brief: [Task Name]
Task
[Describe the requested change.]
Complexity Goal
- Reduce total system complexity by hiding: [volatile decisions / messy details]
- Reduce change amplification for: [future change]
- Reduce cognitive load for: [callers / maintainers]
- Make obvious: [implicit facts / unknown unknowns]
Candidate Modules
Module: [Name]
- Purpose:
- Public operations:
- Inputs:
- Outputs:
- Errors:
- Side effects:
- Invariants:
- Caller responsibilities:
- Hidden implementation knowledge:
- Non-goals:
Alternative Designs
Design A: [Name]
- Modules:
- Interface shape:
- Hidden knowledge:
- Layer boundaries:
- Caller burden:
- Change impact:
- Risks:
Design B: [Name]
- Modules:
- Interface shape:
- Hidden knowledge:
- Layer boundaries:
- Caller burden:
- Change impact:
- Risks:
Chosen Design
Chosen: [A/B/other]
Rationale:
- Deepest module:
- Smallest useful interface:
- Leakage avoided:
- Pass-throughs avoided:
- Future change localized:
- Tradeoffs accepted:
Leakage and Layering Audit
- Storage/framework/vendor details hidden:
- Boundary translations:
- Pass-through method risks:
- Pass-through variable risks:
- Duplicated layer abstractions:
- Special cases centralized or designed away:
Implementation Plan
- Files/classes/functions to add:
- Files/classes/functions to change:
- Tests:
- Interface comments/docs:
- Refactoring triggers during implementation: