swift-code-review

name swift-code-review description Reviews Swift code for concurrency safety, error handling, memory management, and common mistakes. Use when reviewing .swift files for async/await patterns, actor isolation, Sendable conformance, or general Swift best practices. Swift Code Review Review Workflow Follow this sequence in order . Do not emit findings until every Pass below is satisfied. Swift / toolchain baseline — Establish language and tooling context: Package.swift // swift-tools-version and any per-target Swift language version or swiftSettings in the manifest; for Xcode, SWIFT_VERSION (or equivalent) in project or target build settings; note if review is single-file only. Pass: You state a concrete Swift language version or mode (e.g. Swift 6 language mode, tools 5.10) before advice that depends on strict concurrency, migration-only syntax, or SDK availability. Read surrounding code — For each changed .swift file, read the full enclosing type, function, method, or property that contains the edits, not only the diff hunk. Pass: At least one full enclosing symbol (type or member) containing the change was read per changed file. Scope the checklist — Using Quick Reference , decide which Review Checklist rows and references apply; open those reference files; skip rows clearly unrelated to the diff. Pass: The review (or working notes) lists which checklist areas you applied, or marks areas N/A with a one-line reason tied to the diff (e.g. “no SwiftUI / @Observable in change”). Pre-report verification — Load and follow review-verification-protocol . Pass: That skill’s Hard gates (sequenced) are satisfied for each finding you will report (full symbol read, usage search before “unused”, caller checked before “missing handling”, severity calibrated, [FILE:LINE] proof). Hard gates (same sequence, shorter) Step Objective pass condition 1 Swift version/mode (or explicit single-file limitation) recorded before version- or SDK-gated advice. 2 Full enclosing symbol read per changed file, not diff-only. 3 Checklist areas + references listed or N/A with diff-tied reason. 4 review-verification-protocol completed for every reported issue. Output format Report findings as: [FILE:LINE] ISSUE_TITLE Severity: Critical | Major | Minor | Informational Description of the issue and why it matters. Quick Reference Issue Type Reference async/await, actors, Sendable, Task references/concurrency.md @Observable, @ObservationIgnored, @Bindable references/observable.md throws, Result, try?, typed throws references/error-handling.md Force unwraps, retain cycles, naming references/common-mistakes.md Review Checklist No force unwraps ( ! ) on runtime data (network, user input, files) Closures stored as properties use [weak self] Delegate properties are weak Independent async operations use async let or TaskGroup Long-running Tasks check Task.isCancelled Actors have mutable state to protect (no stateless actors) Sendable types are truly thread-safe (beware @unchecked ) Errors handled explicitly (no empty catch blocks) Custom errors conform to LocalizedError with descriptive messages Nested @Observable objects are also marked @Observable @Bindable used for two-way bindings to Observable objects When to Load References Reviewing async/await, actors, or TaskGroups → concurrency.md Reviewing @Observable or SwiftUI state → observable.md Reviewing error handling or throws → error-handling.md General Swift review → common-mistakes.md Review Questions Are async operations that could run concurrently using async let ? Could actor state change across suspension points (reentrancy bug)? Is @unchecked Sendable backed by actual synchronization? Are errors logged and presented with helpful context? Could any closure or delegate create a retain cycle?