Reviewing Changes - Android Additions
This skill provides Android-specific workflow additions that complement the base bitwarden-code-reviewer agent standards.
Instructions
IMPORTANT: Use structured thinking throughout your review process. Plan your analysis in <thinking> tags before providing final feedback.
Step 1: Retrieve Additional Details
Retrieve any additional information linked to the pull request using available tools (JIRA MCP, GitHub API).
If pull request title and message do not provide enough context, request additional details from the reviewer:
- Link a JIRA ticket
- Associate a GitHub issue
- Link to another pull request
- Add more detail to the PR title or body
Step 2: Detect Change Type with Android Refinements
Use the base change type detection from the agent, with Android-specific refinements:
Android-specific patterns:
- Feature Addition: New
ViewModel, new Repository, new @Composable functions, new *Screen.kt files
- UI Refinement: Changes only in
*Screen.kt, *Composable.kt, ui/ package files
- Infrastructure: Changes to
.github/workflows/, gradle/, build.gradle.kts, libs.versions.toml
- Dependency Update: Changes only to
libs.versions.toml or build.gradle.kts with version bumps
Step 3: Load Appropriate Checklist
Based on detected type, read the relevant checklist file:
- Dependency Update →
checklists/dependency-update.md (expedited review)
- Bug Fix →
checklists/bug-fix.md (focused review)
- Feature Addition →
checklists/feature-addition.md (comprehensive review)
- UI Refinement →
checklists/ui-refinement.md (design-focused review)
- Refactoring →
checklists/refactoring.md (pattern-focused review)
- Infrastructure →
checklists/infrastructure.md (tooling-focused review)
The checklist provides:
- Multi-pass review strategy
- Type-specific focus areas
- What to check and what to skip
- Structured thinking guidance
Step 4: Execute Review Following Checklist
Follow the checklist's multi-pass strategy, thinking through each pass systematically.
Step 5: Consult Android Reference Materials As Needed
Load reference files only when needed for specific questions:
- Issue prioritization →
reference/priority-framework.md (Critical vs Suggested vs Optional)
- Phrasing feedback →
reference/review-psychology.md (questions vs commands, I-statements)
- Architecture questions →
reference/architectural-patterns.md (MVVM, Hilt DI, module org, error handling)
- Security questions (quick reference) →
reference/security-patterns.md (common patterns and anti-patterns)
- Security questions (comprehensive) →
docs/ARCHITECTURE.md#security (full zero-knowledge architecture)
- Testing questions →
reference/testing-patterns.md (unit tests, mocking, null safety)
- UI questions →
reference/ui-patterns.md (Compose patterns, theming)
- Style questions →
docs/STYLE_AND_BEST_PRACTICES.md
Core Principles
- Appropriate depth: Match review rigor to change complexity and risk
- Specific references: Always use
file:line_number format for precise location
- Actionable feedback: Say what to do and why, not just what's wrong
- Efficient reviews: Use multi-pass strategy, skip what's not relevant
- Android patterns: Validate MVVM, Hilt DI, Compose conventions, Kotlin idioms
1---2name: reviewing-changes3description: Guides Android code reviews with type-specific checklists and MVVM/Compose pattern validation. Use when reviewing Android PRs, pull requests, diffs, or local changes involving Kotlin, ViewModel, Composable, Repository, or Gradle files. Triggered by "review PR", "review changes", "check this code", "Android review", or code review requests mentioning bitwarden/android. Loads specialized checklists for feature additions, bug fixes, UI refinements, refactoring, dependency updates, and infrastructure changes.4---5
6# Reviewing Changes - Android Additions
7
8This skill provides Android-specific workflow additions that complement the base `bitwarden-code-reviewer` agent standards.
9
10## Instructions
11
12**IMPORTANT**: Use structured thinking throughout your review process. Plan your analysis in `<thinking>` tags before providing final feedback.
13
14### Step 1: Retrieve Additional Details
15
16<thinking>
17Determine if more context is available for the changes:
181. Are there JIRA tickets or GitHub Issues mentioned in the PR title or body?
192. Are there other GitHub pull requests mentioned in the PR title or body?
20</thinking>
21
22Retrieve any additional information linked to the pull request using available tools (JIRA MCP, GitHub API).
23
24If pull request title and message do not provide enough context, request additional details from the reviewer:
25- Link a JIRA ticket
26- Associate a GitHub issue
27- Link to another pull request
28- Add more detail to the PR title or body
29
30### Step 2: Detect Change Type with Android Refinements
31
32<thinking>
33Analyze the changeset systematically:
341. What files were modified? (code vs config vs docs)
352. What is the PR/commit title indicating?
363. Is there new functionality or just modifications?
374. What's the risk level of these changes?
38</thinking>
39
40Use the base change type detection from the agent, with Android-specific refinements:
41
42**Android-specific patterns:**
43- **Feature Addition**: New `ViewModel`, new `Repository`, new `@Composable` functions, new `*Screen.kt` files
44- **UI Refinement**: Changes only in `*Screen.kt`, `*Composable.kt`, `ui/` package files
45- **Infrastructure**: Changes to `.github/workflows/`, `gradle/`, `build.gradle.kts`, `libs.versions.toml`
46- **Dependency Update**: Changes only to `libs.versions.toml` or `build.gradle.kts` with version bumps
47
48### Step 3: Load Appropriate Checklist
49
50Based on detected type, read the relevant checklist file:
51
52- **Dependency Update** → `checklists/dependency-update.md` (expedited review)
53- **Bug Fix** → `checklists/bug-fix.md` (focused review)
54- **Feature Addition** → `checklists/feature-addition.md` (comprehensive review)
55- **UI Refinement** → `checklists/ui-refinement.md` (design-focused review)
56- **Refactoring** → `checklists/refactoring.md` (pattern-focused review)
57- **Infrastructure** → `checklists/infrastructure.md` (tooling-focused review)
58
59The checklist provides:
60- Multi-pass review strategy
61- Type-specific focus areas
62- What to check and what to skip
63- Structured thinking guidance
64
65### Step 4: Execute Review Following Checklist
66
67<thinking>
68Before diving into details:
691. What are the highest-risk areas of this change?
702. Which architectural patterns need verification?
713. What security implications exist?
724. How should I prioritize my findings?
735. What tone is appropriate for this feedback?
74</thinking>
75
76Follow the checklist's multi-pass strategy, thinking through each pass systematically.
77
78### Step 5: Consult Android Reference Materials As Needed
79
80Load reference files only when needed for specific questions:
81
82- **Issue prioritization** → `reference/priority-framework.md` (Critical vs Suggested vs Optional)
83- **Phrasing feedback** → `reference/review-psychology.md` (questions vs commands, I-statements)
84- **Architecture questions** → `reference/architectural-patterns.md` (MVVM, Hilt DI, module org, error handling)
85- **Security questions (quick reference)** → `reference/security-patterns.md` (common patterns and anti-patterns)
86- **Security questions (comprehensive)** → `docs/ARCHITECTURE.md#security` (full zero-knowledge architecture)
87- **Testing questions** → `reference/testing-patterns.md` (unit tests, mocking, null safety)
88- **UI questions** → `reference/ui-patterns.md` (Compose patterns, theming)
89- **Style questions** → `docs/STYLE_AND_BEST_PRACTICES.md`
90
91## Core Principles
92
93- **Appropriate depth**: Match review rigor to change complexity and risk
94- **Specific references**: Always use `file:line_number` format for precise location
95- **Actionable feedback**: Say what to do and why, not just what's wrong
96- **Efficient reviews**: Use multi-pass strategy, skip what's not relevant
97- **Android patterns**: Validate MVVM, Hilt DI, Compose conventions, Kotlin idioms
majiayu000