android-feature

Guide Android feature creation with Compose UI, ViewModels, and repository interfaces.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/soygabimoreno/Los-ANDROIDES --skill android-feature
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: android-feature
Source: https://github.com/soygabimoreno/Los-ANDROIDES/tree/main/.agents/skills/android-feature
Command: npx skills add https://github.com/soygabimoreno/Los-ANDROIDES --skill android-feature

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you create or modify user-facing Android features in Los ANDROIDES without breaking the project’s architecture, module boundaries, or UI/presentation conventions, so changes stay maintainable and testable.

Core Features & Use Cases

  • Repo-aligned feature workflow: Guides you to inspect the existing feature/screen/ViewModel/use cases/repositories/mappers/tests before changing behavior.
  • Architecture-safe edits: Keeps UI behavior in Compose/presentation state, keeps business rules in use cases/domain code, and keeps data access behind repository interfaces.
  • Verification-minded updates: Encourages updating/adding tests and running the narrowest useful verification to prevent regressions when shared code changes.

Quick Start

Use the android-feature skill when you need to implement or adjust a new user-facing behavior in Los ANDROIDES, and ask it to propose the safest set of files, layer boundaries, and tests to update while following AGENTS.md and the feature workflow.

Frequently Asked Questions about android-feature

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new Android feature in Compose without breaking clean architecture boundaries?

To add an Android feature safely, keep UI behavior in Compose and presentation state, keep business rules in use cases, and keep data access behind repository interfaces. This maintains clean architecture boundaries and ensures changes stay maintainable and testable.

Where should presentation logic and data mapping go when modifying a ViewModel in an MVVM project?

Presentation logic belongs in Compose and presentation state, while data mapping updates must occur across module boundaries before changing ViewModel behavior. Inspecting the existing repository interfaces and use cases ensures logic placement aligns with deterministic repo conventions.

What's the best way to verify Compose UI changes and use case modifications without causing regressions?

The best way to verify changes is by updating or adding the narrowest useful tests. Run targeted verification on modified ViewModels, use cases, and mappers to prevent regressions when shared code changes across module boundaries.

Does this Android feature workflow require inspecting existing modules before writing new code?

Yes, the Android feature workflow requires prior inspection of owning modules. You must inspect existing screens, ViewModels, use cases, repositories, and mappers before changing behavior to enforce deterministic repo conventions and maintain architecture safety.

Can I use Hilt for dependency injection while building MVVM features with Compose?

Yes, Hilt works with Compose UI, presentation state, ViewModels, domain use cases, and repository interfaces in this workflow. The architecture-safe edits keep data access behind repository interfaces, allowing Hilt to manage dependencies across module boundaries.

Why should logic be separated across layers instead of putting everything in the ViewModel?

Logic should be separated because keeping UI behavior in Compose, business rules in use cases, and data access behind repository interfaces prevents breaking the project’s architecture. This separation keeps changes maintainable, testable, and aligned with repo conventions.