software-design-philosophy
Manage software complexity through deep modules, information hiding, and strategic programming. Use when the user mentions "module design", "API too complex", "shallow class", "complexity budget", "strategic vs tactical", "deep module", "information leakage", "pass-through method", "this code is over-engineered", or "simplify this design". Also trigger when reviewing an interface for simplicity, evaluating whether an abstraction is pulling its weight, deciding whether a comment is worth writing, or choosing between general-purpose and special-purpose approaches. Covers deep vs shallow modules, red flags for complexity, and comments as design documentation. For code quality, see clean-code. For architecture boundaries, see clean-architecture.
- Version
- 1.4.0
- License
- MIT
Pinned to revision 4f7124e6049e, so it is the text this page describes rather than whatever the author pushed since.
Files
- skills/software-design-philosophy/SKILL.md
- skills/software-design-philosophy/references/comments-as-design.md
- skills/software-design-philosophy/references/complexity-symptoms.md
- skills/software-design-philosophy/references/deep-modules.md
- skills/software-design-philosophy/references/general-vs-special.md
- skills/software-design-philosophy/references/information-hiding.md
- skills/software-design-philosophy/references/strategic-programming.md
Every link opens the file at its source, pinned to the revision this page describes.