About modularization
A modularization reference for Kotlin multi-module projects that explains how to set symbol visibility based on actual usage. It distinguishes public APIs from module-internal implementation to avoid unnecessarily widening the API surface.
Key features
- 01Choose the narrowest compiling visibility
- 02Separate public interfaces from internal implementations
- 03Use internal for module-local helpers
- 04Use private for class-local members
- 05Require cross-module consumers before making symbols public
Use cases
- 01Define a module's public interface
- 02Restrict visibility of mappers and extensions
- 03Review API surfaces in multi-module projects
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/modularizationin Claude Code to confirm it loaded.
Details
From the project READMEModularization
Declare everything at the lowest visibility that still compiles. Start private; widen to internal only when another file in the same module needs it; widen to public only when a different module actually consumes it. Kotlin defaults to public, and in a multi-module project that default is usually wrong — a public symbol joins the module's API surface: it leaks implementation across the boundary and you are then obliged to keep it stable.
- Public interface as the module's API → the interface is
public; its implementation class staysinternal(DI-bound, never named from another module). - Mapper / helper / extension / constant / UI-state holder used only inside the module →
internal(orprivateif a single file uses it). "Rendered by a composable in this module" does not requirepublic—internalis visible to the whole module. - Member used only within its class →
private.
Widening a symbol to public is a decision, not a default: confirm a real cross-module consumer first.