About

Imported from krutikjain/android-agent-skills (skills/android-modularization/SKILL.md). Install upstream with npx skills add krutikjain/android-agent-skills --skill android-modularization. Copyright stays with the author.

Android Modularization

Name: android-modularization
Author: krutikjain

When To Use

Use this skill when the request is about: android module split, feature modularization in android, break cyclic module dependency.
Primary outcome: Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies.
Reach for this skill when the problem is dependency direction, API ownership, or feature/data/core boundaries, not task-level build speed tuning.
Handoff skills when the scope expands:
android-gradle-build-logic
android-architecture-clean

Workflow

Map the current module graph first: app, feature, data, core, build-logic, and any dynamic-feature or test-only modules.
Identify which direction is wrong: feature-to-feature coupling, framework leakage into domain/data, API surface too wide, or duplicated shared code with unclear ownership.
Split by ownership and change rate, not by abstract theory; create the smallest module boundary that removes the current coupling problem.
Keep api vs implementation, public surface area, and test fixture ownership explicit so the new boundary stays stable.
Hand off build-speed or plugin-architecture issues only after the module graph itself is coherent.

Guardrails

Prefer official Android and Kotlin guidance over custom local conventions when they conflict.
Keep public APIs boring and explicit; avoid clever abstractions that hide Android lifecycle costs.
Do not mix architectural cleanup with product behavior changes unless the request explicitly needs both.
Document any compatibility constraints that will affect old modules or generated code.
Avoid over-modularizing a small codebase when the real need is a single clearer ownership boundary.

Anti-Patterns

Sprinkling helpers across modules without a clear ownership boundary.
Introducing framework-specific code into pure domain or data layers.
Refactoring every adjacent file when only one contract needed to change.
Leaving migration notes implied instead of writing them down.
Treating module count as the goal instead of build isolation and dependency clarity.

Examples

Happy path

Scenario: Review the fixture apps as app modules and map the next split into feature/core layers.
Command: cd examples/orbittasks-compose && ./gradlew :app:projects

Edge case

Scenario: Keep shared XML resources and manifest placeholders from leaking across modules.
Command: cd examples/orbittasks-xml && ./gradlew :app:dependencies

Failure recovery

Scenario: Differentiate modularization requests from architecture-clean and build-logic prompts.
Command: python3 scripts/eval_triggers.py --skill android-modularization

Done Checklist

The implementation path is explicit, minimal, and tied to the right Android surface.
Relevant example commands and benchmark prompts have been exercised or updated.
Handoffs to adjacent skills are documented when the request crosses boundaries.
Official references cover the chosen pattern and the main migration or troubleshooting path.

Official References

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml

targets:
  - https://api.opensmartroute.ai/api/v1/registry/krutikjain-android-agent-skills-android-modularization/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

krutikjain-android-agent-skills-android-modularization.ocm.jsonjson

{
  "ocm": "1",
  "id": "krutikjain-android-agent-skills-android-modularization",
  "kind": "skill",
  "name": "android-modularization",
  "description": "Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies.",
  "publisher": "krutikjain",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "general"
    ],
    "tags": [
      "skill-md",
      "android",
      "modules",
      "gradle",
      "repository-design",
      "skills-sh"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "skills.sh",
      "repository": "https://github.com/krutikjain/android-agent-skills",
      "path": "skills/android-modularization/SKILL.md",
      "ref": "HEAD",
      "url": "https://github.com/krutikjain/android-agent-skills/blob/HEAD/skills/android-modularization/SKILL.md",
      "key": "krutikjain/android-agent-skills/skills/android-modularization/SKILL.md"
    }
  },
  "instructions": "# Android Modularization\n\n## When To Use\n- Use this skill when the request is about: android module split, feature modularization in android, break cyclic module dependency.\n- Primary outcome: Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies.\n- Reach for this skill when the problem is dependency direction, API ownership, or feature/data/core boundaries, not task-level build speed tuning.\n- Handoff skills when the scope expands:\n- `android-gradle-build-logic`\n- `android-architecture-clean`\n\n## Workflow\n1. Map the current module graph",
  "cost": {
    "context_tokens": 891
  }
}

Fetch it by URL: GET /api/v1/registry/krutikjain-android-agent-skills-android-modularization/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.