agentleFS
Sign inStart free
krutikJainkrutikJain/android-agent-skills/.github/skills/android-architecture-clean/SKILL.md

android-architecture-clean

Skill14 starsChanged 8 months agoMITView on GitHub

Apply clean architecture boundaries, use cases, repositories, and lifecycle-aware presentation models in Android projects.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the request is about: clean architecture in android, split use cases and repositories, untangle presentation and data …

    line 17
  2. Distinctive:

    Prefer official Android and Kotlin guidance over custom local conventions when they conflict.

    line 31
  3. Distinctive:

    Keep public APIs boring and explicit.

    line 32
  4. Distinctive:

    Do not mix architectural cleanup with product behavior changes unless the request explicitly needs both.

    line 33
  5. Distinctive:

    Document any compatibility constraints that will affect old modules or generated code.

    line 34

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Android Architecture Clean

When To Use

  • Use this skill when the request is about: clean architecture in android, split use cases and repositories, untangle presentation and data layer.
  • Primary outcome: Apply clean architecture boundaries, use cases, repositories, and lifecycle-aware presentation models in Android projects.
  • Handoff skills when the scope expands:
  • android-modularization
  • android-state-management

Workflow

  1. Map the request to the current Android stack, module boundaries, and minimum supported API level.
  2. Inspect the existing implementation for implicit assumptions, duplicate helpers, and outdated patterns.
  3. Apply the smallest change that improves correctness, readability, and long-term maintainability.
  4. Validate the result against the relevant showcase app path and repo benchmarks.
  5. Hand off adjacent work to the next specialized skill only after the core foundation is stable.

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.

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.

Examples

Happy path

  • Scenario: Separate OrbitTasks feature state, use case, and repository contracts.
  • Command: cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

Edge case

  • Scenario: Keep XML activity actions thin while preserving saved-state behavior.
  • Command: cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

Failure recovery

  • Scenario: Catch trigger confusion against modularization and state-management requests.
  • Command: python3 scripts/eval_triggers.py --skill android-architecture-clean

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free