bitwarden/android
Overview
This skill guides Android code reviews with type-specific checklists and MVVM/Compose pattern validation. It is designed for PRs, diffs, or local changes involving Kotlin, ViewModel, Composable, Repository, or Gradle files. It triggers on phrases like "review PR", "review changes", "check this code", or "Android review" and adapts depth to change risk.
How this skill works
The skill detects the change type (feature, bug fix, UI refinement, refactor, dependency, or infrastructure) using file patterns and commit metadata, then loads the matching checklist. It runs a multi-pass review focused on high-risk areas, architecture (MVVM, Hilt DI), Compose conventions, Kotlin idioms, and security/testing implications. It produces actionable feedback with precise file:line references and prioritized recommendations.
When to use it
- Review pull requests or diffs that add/modify ViewModel, Repository, or Composable code
- Validate UI-only changes under ui/ or *Screen.kt / *Composable.kt files
- Assess dependency or Gradle version updates and build changes
- Review refactorings that touch architecture or module boundaries
- Perform focused bug-fix reviews where behavior or error handling changed
Best practices
- Start by confirming PR context: linked tickets, related PRs, or explicit scope
- Use the multi-pass checklist: high-level risk, architecture, implementation, tests
- Prefer file:line_number references for every actionable comment
- Match review depth to risk: expedite dependency updates, deep-check features
- Offer concrete remediation steps and the rationale (security, performance, style)
Example use cases
- A PR adding a new LoginViewModel and LoginScreen: run the feature-addition checklist to validate DI, state handling, and tests
- A small UI tweak changing composables in ui/ package: run the UI-refinement checklist focused on theming and recomposition costs
- A version bump in libs.versions.toml or build.gradle.kts: run the dependency-update checklist for compatibility and changelog checks
- A refactor that moves repository interfaces between modules: run the refactoring checklist to verify module boundaries and API stability
- A bug-fix PR updating error handling in network repository: run the bug-fix checklist to verify tests and edge-case coverage
FAQ
It estimates risk from changed file types, new files versus edits, and presence of DI/architecture changes, then selects checklist strictness accordingly.
What patterns are explicitly validated?
MVVM boundaries, ViewModel lifecycle and state, Compose best practices (recomposition, remember, slot APIs), Hilt DI usage, repository layering, and Kotlin idioms.
How are security concerns handled?
Security checks are prioritized for high-risk changes (auth, secrets, storage, network) and reference security patterns and architecture docs for remediation.
