Fetches axiom-swift-concurrency from charleswiltgen/axiom and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/axiom-swift-concurrency
Restart Cursor to activate axiom-swift-concurrency. Access via /axiom-swift-concurrency in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Purpose: Progressive journey from single-threaded to concurrent Swift code
Swift Version: Swift 6.3 (strict concurrency by default). @concurrent requires Swift 6.2+.
iOS Version: iOS 17+ (iOS 26+ for @concurrent)
Xcode: Xcode 16+ (Xcode 26+ for @concurrent)
When to Use This Skill
✅ Use this skill when:
Starting a new project and deciding concurrency strategy
Debugging Swift 6 concurrency errors (actor isolation, data races, Sendable warnings)
Deciding when to introduce async/await vs concurrency
Implementing @MainActor classes or async functions
Converting delegate callbacks to async-safe patterns
Deciding between @MainActor, nonisolated, @concurrent, or actor isolation
Resolving "Sending 'self' risks causing data races" errors
Making types conform to Sendable
Offloading CPU-intensive work to background threads
UI feels unresponsive and profiling shows main thread bottleneck
❌ Do NOT use this skill for:
General Swift syntax (use Swift documentation)
SwiftUI-specific patterns (use axiom-swiftui-debugging or axiom-swiftui-performance)
API-specific patterns (use API documentation)
Core Philosophy: Think in Isolation Domains, Not Threads
"Your apps should start by running all of their code on the main thread, and you can get really far with single-threaded code." — Apple
Stop asking: "What thread should this run on?"
Start asking: "What isolation domain should own this work?"
@MainActor → UI state ownership
Custom actor → shared mutable state ownership
nonisolated → no ownership, caller decides
@concurrent → force background execution
Async does not mean background. An async function suspends without blocking, but resumes on the same actor it was called from. A @MainActor async function runs entirely on the main actor — await just yields control, it does not switch threads. Use @concurrent (Swift 6.2+) when you need to force work off the calling actor.
Prefer structured concurrency. Use async let and TaskGroup for parallel work — they propagate cancellation and errors automatically through the task tree. Unstructured Task {} is for bridging sync→async boundaries (event handlers, SwiftUI .task). Task.detached is a last resort.
GCD is a bridge pattern, not a default. In new code, do not use DispatchQueue, DispatchGroup, DispatchSemaphore, or completion handlers as primary architecture. Use them only to bridge legacy APIs that don't have async alternatives yet. Isolate bridge code and keep the rest of the codebase idiomatic Swift 6.
The Progressive Journey
Single-Threaded → Asynchronous → Concurrent → Actors
↓ ↓ ↓ ↓
Start here Hide latency Background Move data
(network) CPU work off main
When to advance:
Stay single-threaded if UI is responsive and operations are fast
Add async/await when high-latency operations (network, file I/O) block UI
Add concurrency when CPU-intensive work (image processing, parsing) freezes UI
Add actors when too much main actor code causes contention
Key insight: Concurrent code is more complex. Only introduce concurrency when profiling shows it's needed.
Step 1: Single-Threaded Code (Start Here)
With Main Actor Mode enabled (the default for new projects in Xcode 26+), all code runs on the main thread unless explicitly marked otherwise.
// ✅ Simple, single-threadedclassImageModel{var imageCache:[URL:Image]=[:]funcfetchAndDisplayImage(url:URL)throws{let data =tryData(contentsOf: url)// Reads local filelet image =decodeImage(data) view.displayImage(image)}funcdecodeImage(_ data:Data)->Image{// Decode image datareturnImage()}}
Main Actor Mode (Xcode 26+)
Enabled by default for new projects
All code protected by @MainActor unless explicitly marked otherwise
Access shared state safely without worrying about concurrent access
Build Setting (Xcode 26+)
Build Settings → Swift Compiler — Language
→ "Default Actor Isolation" = Main Actor
Build Settings → Swift Compiler — Upcoming Features
→ "Approachable Concurrency" = Yes
When this is enough: If all operations are fast (<16ms for 60fps), stay single-threaded!
Step 2: Asynchronous Tasks (Hide Latency)
Add async/await when waiting on data (network, file I/O) would freeze UI.
Problem: Network Access Blocks UI
// ❌ Blocks main thread until network completesfuncfetchAndDisplayImage(url:URL)throws{let data =tryData(contentsOf: url)// ❌ Synchronous network fetch, freezes UI!let image =decodeImage(data) view.displayImage(image)}
Solution: Async/Await
// ✅ Suspends without blocking main threadfuncfetchAndDisplayImage(url:URL)asyncthrows{let(data,_)=tryawaitURLSession.shared.data(from: url)// ✅ Suspends herelet image =decodeImage(data)// ✅ Resumes here when data arrives view.displayImage(image)}
What happens:
Function starts on main thread
await suspends function without blocking main thread
URLSession fetches data on background thread (library handles this)
Function resumes on main thread when data arrives
UI stays responsive the entire time
Task Creation
Create tasks in response to user events:
classImageModel{var url:URL=URL(string:"https://swift.org")!funconTapEvent(){Task{// ✅ Create task for user actiondo{tryawaitfetchAndDisplayImage(url: url)}catch{displayError(error)}}}}
Task Interleaving (Important Concept)
Multiple async tasks can run on the same thread by taking turns:
Critical: Both tasks above run on the main actor. The await keyword suspends the task and frees the thread, but when the task resumes, it returns to the same isolation domain (main actor). No background thread is involved unless the awaited API (like URLSession) handles that internally.
When to use tasks:
High-latency operations (network, file I/O)
Library APIs handle background work for you (URLSession, FileManager)
Your own code stays on main thread
Step 3: Concurrent Code (Background Threads)
Add concurrency when CPU-intensive work blocks UI.
funcfetchAndDisplayImage(url:URL)asyncthrows{let(data,_)=tryawaitURLSession.shared.data(from: url)let image =decodeImage(data)// ❌ 200ms on main thread! view.displayImage(image)}
Solution 1: @concurrent Attribute (Swift 6.2+)
Forces function to always run on background thread:
funcfetchAndDisplayImage(url:URL)asyncthrows{let(data,_)=tryawaitURLSession.shared.data(from: url)let image =awaitdecodeImage(data)// ✅ Runs on background thread view.displayImage(image)}@concurrentfuncdecodeImage(_ data:Data)async->Image{// ✅ Always runs on background thread pool// Good for: image processing, file I/O, parsingreturnImage()}
What @concurrent does:
Function always switches to background thread pool
Compiler highlights main actor data access (shows what you need to fix)
Cannot access @MainActor properties without await
Requirements: Swift 6.2+, Xcode 26+, iOS 26+
Solution 2: nonisolated (Library APIs)
If providing a general-purpose API, use nonisolated instead:
// ✅ Stays on caller's actornonisolatedfuncdecodeImage(_ data:Data)->Image{// Runs on whatever actor called it// Main actor → stays on main actor// Background → stays on backgroundreturnImage()}
When to use nonisolated:
Library APIs where caller decides where work happens
Small operations that might be OK on main thread
General-purpose code used in many contexts
When to use @concurrent:
Operations that should always run on background (image processing, parsing)
Performance-critical work that shouldn't block UI
Breaking Ties to Main Actor
When you mark a function @concurrent, compiler shows main actor access:
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
