Swift Code Review

Reviews Swift code for concurrency safety, error handling, memory management, and common mistakes. Use when reviewing .swift files for async/await patterns,...

Security Scan

The skill is an instruction-only Swift code-review checklist that requests no binaries, credentials, or installs and its runtime instructions are consistent with its stated purpose; the only minor issue is a cross-reference to an external 'review-verification-protocol' skill that is not declared.

Purpose & Capability

Name and description (Swift concurrency, error handling, memory management review) match the content of SKILL.md and the included reference documents. The skill does not request unrelated binaries, credentials, or config paths — everything it asks the agent to do (read .swift files, apply checklist) is proportionate to the stated purpose.

Instruction Scope

Instructions are precise and scoped to reviewing Swift source (read full enclosing symbol, apply checklist, provide file:line evidence). They do not request environment secrets or external network endpoints. One note: the runtime instructions require loading and following a 'review-verification-protocol' (path ../review-verification-protocol/SKILL.md) that is not included or declared as a dependency — this creates an implicit external dependency the agent will try to resolve at runtime. That is a usability/consistency concern but not an immediate security risk by itself.

Install Mechanism

No install spec and no code files with executable content; instruction-only skill means nothing is downloaded or written to disk during install. This is the lowest-risk install footprint.

Credentials

The skill declares no environment variables, no credentials, and no config paths. The SKILL.md does not access any undeclared env vars or secrets; all referenced inputs are code files and project manifests (Package.swift, Xcode SWIFT_VERSION), which are appropriate for a code-review skill.

Persistence & Privilege

always is false and the skill is user-invocable with normal model invocation. It does not request persistent presence, nor does it instruct modifying other skills or system-wide settings. No elevated privileges are requested.

Assessment

This skill appears coherent and low-risk: it only contains review instructions and reference materials and asks for no credentials or downloads. Before installing, confirm the following: (1) the referenced 'review-verification-protocol' skill (../review-verification-protocol/SKILL.md) exists in your environment or adjust the checklist, because the SKILL.md expects it to be loaded but does not declare it; (2) the agent that will run this skill has access to the repository files (Package.swift, .swift files, Xcode project settings) so the review can be performed; and (3) you are comfortable with an instruction-only skill from an unknown publisher (no homepage provided)—if provenance matters, prefer skills from known sources or check the owner ID externally. Otherwise this skill matches its stated purpose and does not request disproportionate access.

Review Workflow

Follow this sequence in order. Do not emit findings until every Pass below is satisfied.

1. 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.

2. 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.

3. 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”).

4. 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

1. Are async operations that could run concurrently using async let?
2. Could actor state change across suspension points (reentrancy bug)?
3. Is @unchecked Sendable backed by actual synchronization?
4. Are errors logged and presented with helpful context?
5. Could any closure or delegate create a retain cycle?