android-modularization-pro

Turn an Android app into a thin :app over many small Gradle modules, or check one that already is. This is the deep companion to the always-on android-modular-architecture.md rule. The rule steers while writing; this skill plans a graph, audits a whole build, and drives a migration one module at a time.

Pick the mode from the request:

• Plan: a new app, or a single-module app before any move. Produce a module map (module · type · purpose · dependencies) and the extraction order, using references/module-graph.md. Start small (:core:model, :core:data, :core:designsystem, one feature) and say which later splits you'd expect.
• Migrate: move code out of :app, or out of an oversized module, following references/migration.md. One module per step, the app building and tests passing after each.
• Audit: an app that already has modules. Run the checks in references/audit.md, then report findings ranked by severity.

Review process (audit mode):

1. Inventory: settings.gradle.kts includes, each module's plugins and Kotlin file count, :app's Kotlin files, and gradle.properties build flags. Use references/audit.md ("Inventory").
2. Check the graph with references/module-graph.md and the dependency report in references/audit.md: feature→feature impl edges, features reaching data sources, api(...) overuse, :impl modules consumed outside :app, oversized or near-empty modules.
3. Check navigation and DI with references/navigation-and-di.md: how features reach each other, where the NavHost lives, Hilt module visibility, test bindings.
4. Check resources, visibility, and build flags: non-transitive R, resource prefixes, internal/explicit API, configuration cache and build cache.
5. Check enforcement: is there a module-graph assertion in CI, and a module table in CLAUDE.md?

If doing a partial review, load only the relevant reference file.

Core Instructions

• :app is an assembler. It keeps the Application, MainActivity, the top-level NavHost, the manifest, and launcher resources. Screens, ViewModels, and repositories belong in modules.
• Direction is the architecture. :app → features → domain → data → data sources → model. Features never depend on another feature's impl; shared needs move down into :core:*.
• Navigation goes through :app. Features expose a NavGraphBuilder entry and navigation lambdas; the api module holds routes. :app connects them.
• Incremental, never big-bang. Every step leaves the app building and shippable. Convention plugins come first so each new module costs a few lines.
• implementation and internal by default. api(...) and public symbols are deliberate, reviewed choices.
• Granularity follows real boundaries. Split for a second owner, a heavy dependency only part of the code needs, reuse by another app (Wear, TV), or slow builds. Don't split speculatively.
• Enforce what you decide. A graph rule without a CI check is a suggestion.
• Severity by cost: broken (a missing Hilt binding at runtime because a module never reaches :app, resources resolving through a transitive R that breaks when non-transitive R is on, a dynamic feature with a missing split) > boundary leak (feature→feature impl edge, features importing :core:database or :core:network, logic in :app, api leaks) > shape (oversized or near-empty modules, missing graph check or module table).
• Cross-reference, don't duplicate: convention plugins, catalogs, and AGP versions go to android-gradle-architecture-pro; ViewModel and UiState shape to android-mvvm-architecture.md; repositories to android-repository-pattern.md; design-system contents to android-design-system-pro; Compose performance to android-compose-pro.