reviewing-changes

name

reviewing-changes

description

Performs comprehensive code reviews for Bitwarden iOS projects, verifying architecture compliance, style guidelines, compilation safety, test coverage, and security requirements. Use when reviewing pull requests, checking commits, analyzing code changes, verifying Bitwarden coding standards, evaluating unidirectional data flow pattern, checking services container dependency injection usage, reviewing security implementations, or assessing test coverage. Automatically invoked by CI pipeline or manually for interactive code reviews.

Reviewing Changes — Bitwarden iOS

Instructions

Work systematically through each step before providing feedback. Each checklist loads only the relevant review strategy for the change type detected.

Step 1: Retrieve Additional Details

Fetch any additional context using available tools (JIRA MCP, GitHub API). If the PR title and description don't provide enough context, request:

• A link to the JIRA ticket
• A GitHub issue reference
• More detail in the PR description

iOS-specific metadata checks:

• Screenshots required for any *View.swift changes that affect visible UI — flag as ❓ if absent
• If new *Processor.swift or *Service.swift is added with no test file, flag as ❓

Step 2: Detect Change Type

iOS-specific patterns:

• Feature Addition: New *Coordinator.swift, *Processor.swift, *View.swift (full file-set); new screen or flow
• Bug Fix: Targeted changes to existing *Processor.swift, *Service.swift, or *Repository.swift files
• UI Change: Changes only to *View.swift files; no business logic changes
• Refactoring: Renamed/restructured files without new user-visible behavior
• Dependency Update: Changes to Mintfile, project-*.yml version references, Package.swift
• Infrastructure: Changes to Scripts/, Configs/, .github/, fastlane/

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: fix correctness + regression test)
• Feature Addition → checklists/feature-addition.md (comprehensive: all areas)
• UI Change → checklists/ui-change.md (UDF compliance + accessibility + snapshots)
• Refactoring → Full architecture check: verify behavior-preserving via reference/ios-architecture-patterns.md
• Infrastructure → Security review + deployment impact assessment

The checklist provides: multi-pass review strategy, type-specific focus areas, what to check and what to skip.

Step 4: Execute Review Following Checklist

Follow the checklist's review strategy, thinking through each pass systematically before writing feedback.

Step 5: Consult Reference Materials As Needed

Load reference files only when needed for specific questions:

• Re-reviews (incremental) → invoke reviewing-incremental-changes agent skill; scope to changed lines only, do not flag new issues in unchanged code
• Issue prioritization → reference/priority-framework.md (Critical vs Important vs Suggested)
• Phrasing feedback → reference/feedback-psychology.md (questions vs commands, I-statements)
• Architecture questions → reference/ios-architecture-patterns.md + Docs/Architecture.md
• Security questions → reference/ios-security-patterns.md
• Testing questions → reference/ios-testing-patterns.md
• Style questions → reference/ios-style-patterns.md
• Output format → examples/annotated-example.md

Core Principles

• Priority order: Security → Correctness → Breaking Changes → Performance → Maintainability
• Appropriate depth: Match review rigor to change complexity and risk. A dependency update doesn't need architecture review.
• Specific references: Always use file:line_number format for precise locations
• Actionable feedback: Say what to change and why — not just what's wrong
• Efficient reviews: Use the change-type checklist, skip what's not relevant
• iOS patterns: Validate UDF, Has* DI, store.binding, Sourcery mock conventions, StateProcessor subclass