Skip to content
Development
Skill

/modularization

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

BOOST
From plugin
android-skills
16221 skills
Install
$ npx -y skills add rcosteira79/android-skills --skill modularization --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/modularization

Context preview

The summary Claude sees to decide when to auto-load this skill.

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

SKILL.md

modularization.SKILL.md
name: modularization
description: 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?".

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 stays `internal`** (DI-bound, never named from another module).
  • Mapper / helper / extension / constant / UI-state holder used only inside the module → `internal` (or `private` if a single file uses it). "Rendered by a composable in this module" does **not** require `public` — `internal` is 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.

Read more
Ships withandroid-skills

Android & KMP development skills for Claude Code, Codex, and Copilot CLI — architecture, Compose, coroutines, flows, networking, persistence, dependency injection, testing, debugging, and Gradle.

Get the whole plugin

Other skills on android-skills.