用途：当请求涉及 Android 模块拆分、feature 模块化或打破循环模块依赖时使用本技能。主要产出是设计可扩展、无循环依赖的 Android 仓库结构，划分为 feature、core、build-logic 模块。当问题在于依赖方向、API 归属或 feature/data/core 边界时适用，而非任务级构建速度调优。
工作流程：先梳理现有模块图，包括 app、feature、data、core、build-logic 以及任何 dynamic-feature 或仅测试模块。再判断哪一方向有误，如 feature 间耦合、框架代码泄漏进 domain/data、API 面过宽、共享代码重复且归属不清。按归属和变更频率而非抽象理论拆分，创建能消除当前耦合问题的最小模块边界。保持 api 与 implementation、公开接口面积、测试夹具归属显式，使新边界保持稳定。仅在模块图本身一致后再移交构建速度或插件架构问题。
适用场景：依赖方向、接口归属、feature/data/core 边界问题。范围扩大时可移交 android-gradle-build-logic、android-architecture-clean。
限制与护栏：官方 Android 与 Kotlin 指南与本地约定冲突时，优先官方指南。公开 API 应直白显式，避免隐藏 Android 生命周期成本的取巧抽象。除非请求明确要求，不要将架构清理与产品行为变更混在一起。记录影响旧模块或生成代码的兼容性约束。小型代码库若真正需求只是单一更清晰的归属边界，应避免过度模块化。
反模式：在模块间散落 helper 而无清晰归属边界；将框架特定代码引入纯 domain 或 data 层；仅需改一个契约却重构所有相邻文件；迁移说明只是暗示而不写下来；把模块数量当作目标而非构建隔离与依赖清晰度。
示例命令：cd examples/orbittasks-compose && ./gradlew :app:projects；cd examples/orbittasks-xml && ./gradlew :app:dependencies；python3 scripts/eval_triggers.py --skill android-modularization。
完成清单：实现路径显式、最小且绑定正确 Android 界面；相关示例命令与基准提示已执行或更新；请求跨界时记录相邻技能移交；官方参考覆盖所选模式及主要迁移或排查路径。官方参考：https://developer.android.com/topic/modularization、https://docs.gradle.org/current/userguide/multi_project_builds.html、https://developer.android.com/build/extend-agp、https://developer.android.com/build/migrate-to-kotlin-dsl。