Use when designing or reviewing Swift protocols, generics, `some`/`any`, enums, domain types, associated types, typed throws, or public API resilience. Do not invoke for a local implementation change with no API decision.
Use for a retrospective audit of a Swift codebase or target to identify prioritized correctness, architecture, modernization, safety, and performance improvements. It is read-only unless the user requests implementation.
Use when Swift code crosses actors or tasks, handles `Sendable`/`sending`, async isolation, cancellation, `TaskGroup`, `Mutex`, atomics, or Swift 6 strict-concurrency diagnostics. Do not invoke for synchronous code with no shared state or isolation boundary.
Use for implementing a non-trivial Swift 6.3 feature, bug fix, or refactor. It coordinates repository inspection, relevant domain skills, implementation, and proof; it does not authorize unrelated cleanup.
Use when a Swift feature contains policy, evaluation, parsing, validation, state transitions, or deterministic business logic that can be separated from I/O. Do not force this skill onto inherently imperative resource or UI code.
Use when Swift code owns a unique resource, has `~Copyable`/`borrowing`/`consuming` diagnostics, or needs an ownership-aware API. Do not invoke for ordinary value-type refactors with no lifetime or transfer invariant.
Use when the task claims a latency, throughput, allocation, memory, startup, compilation, or energy improvement, or when optimizing hot Swift code. Do not make performance changes from intuition alone.
Use for an adversarial review of a Swift diff or pull request. Review only the supplied change and its necessary context; do not modify code or turn style preferences into blockers.