---
name: swift-review
description: >
  Reviews Swift/Xcode codebases, pull requests, local changes, or individual files against
  Swift best practices including Google's Swift Style Guide, Apple's API Design Guidelines,
  build performance, memory management, and testing standards. Use this skill whenever the
  user asks to review Swift code, audit a Swift PR, check Swift style, review an Xcode
  project, or mentions swift code review, swift lint, swift best practices review, or
  swift code quality. Also trigger when reviewing .swift files, Package.swift, or Xcode
  project changes — even if the user just says "review this" or "check this code" and
  the context involves Swift.
license: MIT
metadata:
  author: github.com/bastos
  version: "1.0"
---

# 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`, `isValid`
- Factory methods start with `make`
- Protocol names use nouns for "what it is", `-able`/`-ible` for capabilities
- Argument labels form grammatical phrases with the method name
- No abbreviations unless universally understood (`min`, `max`, `URL`)

### 2. Code Style & Formatting

Read `references/code-style.md` for the complete rules.

Key checks:
- 100-character line limit
- K&R brace style (opening brace on same line)
- No semicolons
- One statement per line
- `//` comments only, never `/* */`
- One variable per `let`/`var` declaration
- Trailing commas in multiline array/dictionary literals
- Imports grouped: standard modules, then individual declarations, then `@testable`
- `// MARK:` comments to organize type members
- Shorthand syntax for arrays `[Element]`, dictionaries `[Key: Value]`, optionals `T?`

### 3. Swift Patterns & Idioms

Read `references/swift-patterns.md` for the complete rules.

Key checks:
- `guard` for early exits instead of nested `if` blocks
- `for-where` instead of `for` + single `if` body
- `Optional` over sentinel values (`-1`, empty string)
- Errors thrown, not merged with return types
- No force-unwrap (`!`) without a comment explaining the invariant
- No implicitly unwrapped optionals except `@IBOutlet` and test fixtures
- Explicit access control where it differs from `internal`
- Nested types for scoping (error types, flag enums inside their parent)
- Prefer `let` over `var` when value doesn't change
- Prefer value types (`struct`, `enum`) over `class` when no identity needed
- Protocol extensions for default implementations, not base classes
- Computed properties omit `get` when read-only

### 4. Build Performance

Read `references/performance.md` for the complete rules.

Key checks:
- No complex expressions that slow type-checker (break into smaller statements)
- Explicit types on complex closures and collection literals
- Minimize use of `AnyObject`, `Any` — prefer concrete or generic types
- No unnecessary `@objc` or `dynamic` unless needed for Objective-C interop
- Module boundaries are clean — no circular dependencies
- Prefer `final` on classes not designed for inheritance (enables compiler optimizations)
- Large expressions broken into smaller sub-expressions with explicit types
- No excessive protocol conformance in extensions across files (merge where logical)

### 5. Memory Management

Read `references/memory-management.md` for the complete rules.

Key checks:
- No retain cycles in closures — use `[weak self]` or `[unowned self]` appropriately
- `weak` preferred over `unowned` unless lifetime is guaranteed
- Delegates declared as `weak var`
- Large resources freed in `deinit` or on memory warnings
- Discardable resource caches use `NSCache` with count/cost limits; deterministic
  maps or non-discardable data may use bounded dictionaries
- Autoreleasepool used in tight loops creating many temporary objects
- No strong reference chains between parent and child objects
- Image and data caches have size limits
- Observation tokens stored and invalidated properly

### 6. Testing

Read `references/testing.md` for the complete rules.

Key checks:
- Test methods named descriptively: `test_<condition>_<expectedResult>`
- One assertion concept per test (test may have setup + multiple related asserts)
- No test interdependencies — each test stands alone
- `setUp()` / `tearDown()` used for shared fixtures, not duplicated in every test
- Async code tested with expectations or Swift concurrency
- UI tests separated from unit tests
- Edge cases covered: nil, empty, boundary values, error paths
- No network calls in unit tests — use protocols and mocks
- Force-unwrap permitted in tests (fails the test if nil, which is desired)

### 7. Documentation

Key checks:
- Public API has `///` doc comments with summary, parameters, returns, throws
- Doc comments use verb phrases for methods, noun phrases for properties
- No `/** */` block comment syntax
- `Parameter`, `Returns`, `Throws` tags in that order
- Complex algorithms have inline comments explaining why, not what

### 8. Concurrency (if applicable)

Key checks:
- `@Sendable` closures don't capture mutable state
- Actors used for mutable shared state instead of locks
- `MainActor` for UI updates
- No data races — `nonisolated` used intentionally
- Structured concurrency (`async let`, `TaskGroup`) preferred over unstructured `Task {}`
- Cancellation handled properly

## Output Format

Structure the review as:

```
## Summary
<1-2 sentence overall assessment>

## Findings

### Critical
<issues that will cause bugs, crashes, or data loss>

### Important
<style violations, performance issues, missing tests>

### Suggestions
<minor improvements, alternative approaches>

## What's Done Well
<2-3 things the code does right — always include this>
```

For each finding, include:
- **File and line**: `Sources/Auth/TokenManager.swift:42`
- **Category**: which checklist item it falls under
- **Issue**: what's wrong
- **Fix**: concrete code suggestion or direction

Keep findings actionable. Don't flag things that are clearly intentional project
conventions unless they cause real problems.


---
Source attribution: jcasnellie69
Original project: https://github.com/jcasnellie69/homelab-config/blob/main/.agents/skills/swift-review/SKILL.md
License: MIT
License information: https://opensource.org/license/mit
Original upstream instructions; downloaded from Mega AI Hub.

## Upstream license notice

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.



# Mega AI Hub resource metadata

Creator / publisher: jcasnellie69
Original project: https://github.com/jcasnellie69/homelab-config/blob/main/.agents/skills/swift-review/SKILL.md
Attribution basis: Source repository record

Fields of work: Development & Engineering, Product Management
Roles: Backend Developer, Frontend Developer, Mobile Developer, Product Manager, QA / Test Engineer
Specialties: Backend, Cross Platform, Frontend, Mobile
Tools: Tool not specified
Country applicability: Country not specified
Classification basis: Source catalog labels
Instruction SHA-256: ea244083afd5301456b00bdee46225d08bb674b1f1d5ea5649a48f56c820dda9