home / skills / microck / ordinary-claude-skills / reviewing-changes

reviewing-changes skill

safe

This skill helps review Android-specific code changes for Bitwarden Android, applying refined change types, checklists, and reference materials for quality.

npx playbooks add skill microck/ordinary-claude-skills --skill reviewing-changes

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

4.4 KB

---
name: reviewing-changes
version: 3.0.0
description: Android-specific code review workflow additions for Bitwarden Android. Provides change type refinements, checklist loading, and reference material organization. Complements bitwarden-code-reviewer agent's base review standards.
---

# 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

<thinking>
Determine if more context is available for the changes:
1. Are there JIRA tickets or GitHub Issues mentioned in the PR title or body?
2. Are there other GitHub pull requests mentioned in the PR title or body?
</thinking>

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

<thinking>
Analyze the changeset systematically:
1. What files were modified? (code vs config vs docs)
2. What is the PR/commit title indicating?
3. Is there new functionality or just modifications?
4. What's the risk level of these changes?
</thinking>

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

<thinking>
Before diving into details:
1. What are the highest-risk areas of this change?
2. Which architectural patterns need verification?
3. What security implications exist?
4. How should I prioritize my findings?
5. What tone is appropriate for this feedback?
</thinking>

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

Overview

This skill adds Android-specific code review workflows to complement base review standards for Bitwarden Android. It detects refined change types, loads targeted checklists, and organizes Android reference materials to produce focused, actionable reviews. The goal is faster, more consistent reviews that respect Android architecture and UI conventions.

How this skill works

The skill inspects the pull request metadata and the diff to classify the change (feature, UI refinement, dependency update, infrastructure, bug fix, refactor). It pulls context links (JIRA, related PRs) when available, selects a matching checklist, and runs a multi-pass review with Android-focused checks (MVVM, Hilt DI, Compose, Gradle). When needed, it loads targeted reference files for security, testing, UI, or architecture guidance and produces line-referenced, prioritized feedback.

When to use it

When a PR modifies Android code (Kotlin, Compose, ViewModel, repositories, screens).
When you need a review that accounts for MVVM, Hilt, or Compose patterns.
When dependency or Gradle changes occur and you need expedited checks.
When UI-only changes require design- and theming-focused review.
When a PR lacks context (no JIRA/issue links) and additional details are required.

Best practices

Start by collecting PR context: link JIRA tickets and related issues or PRs.
Classify the change with Android-specific patterns before loading a checklist.
Use the multi-pass checklist: surface quick risks first, then deep architecture and tests.
Always reference exact file:line_number for issues and suggested edits.
Prioritize actionable feedback: state the fix, the reason, and the expected outcome.

Example use cases

A PR adds a new Screen.kt and ViewModel — run the Feature Addition checklist and validate navigation, DI, and state handling.
A bump in libs.versions.toml — run the Dependency Update checklist for compatibility and build checks.
A UI tweak in a Compose file — run the UI Refinement checklist and check theming, accessibility, and recomposition costs.
A refactor touching repositories and interfaces — run the Refactoring checklist to verify behavior preservation and tests.
A change to build.gradle.kts or CI workflows — run the Infrastructure checklist for reproducible builds and secrets handling.

FAQ

What level of context is required to start a review?

At minimum, include a descriptive PR title and a link to a JIRA ticket or GitHub issue. If missing, request the link before deep review.

How are security concerns surfaced?

Security checks are part of the checklist strategy; for quick issues use the security-patterns reference, and for deeper concerns consult the architecture security docs.