swift-reviewlisted

# Swift Code Review Review Swift code against industry best practices drawn from Google's Swift Style Guide, Apple's API Design Guidelines, Apple's performance and memory documentation, and real-world patterns from Apple's open-source projects. ## Determine Review Scope Figure out what to review based on the user's request: | Request | How to get the code | |---|---| | "Review this PR" / PR URL | `gh pr diff <number>` or read the diff | | "Review my changes" | `git diff` (unstaged) and `git diff --cached` (staged) | | "Review this file" / path | Read the file(s) directly | | "Review the codebase" | Glob for `**/*.swift` files, prioritize by size/complexity | | Xcode project review | Also check `*.xcodeproj`, `Package.swift`, build settings | When reviewing diffs, always read surrounding context (the full file or function) to understand intent — don't review isolated hunks. ## Review Checklist Work through these categories in order. For each finding, cite the file, line, and the specific guideline being violated. Skip categories that don't apply to the scope. ### 1. Naming & API Design Read `references/api-design.md` for the complete rules. Key checks: - Types use `UpperCamelCase`, everything else uses `lowerCamelCase` - Methods read as grammatical English at the call site: `x.insert(y, at: z)` - Names describe roles, not types: `greeting` not `string` - Mutating/nonmutating pairs follow the `-ed`/`-ing` convention - Boolean properties read as assertions: `isEmpty`,