LLMSkillHub
mirroredCopied from stevesolun/ctx under MIT. stevesolun has not claimed this page, and is not affiliated with LLM SkillHub.

stevesolun / codebase-design

Design or improve module interfaces using deep-module heuristics. Use when deciding where a seam belongs, reducing caller-facing complexity, improving testability or navigability, or comparing module designs.

0
SKILL.md
2.6 KB

Codebase Design

Seek deep modules: substantial useful behavior behind a small, stable
interface. Use the concepts below as design lenses, while matching the
repository's established domain language.

Working vocabulary

  • Module: a coherent unit with an interface and implementation, at any scale.

  • Interface: everything callers must know, including invariants and failure
    modes—not just a type signature.

  • Seam: a location where behavior can vary without editing its callers.
  • Adapter: an implementation that connects at a seam.
  • Depth: useful capability relative to interface complexity.

  • Leverage: capability gained by callers; locality: change and knowledge
    concentrated for maintainers.

Translate these terms to the project's vocabulary when that makes the design
clearer. Consistency with the codebase is more valuable than enforcing a private
lexicon.

Design workflow

  1. Map representative callers, responsibilities, dependencies, and existing
    contracts.

  2. Look for coordination or policy that can move behind a smaller interface.
  3. Place seams where variation, ownership, or test isolation justifies them.
  4. Compare alternatives when the choice is consequential.
  5. Validate the candidate with representative caller code and tests.

Heuristics, not laws

  • Reduce methods, parameters, ordering constraints, and configuration callers
    must understand.

  • Use the deletion test: if removing a module merely spreads its complexity
    across callers, it was likely earning its keep.

  • Treat pass-through layers skeptically, but keep them when they provide a real
    compatibility, ownership, policy, or navigation boundary.

  • Introduce dependency seams when actual variation or test isolation repays the
    indirection; avoid interfaces justified only by hypothetical futures.

  • Prefer tests through observable interfaces, while allowing focused internal
    tests when they provide cheaper or more precise feedback.

  • Favor explicit dependencies and returned results when they improve control and
    testability; side effects and internally created dependencies can still be
    appropriate at well-defined boundaries.

Read [DEEPENING.md](DEEPENING.md) when consolidating a cluster across dependency
boundaries. Read [DESIGN-IT-TWICE.md](DESIGN-IT-TWICE.md) when materially
different interface designs can be explored independently.