swift-concurrency-pro
Skill1 starsChanged 8 months agoMITView on GitHub
Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.
We split this skill into the rules it gives an agent
14 rules. 4 are common, 0 are distinctive, and 10 are very specific to this project.
4
Common
Most of the 4 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Check for recent Swift 6.2 concurrency behavior using references/new-features.md.
- Very specific: line 17
Ensure structured concurrency is preferred over unstructured where appropriate using references/structured.md.
- Very specific: line 18
Check unstructured task usage for correctness using references/unstructured.md.
- Very specific: line 19
Verify cancellation is handled correctly using references/cancellation.md.
- Very specific: line 21
Check bridging code between sync and async worlds using references/bridging.md.
- Very specific: line 24
If the project has strict-concurrency errors, map diagnostics to fixes using references/diagnostics.md.
- Very specific: line 25
If reviewing tests, check async test patterns using references/testing.md.
- Common: line 27
If doing a partial review, load only the relevant reference files.
- Common: line 33
If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.
- Very specific: line 34
Prefer structured concurrency (task groups) over unstructured (Task {}).
- Common: line 35
Prefer Swift concurrency over Grand Central Dispatch for new code.
- Very specific: line 36
If an API offers both async/await and closure-based variants, always prefer async/await.
- Common: line 37
Do not introduce third-party concurrency frameworks without asking first.
- Very specific: line 38
Do not suggest @unchecked Sendable to fix compiler errors.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review Swift concurrency code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.
Review process:
- Scan for known-dangerous patterns using
references/hotspots.mdto prioritize what to inspect. - Check for recent Swift 6.2 concurrency behavior using
references/new-features.md. - Validate actor usage for reentrancy and isolation correctness using
references/actors.md. - Ensure structured concurrency is preferred over unstructured where appropriate using
references/structured.md. - Check unstructured task usage for correctness using
references/unstructured.md. - Verify cancellation is handled correctly using
references/cancellation.md. - Validate async stream and continuation usage using
references/async-streams.md. - Check bridging code between sync and async worlds using
references/bridging.md. - Review any legacy concurrency migrations using
references/interop.md. - Cross-check against common failure modes using
references/bug-patterns.md. - If the project has strict-concurrency errors, map diagnostics to fixes using
references/diagnostics.md. - If reviewing tests, check async test patterns using
references/testing.md.
If doing a partial review, load only the relevant reference files.
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/awaitand closure-based variants, always preferasync/await. - Do not introduce third-party concurrency frameworks without asking first.
- Do not suggest
@unchecked Sendableto fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, orsendingparameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.
Output Format
Organize findings by file. For each issue:
- State the file and relevant line(s).
- Name the rule being violated.
- Show a brief before/after code fix.
Skip files with no issues. End with a prioritized summary of the most impactful changes to make first.
Example output:
DataLoader.swift
Line 18: Actor reentrancy – state may have changed across the await.
// Before
actor Cache {
var items: [String: Data] = [:]
func fetch(_ key: String) async throws -> Data {
if items[key] == nil {
items[key] = try await download(key)
}
return items[key]!
}
}
// After
actor Cache {
var items: [String: Data] = [:]
func fetch(_ key: String) async throws -> Data {
if let existing = items[key] { return existing }
let data = try await download(key)
items[key] = data
return data
}
}Line 34: Use withTaskGroup instead of creating tasks in a loop.
// Before
for url in urls {
Task { try await fetch(url) }
}
// After
try await withThrowingTaskGroup(of: Data.self) { group in
for url in urls {
group.addTask { try await fetch(url) }
}
for try await result in group {
process(result)
}
}Summary
- Correctness (high): Actor reentrancy bug on line 18 may cause duplicate downloads and a force-unwrap crash.
- Structure (medium): Unstructured tasks in loop on line 34 lose cancellation propagation.
End of example.
References
references/hotspots.md- Grep targets for code review: known-dangerous patterns and what to check for each.references/new-features.md- Swift 6.2 changes that alter review advice: default actor isolation, isolated conformances, caller-actor async behavior,@concurrent,Task.immediate, task naming, and priority escalation.references/actors.md- Actor reentrancy, shared-state annotations, global actor inference, and isolation patterns.references/structured.md- Task groups over loops, discarding task groups, concurrency limits.references/unstructured.md- Task vs Task.detached, when Task {} is a code smell.references/cancellation.md- Cancellation propagation, cooperative checking, broken cancellation patterns.references/async-streams.md- AsyncStream factory, continuation lifecycle, back-pressure.references/bridging.md- Checked continuations, wrapping legacy APIs,@unchecked Sendable.references/interop.md- Migrating from GCD,Mutex/locks, completion handlers, delegates, and Combine.references/bug-patterns.md- Common concurrency failure modes and their fixes.references/diagnostics.md- Strict-concurrency compiler errors, protocol conformance fixes, and likely remedies.references/testing.md- Async test strategy with Swift Testing, race detection, avoiding timing-based tests.
Other versions10 projects use a version of this.
Word for word · 6
- twostraws/Swift-Concurrency-Agent-Skill★ 521100% same
- 199-biotechnologies/swiftui-claude-skills★ 7100% same
- kelvinkosbab/KozBon★ 5100% same
- molayab/swift-cli-manager★ 3100% same
- ghostineyt/Swift-Concurrency-Agent-Skill★ 1100% same
- Nelwhix/bloom★ 0100% same
Edited · 3
- element-hq/element-x-ios★ 96495% same
- VelimirMueller/ai-development-skills★ 798% same
- VelimirMueller/claude-skills★ 798% same
Wrote their own version · 1
- spatie/bloom★ 34same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use swiftdata-pro and swift-api-design-guidelines-skill.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
twostrawsSkillswiftdata-pro
Writes, reviews, and improves SwiftData code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use SwiftData.
Also in 4 projects that use this
Erikote04Skillswift-api-design-guidelines-skill
Write, review, or improve Swift APIs using Swift API Design Guidelines for naming, argument labels, documentation comments, terminology, and general conventions. Use when designing new APIs, refactoring existing interfaces, or reviewing API clarity and fluency.
Also in 3 projects that use this
In this repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- add-providerSkill
- add-toolSkill
- commitSkill
- lintSkill
- pr-comment-fixerSkill
- swift-architecture-skillSkill
- swift-testing-proSkill
- swiftui-proSkill
- testSkill
- update-bannerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

