android-feature-implement

Implements Android features across UI, ViewModel, repository, and data layers per spec.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/nolte/claude-android-engineering --skill android-feature-implement-nolte
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: android-feature-implement
Source: https://github.com/nolte/claude-android-engineering/tree/main/skills/android-feature-implement
Command: npx skills add https://github.com/nolte/claude-android-engineering --skill android-feature-implement-nolte

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Implementing a feature in a native Kotlin Android app touches many layers — Compose UI, ViewModel state, repository, sync workers, and backend contracts — and it is easy to silently move business logic onto the device or leave failure cases unhandled. This Skill enforces a flat, server-authoritative architecture: the backend decides, the local replica is what the UI observes, and every missing backend capability becomes a recorded handoff artifact instead of a client-side workaround. ## Core Features & Use Cases - Seven-step gated implementation: feature contract, flat-layer placement test, state and data model design, backend-requirement capture, bottom-up implementation, state-focused JVM tests, and a release-readiness gate (R8 release build, lint, device smoke, process death). - Backend gap handoff: missing API capabilities are written as nine-section BR-<n> artifacts in project/backend-requirements/ with a proposed OpenAPI fragment, never worked around on the device. - Failure and offline handling: all eight backend-contract outcome cases mapped into a closed result type, staleness and pending-write states, WorkManager-based queued writes with capped backoff, jitter, and deadlines. - Use Case: Ask to wire a new screen to a REST API with offline support; the Skill designs the state model, generates the client from the OpenAPI contract, implements repository and ViewModel, delegates the Compose UI, and closes with a green release build. ## Quick Start Ask the assistant to implement a feature in your Android app, for example: implement the orders list screen wired to the backend API with offline caching and queued writes.

Frequently Asked Questions about android-feature-implement

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

FAQPage Schema
How do I implement an Android feature with offline support in Kotlin?

Define a write strategy per write (online-only, queued, or local-first), serve reads from a local replica as Flow, and drain queued writes in WorkManager with connectivity constraints and capped exponential backoff. The Skill designs the staleness policy and pending-write states, then implements each layer bottom-up.

How to wire a Jetpack Compose screen to a backend API?

Generate the network client from the OpenAPI contract with openapi-generator (jvm-retrofit2, kotlinx_serialization), map DTOs at the repository boundary, and expose a single uiState StateFlow from the ViewModel. The Compose UI itself is delegated to the android-compose-ui skill.

What happens when the backend API is missing a capability the app needs?

The Skill writes a nine-section backend-requirement artifact (BR-<n>) in project/backend-requirements/ with a proposed OpenAPI fragment and agreed interim client behavior. It never implements the missing capability silently on the device.

Does this skill handle push notifications and FCM data messages?

Yes, it implements the delivery path: a FirebaseMessagingService that only enqueues WorkManager work, missed-message sync on foreground and token refresh, and immutable explicit tap PendingIntents. Channel decisions and notification construction belong to the android-notification-derive skill.

When should I not use android-feature-implement?

Use android-compose-ui for UI-only work, android-project-scaffold for creating a new project, and android-debugging for build failures, crashes, or ANRs. Read-only reviews belong to android-ux-reviewer or android-code-reviewer.

Why must verification run on a release build instead of debug?

R8 shrinking and obfuscation failures are invisible until the release build runs, so the release-readiness gate requires the release variant to assemble with the shrinker on, the touched flow exercised on a device from that variant, and process death survived without losing input.