reviewing-changes

# 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