skills/android/android-compose-migration/SKILL.md
Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.
npx skillsauth add hoangnguyen0403/agent-skills-standard android-compose-migrationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Structured 10-step workflow for migrating XML layouts to Compose.
If the user specified a target XML layout, proceed to Step 2. Otherwise, pick the best candidate:
Examine the XML structure: list all Views, data bindings, click listeners, style references, and custom Views needing AndroidView wrappers.
Generate a checklist of every View → Composable mapping. Present to user for approval.
Ask the user for a screenshot, or take one via emulator for visual comparison.
Check build.gradle.kts or libs.versions.toml for Compose BOM and compiler. If missing, add them. See dependency setup.
If missing, initialize minimum required theme — map XML colors/styles to Compose. Do NOT migrate the entire theme.
Convert each View to its Compose equivalent. See interop patterns for the View→Composable mapping table, ComposeView, and AndroidView usage. Include a @Preview for every new Composable.
Use LazyColumn or LazyRow for list-heavy screens instead of flattening them into one large static composable.
Use ComposeView to host Compose in Views, or AndroidView for Views in Compose. See interop patterns.
Compare baseline screenshot with Compose Preview. Focus on layout and styling. Iterate until visual parity.
Delete the migrated XML file and legacy tests. Only remove code not referenced elsewhere.
./gradlew build succeeds.testing
Infer the requesting operator's technical fluency from message content (never ask directly) and adapt register — business, hybrid, or technical — across SDLC workflow output. Use when starting sdlc, brainstorm-feature, plan-feature, verify-work, publish-notes, or session-report, or whenever a request's phrasing signals a non-technical or cross-stack operator.
documentation
Define transaction boundaries, locking, and consistency guarantees for multi-step writes. Use when designing atomic operations, retries, idempotency, or concurrent write behavior.
development
Design relational or document schemas from access patterns, cardinality, and lifecycle. Use when modeling entities, choosing embed vs normalize, or shaping schema boundaries before implementation.
data-ai
Diagnose database latency with explain plans, index ownership, and query-shape review. Use when a query is slow, an index is missing, or scans and N+1 patterns appear.