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.
93
94%
Does it follow best practices?
Impact
92%
1.12xAverage score across 5 eval scenarios
Passed
No known issues
property-based-testing.mdskills/software-testing/references/
Property-Based Testing
Use property-based testing when example lists become unwieldy and behavior is better expressed as an invariant.
Good Properties
- Ordering preservation
- Idempotence
- Reversibility
- Monotonicity
- Conservation of totals/counts
- Parser/serializer round-trips
- Commutativity/associativity where domain-valid
- State machine transitions and invariants
Pitfalls
Avoid properties that are too weak, too broad, or secretly reimplement the algorithm under test. Generators should create valid domain values often enough to exercise meaningful behavior and include boundary cases. Shrinking should produce readable counterexamples.
Placement
Use property tests mostly for pure domain rules, parsers, serializers, calculations, and state transitions. Keep a few example tests for named business cases so failures are easy to understand.