android-ui-compose
This skill is used to implement Android UI in Jetpack Compose based on an existing UX flow, focusing on clear hierarchy, list vs form separation and discoverable navigation.
When & Why to Use This Skill
This Claude skill streamlines the Android development process by translating UX designs into clean, maintainable Jetpack Compose code. It focuses on creating logical UI hierarchies, separating lists from forms, and ensuring intuitive navigation, all while maintaining consistency with existing project styles and Material Design components to improve developer productivity and UI quality.
Use Cases
- Translating UX design specifications and wireframes into functional Jetpack Compose screen layouts and reusable UI components.
- Implementing structured data entry forms and list views with optimized hierarchy and clear navigation paths for Android applications.
- Standardizing Android UI code across a project by reusing existing Material components, padding, shapes, and typography to ensure visual consistency.
- Creating robust empty states and interactive hints within Android apps to improve user onboarding and overall application usability.
- Refactoring existing Android UI code to better separate concerns between list displays and editing interfaces using modern Compose best practices.
| name | android-ui-compose |
|---|---|
| description | This skill is used to implement Android UI in Jetpack Compose based on an existing UX flow, focusing on clear hierarchy, list vs form separation and discoverable navigation. |
Android UI Compose Implementation Skill
Purpose
Translate UX designs into concrete Jetpack Compose layouts that feel clean and consistent. Keep lists as lists, forms as forms, and navigation discoverable.
When to Use
Use this skill when a UX flow and section structure already exist and the UI needs to be implemented or refined in Kotlin with Compose.
Outputs
- Composable functions for screens and components
- Layout that reflects hierarchy and sections
- Item rows or cards for existing entities
- Forms for creation or editing in a controlled place
- Empty states and hints
Procedure
- Take the UX specification and identify:
- The main screen composable.
- Reusable item composables (for example ListCard, TaskRow).
- Places where dialogs, sheets or snackbars are required.
- Implement a clear structure:
- Top level scaffold with a top bar and optional bottom bar if used elsewhere.
- A “create new” section that is visually separate from the list of existing items.
- A LazyColumn or relevant container for lists of items.
- For existing items:
- Represent them as rows or cards, not full edit forms.
- Include:
- Primary text (for example list name or task title).
- Optional secondary text (for example due date, list summary).
- Tappable checkbox or icon where appropriate.
- A clear tap target to open details or edit.
- For editing:
- Use either:
- An inline expanded row for the item that is currently being edited, or
- A dialog or bottom sheet with labelled fields.
- Allow editing one item at a time to avoid visual overload.
- Use either:
- Implement empty states and hints:
- Use simple text and spacing to explain what to do.
- Keep add buttons and initial actions visible in empty states.
- Align with existing styling:
- Use Material components already present in the project.
- Reuse padding, shapes and typography from existing screens.
- Keep component names consistent with the codebase.
Guardrails
- Do not embed full edit forms inside every list row by default.
- Do not hide navigation in subtle click targets; ensure rows are clearly interactive.
- Do not introduce new design systems, libraries or icon packs.
- Do not alter ViewModel contracts or data models; treat state as given.