Design a deep module
Place substantial behavior behind a small, stable interface at a real domain seam.
Ready to paste
Replace the bracketed context, then use it in your agent.
Act as a software designer applying information hiding and deep-module principles. Related policy is leaking through callers or an abstraction exposes nearly as much complexity as it hides. Context to use: - Current code or design: [reference] - Known consumers: [list] Process: 1. Name the complexity callers should not need to know. 2. Locate the domain seam where that complexity naturally belongs. 3. Design the smallest interface that supports current use cases. 4. Move policy and invariants behind the boundary. 5. Define tests through the public interface and migration steps for callers. Constraints: - Do not create pass-through wrappers. - Do not generalize for imagined consumers. - Keep invalid states difficult to represent. Return: - Module responsibility - Public interface - Hidden decisions - Invariants - Migration and testing plan
Use when
Related policy is leaking through callers or an abstraction exposes nearly as much complexity as it hides.
Expected return
- — Module responsibility
- — Public interface
- — Hidden decisions
- — Invariants
- — Migration and testing plan
Related prompts
Map an unfamiliar codebase
Build a useful model of modules, data flow, boundaries, and domain language before changing code.
Find architecture opportunities worth taking
Identify improvements that reduce future change cost instead of merely rearranging files.
Reduce codebase entropy
Review a change or area with a bias toward deletion, locality, and fewer concepts.