Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Step-by-step module creation checklist. Use when adding a new Gradle module and wiring build, DI, and architecture integration correctly.
Skill: Adding a New Module
Overview
The build system is convention-driven: naming a module correctly causes buildSrc/CorePlugin to
automatically apply the right plugins, dependencies, and Room options. Follow this checklist when
adding any new Gradle module.
Before creating a new module, confirm the work does not belong in an existing :android:* or
:app:core helper surface. Theme/configuration, notification, deep-link, drawer, and general
Android utility work often extends those modules rather than introducing a new module.
Key files to read
buildSrc/src/main/java/co/anitrend/buildSrc/module/Modules.kt — central registry of all
module paths; must be updated for every new module
buildSrc/src/main/java/co/anitrend/buildSrc/plugins/CorePlugin.kt — the convention plugin
applied to every module
buildSrc/src/main/java/co/anitrend/buildSrc/plugins/components/ProjectDependencies.kt —
determines which libraries are automatically injected based on module type
settings.gradle.kts — where the include(":your:new:module") declaration lives
Step-by-step checklist
0. Placement decision
If the change is a platform/helper concern, inspect :android:*, :app:core, and
.agents/skills/android-platform-patterns/SKILL.md first.
Only create a new module when an existing module cannot own the change cleanly.
1. File system
Create the module directory following the existing layout (feature/, data/, common/, etc.).
Add build.gradle.kts applying the CorePlugin (copy from a similar existing module).
Add src/main/kotlin/ and src/main/AndroidManifest.xml (for Android library modules).
2. Gradle wiring
Add include(":your:new:module") to settings.gradle.kts.
Register the path constant in Modules.kt under the correct category
(Feature, Data, Common, Android, Task, etc.).
3. Dependency injection (Koin)
Create <module>/src/main/kotlin/.../koin/Modules.kt (see .agents/skills/koin-module-wiring/SKILL.md).
Add the module loader to the Modules.kt file in the module's immediate parent Gradle
module. If that parent module is new and must load at app startup, also add the parent loader to
app/core/src/main/kotlin/co/anitrend/core/koin/Modules.kt.
4. Domain / Data wiring (if a data or feature module)
Choose the reference pattern by shape: tag for a single query-only read, media for
multiple read contracts against one entity, medialist or review for modules that both read
and write, and favourite for a single mutation-only toggle.
Define the domain repository contract in :domain; if the module performs both reads and
writes, split it by operation (Detail, Paged, Save, Delete, Rate, etc.) instead of one
broad interface.
Define the abstract domain use case in :domain; do not keep repository contracts or
concrete interactor implementations inside the module Types.kt.
Implement the repository specialization in the new data module and export aliases from
Types.kt.
Create the data-layer interactor bridge in usecase/; simple modules may use
XxxUseCaseImpl, while multi-operation modules may use nested XxxInteractor classes.
If writes should be background-safe or follow existing mutation routing, add the matching
:task:* worker and router plumbing instead of calling the mutation interactor directly from
feature code.
Follow the four-file entity pattern if adding persistence (see .agents/skills/room-entity-pattern/SKILL.md).
5. Validation
Run ./gradlew :your:new:module:assembleDebug to verify plugin and dependency resolution.
Run ./gradlew spotlessCheck to validate formatting.
If Room is involved, confirm schema JSON is exported under data/schemas/.
