Reviewing Changes Agent Skill

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