Modularization
Communityrcosteira79
Use when writing or changing any class, object, function, property, or constant in a multi-module Android/Kotlin project (settings.gradle(.kts) includes more than one module — :app, :core:*, :feature:*, :data, etc.). Symptoms — a top-level declaration left at Kotlin's default public visibility; an implementation class, mapper, helper, constant, or UI-state holder reachable from another module though only used within its own; reaching for public "because the caller needs it"; "should this be public or internal?".
Overview
- Repository
- rcosteira79/android-skills
- Publisher
- rcosteira79
- Stars
- 174
- Forks
- 21
- Bundled files
- 0
- License
- MIT
- Updated
- Nov 10, 2026
Installation
tmp=$(mktemp -d)
git clone --depth 1 https://github.com/rcosteira79/android-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/plugins/android-skills/skills/modularization" ~/.claude/skills/modularization
rm -rf "$tmp"tmp=$(mktemp -d)
git clone --depth 1 https://github.com/rcosteira79/android-skills.git "$tmp"
mkdir -p ~/.codex/skills
cp -R "$tmp/plugins/android-skills/skills/modularization" ~/.codex/skills/modularization
rm -rf "$tmp"Install the Modularization agent skill from https://github.com/rcosteira79/android-skills/tree/main/plugins/android-skills/skills/modularization into this project's skills folder.Instructions
Modularization
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.
FAQ
What does Modularization do?
Use when writing or changing any class, object, function, property, or constant in a multi-module Android/Kotlin project (settings.gradle(.kts) includes more than one module — :app, :core:*, :feature:*, :data, etc.). Symptoms — a top-level declaration left at Kotlin's default public visibility; an implementation class, mapper, helper, constant, or UI-state holder reachable from another module though only used within its own; reaching for public "because the caller needs it"; "should this be public or internal?".
Who made Modularization?
rcosteira79 (a community member) publishes it in the rcosteira79/android-skills repository on GitHub.
Is Modularization free?
Yes. Modularization is open source, published by rcosteira79 under the MIT license.
What comes with Modularization?
Just its instructions. Everything the agent needs is in one SKILL.md file.
Which agents can use Modularization?
Any coding agent that reads SKILL.md files, including Claude Code, Codex, Cursor, GitHub Copilot and Gemini CLI. The agent loads the skill when a task matches its description.
What are agent skills?
An agent skill is a folder with a SKILL.md file: instructions that teach a coding agent how to do one kind of task, and optionally files it can read while it works. The agent keeps only the skill's name and description in mind and reads the rest when a task calls for it.
How are agent skills different from MCP servers?
An MCP server gives an agent new tools to call, code that runs somewhere and returns results. A skill gives it knowledge: how to approach a task with the tools it already has. Many agents use both.
How can my agent test my Android app?
Robomori lets coding agents create, start and control Android emulators and devices from one command, so they can install your app, take screenshots and check dark mode, font sizes and languages.
Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns. Use when structuring modules, layers, or data flow in an Android or KMP project.
Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow implementation to their specific skills.
Use when building or reviewing redux-kotlin (Kotlin Multiplatform Redux) code — adding/editing a feature slice, wiring the store, Compose state binding, effects/sync middleware, testing, the platform expect/actual shims, or modularization. Enforces the project's render-isolation / off-main-effects / mint-at-edge rules.
Design and verify App Platform module boundaries. Use when placing shared APIs, implementations, internal code, fakes, robots, or app assembly; adding Gradle modules or dependencies; enabling module structure checks; or fixing forbidden dependency errors.
