From developer-workflow
Migrates Android View-based UIs (Activities, Fragments, custom Views/ViewGroups) to Jetpack Compose via pattern analysis, gap identification, implementation, and visual/structural verification.
npx claudepluginhub kirich1409/krozov-ai-tools --plugin developer-workflowThis skill uses the workspace's default tool permissions.
**Core principle:** Understand the screen deeply before touching it → discover how the rest of the app uses Compose → identify what's missing → capture a visual baseline → migrate → verify appearance and structure match.
evals/evals.jsonevals/fixtures/eval-1-fragment/OrderListFragment.ktevals/fixtures/eval-1-fragment/OrderListViewModel.ktevals/fixtures/eval-1-fragment/fragment_order_list.xmlevals/fixtures/eval-2-activity/LoginActivity.ktevals/fixtures/eval-2-activity/activity_login.xmlevals/fixtures/eval-3-custom-view/RatingBarView.ktreferences/custom-view-migration.mdreferences/discovery-and-patterns.mdreferences/migration-and-verify.mdreferences/view-to-compose-mapping.mdProvides expertise in Jetpack Compose and Compose Multiplatform for UI development across Android, Desktop, iOS, Web. Covers APIs, navigation, Paging 3, Android TV, design systems, and PR reviews.
Guides building Android UIs with Jetpack Compose: project setup, MVVM state management with ViewModels/StateFlow, navigation, performance optimization, Material 3.
Guides building native Android UIs with Jetpack Compose, including state management via remember/mutableStateOf, state hoisting, and ViewModel integration.
Share bugs, ideas, or general feedback.
Core principle: Understand the screen deeply before touching it → discover how the rest of the app uses Compose → identify what's missing → capture a visual baseline → migrate → verify appearance and structure match.
Never write a single line of Compose until the pattern analysis and gap analysis are done.
Do not do any of the following without explicit user approval:
When you encounter a bug or missing feature: Add it to an "Issues found" section in the migration report and ask the user.
Unavoidable behavior differences: Document the difference, propose the closest Compose behavior, and ask the user before proceeding.
DISCOVER → ANALYZE PATTERNS → GAP ANALYSIS → CONFIRM → IMPLEMENT GAPS → MIGRATE → STATIC VERIFY → VIEW API AUDIT → [device: manual-tester agent (QA)]
First, identify the source type (Activity/Fragment/Custom View) — this shapes the migration strategy. See references/discovery-and-patterns.md for the source type table and detailed inventory checklist.
Read every file that makes up the target: XML layout, host class, ViewModel, nested custom Views, adapters, and referenced resources. Build a mental model of: what data is displayed, what interactions exist, and which parts are complex or risky.
Inventory all animations — they are easy to miss and silently drop. See references/discovery-and-patterns.md for the full animation inventory checklist.
Produce a behavior-scenarios.md — captures everything the screen does. Grouped by: visual states, interactions, side effects, edge cases. See references/discovery-and-patterns.md for the template and examples. This document becomes the verification checklist for all subsequent phases.
Mandatory. Launch the compose-developer agent to discover project patterns and produce a Pattern Summary. Also determine state stream conventions and event transport compatibility yourself. See references/discovery-and-patterns.md for full details.
For each UI element with no shared Compose equivalent, resolve using priority: existing UI Kit → already-imported libraries → suggest new library → write custom component. See references/discovery-and-patterns.md for the full priority order and documentation format.
Custom Views are mandatory migration scope — they must be fully migrated to Compose composables, not wrapped in AndroidView. See references/custom-view-migration.md for the decision tree: classify → search for replacements → assess feasibility → choose strategy.
Present the gap list to the user and confirm before proceeding.
Present a migration plan before writing any Compose code:
behavior-scenarios.md for user confirmationSee references/discovery-and-patterns.md for screenshot testing guidance. Wait for explicit user approval.
Resolve missing components before writing the screen. See references/discovery-and-patterns.md for the implementation priority order.
Use the compose-developer agent. Brief it with: all files from Phase 1, pattern constraints from Phase 2, shared components from Phase 2 + Phase 5.
The migration produces:
FooScreen.kt with screen composable and sub-composablesKey constraints — see references/migration-and-verify.md for full details:
when, stability annotations, correct string typeinternal by defaultdp/hex valuesFor View→Compose component mapping, see references/view-to-compose-mapping.md — covers RecyclerView, Custom Views, animations, WindowInsets, ViewPager, CoordinatorLayout, BottomSheet, ItemTouchHelper, permissions, focus management, and more.
See references/migration-and-verify.md for detailed fidelity review checklist and migration report template.
behavior-scenarios.md and XML element by element: layout structure, visual properties, behavioral details, architecture, window insetsmigration-report.md — replacements, new components, ViewModel changes, behavior verification status, visual comparison table, deviations, issues foundAfter static checks pass: proceed to View API Audit.
Mandatory. Scan all migrated and touched files for remaining View-system API usage. Nothing from the old View world should survive in new Compose code unless explicitly allowed.
See references/migration-and-verify.md for the full scan procedure, prohibited API list, and allowlist format.
AndroidView, ComposeView), or a false positivebehavior-scenarios.md, skip approved usagesThe audit result is appended to migration-report.md as a "View API Audit" section.
Brief the manual-tester agent with behavior-scenarios.md, the migration report, and interaction list. It captures before/after screenshots, executes all test cases, and populates the screenshot table. See references/migration-and-verify.md for briefing details.
Once verification passes, offer to clean up (never automatically). Propose deleting old files: Activity/Fragment, XML layouts, adapters, ViewHolders, binding classes, DiffUtil callbacks. Also review: nav graph, DI/Hilt modules. Run project-wide usage search before any deletion. See references/migration-and-verify.md for the full checklist.