Module Interface Design
Propose a coherent boundary that reduces caller knowledge without hiding important authority or failure behavior.
Workflow
- Establish the user outcome, current modules, callers, dependencies, vocabulary, invariants, and change pressure.
- Identify knowledge duplicated across callers, unstable details that leak through interfaces, and state or authority that lacks a clear owner.
- Define the smallest useful contract: inputs, outputs, errors, state transitions, compatibility promises, and operational signals.
- Compare at least two viable boundaries when the tradeoff is material. Include the cost of keeping the current design.
- Test each option against common use, difficult use, invalid use, migration, partial rollout, and future change.
- Recommend a boundary with explicit reasons, rejected alternatives, and unresolved decisions.
- Describe a staged migration and verification approach without performing the redesign.
Boundaries
- Prefer evidence from actual callers over abstract purity.
- A deeper module is not permission to conceal data authority, security decisions, or failure modes.
- Do not force one architecture pattern across unrelated stacks.
- Treat redesign, deletion, migration, and compatibility breaks as proposals until separately approved.
Output
Return Current pressure, Vocabulary, Invariants, Candidate boundaries, Recommended interface, Hidden implementation, Compatibility, Migration, Tradeoffs, and Open decisions.
1---2name: module-interface-design3description: Design or review a module boundary, vocabulary, interface, and hidden implementation so callers face a smaller and more stable contract. Use when code is coupled, concepts leak across layers, responsibilities are unclear, or a redesign needs concrete options before implementation.4license: MIT5---67# Module Interface Design89Propose a coherent boundary that reduces caller knowledge without hiding important authority or failure behavior.1011## Workflow12131. Establish the user outcome, current modules, callers, dependencies, vocabulary, invariants, and change pressure.142. Identify knowledge duplicated across callers, unstable details that leak through interfaces, and state or authority that lacks a clear owner.153. Define the smallest useful contract: inputs, outputs, errors, state transitions, compatibility promises, and operational signals.164. Compare at least two viable boundaries when the tradeoff is material. Include the cost of keeping the current design.175. Test each option against common use, difficult use, invalid use, migration, partial rollout, and future change.186. Recommend a boundary with explicit reasons, rejected alternatives, and unresolved decisions.197. Describe a staged migration and verification approach without performing the redesign.2021## Boundaries2223- Prefer evidence from actual callers over abstract purity.24- A deeper module is not permission to conceal data authority, security decisions, or failure modes.25- Do not force one architecture pattern across unrelated stacks.26- Treat redesign, deletion, migration, and compatibility breaks as proposals until separately approved.2728## Output2930Return `Current pressure`, `Vocabulary`, `Invariants`, `Candidate boundaries`, `Recommended interface`, `Hidden implementation`, `Compatibility`, `Migration`, `Tradeoffs`, and `Open decisions`.
JovaniPink