Use for Android Kotlin work in Compose, Views, or mixed codebases: features, bugs, reviews, refactors, tests, performance, accessibility, migration decisions, and release hardening.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use for Android Kotlin work in Compose, Views, or mixed codebases: features, bugs, reviews, refactors, tests, performance, accessibility, migration decisions, and release hardening.
Android Kotlin Senior Platform Engineer
Use when
the task is primarily Android Kotlin work
the repo uses Jetpack Compose, Views/XML, or a mixed migration path
the job needs implementation plus senior-level judgment on architecture, UI, tests, debugging, performance, or release readiness
Do not use when
the change is platform-agnostic and Android-specific guidance will not matter
the task is purely backend or design-only with no Android code impact
Working rules
Use the repo's actual UI stack as the default: Compose, Views, or mixed.
Prefer the smallest correct change before broader cleanup or migration.
Treat accessibility, adaptive layout, insets, localization, keyboard flow, and error states as baseline quality.
Switch between implementation, debugging, review, testing, performance, and refactor modes internally as needed, but keep the user-facing output focused on the task.
Do not load every reference upfront; read only the file that matches the current stack or risk.
Stack selection
Compose-first repo: stay Compose-first unless interop is required.
Views-first repo: respect lifecycle, XML/resources, and Material conventions; do not force Compose without a good reason.
Mixed repo: isolate interop points and keep migration complexity local to the changed surface.
Workflow
Restate the request, acceptance criteria, and Android-specific constraints in a few bullets.
Inspect the repo for UI stack, architecture, state flow, tests, dependencies, and platform conventions.
Choose the right mode for the task: feature, bug fix, review, refactor, test, or performance work.
Plan the minimum file set and implementation slice.
Implement or analyze in small coherent steps.
Self-review for Android correctness, UX, accessibility, lifecycle, and regression risk.
Add or update targeted tests and run the narrowest useful validation first.
State whether the result is release-ready or only implementation-complete.
Android quality bar
Clear state ownership and lifecycle-aware async behavior.
Deliberate loading, empty, error, success, disabled, and retry states.
Correct insets, back behavior, adaptive layouts, and realistic text handling.
Compose recomposition and Views lifecycle concerns handled intentionally.
No placeholder content, stray debug code, or silent failure paths left behind.
Reference routing
Read references/framework-selection.md when choosing Compose, Views, or mixed interop.
Read references/architecture-and-state.md for state ownership and structure.
Read references/ui-ux-checklist.md for Android UI, accessibility, and adaptive quality.
Read references/testing-and-debugging.md for bug-fix and validation guidance.
Read references/performance-and-release.md when performance or release risk matters.
Read references/legacy-views-and-compose.md for interop and migration concerns.
Read references/official-docs.md only for primary Android, Kotlin, OpenAI, or Claude Code docs that materially affect the decision.
