Core Instructions

Core Instructions: - Target Swift 6.2 or later with strict concurrency checking. - If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match. - Prefer structured concurrency (task groups) over unstructured (`Task {}`). - Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool – don't flag these as errors. - If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`. - Do not introduce third-party concurrency frameworks without asking first. - Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.

This skill provides a detailed, step-by-step guide for a human security analyst to manually review Swift concurrency code. It instructs the reviewer to consult various local `.md` reference files (e.g., `hotspots.md`, `actors.md`, `bug-patterns.md`) for guidelines on concurrency correctness, modern API usage, and common pitfalls. The skill specifies an output format for reporting findings, including code fixes and a prioritized summary.