modularitylisted

# /modularity — Modular Design Enforcement Every design, plan, and implementation MUST produce small, focused modules where any single change touches the fewest files possible and every touched file fits comfortably in context. **Why this matters:** When files are large or tightly coupled, the active runtime must compact context to fit them — risking loss of key details. Modular design prevents this by keeping each unit small enough to reason about completely. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to both new code and modifications to existing code. --- ## The Rules ### Rule 1: File Size Limits | File type | Soft limit | Hard limit | Action at hard limit | |-----------|-----------|------------|---------------------| | Source code (logic) | 150 lines | 300 lines | MUST split before proceeding | | Test files | 200 lines | 400 lines | MUST split into focused test suites | | Config / data | 100 lines | 200 lines | MUST split into per-concern configs | | Documentation | 300 lines | 500 lines | MUST split into linked pages | **Soft limit:** Refactor soon. Flag in code review. **Hard limit:** Do not proceed. Split first, then continue. Line counts exclude blank lines and comments. If a file approaches the soft limit during implementation, split it before the next commit — not "later." ### Rule 2: Single Responsibility Per File Every file answers ONE