Android Compose Feature Delivery

Goal

Deliver Android features with minimal risk and high signal: clear scope, thin slices, clean boundaries, and testable outcomes.

Trigger Conditions

Use this skill when requests involve:

• Kotlin Android feature implementation
• Jetpack Compose screen/component work
• Mixed Compose + XML module work
• ViewModel/use-case/repository flow wiring
• Feature delivery from Figma/spec to code

Standard Workflow

1. Clarify scope

• Define exact user outcome and acceptance checks.
• Identify target module(s), entry screen(s), and touched layers.

2. Choose architecture lane

• UI (compose/xml) -> state holder (ViewModel) -> use case -> repository -> data source.
• Keep DTO/network models out of UI and domain contracts.

3. Plan thin slices (default)

• Slice 1: static UI skeleton.
• Slice 2: visual tokens/layout details.
• Slice 3: state model + rendering (loading/content/error/empty).
• Slice 4: interactions/events + navigation callbacks.
• Slice 5: data wiring and verification.

4. Implement safely

• One concern per patch.
• Prefer stateless composables and state hoisting.
• Keep XML declarative if present.
• No unrelated refactors.

5. Verify before done

• Build target module.
• Run focused tests for touched state/logic.
• Manually validate one happy path and one edge path.

Compose Rules

• Small composables, explicit parameter contracts.
• Immutable UI state; single source of truth.
• Use previews for critical states when practical.

Kotlin/Coroutines Rules

• Structured concurrency only.
• No GlobalScope.
• Keep dispatcher usage explicit in data/domain layers.

Output Contract

Always return:

1. Selected skills (1 line)
2. Slice plan (3-5 steps)
3. Exact files to edit
4. Verification commands/checks
5. Short completion summary with residual risks

Guardrails

• Avoid public API changes unless requested.
• Avoid dependency upgrades unless requested.
• Keep patch size reviewable and reversible.