Swift Concurrency Pro is an agent skill aimed at the mistakes models make

What the skill actually contains

The project is an agent skill, and the README says what that means in one sentence: it helps AI coding assistants like Claude Code, Codex, Cursor, and Gemini write better Swift concurrency code.

The coverage list is specific. It covers async and await, actors, Sendable, task groups, @concurrent and structured concurrency, and the README says it targets the mistakes LLMs actually make.

That last clause is the design principle, and the section titled Why Use an Agent Skill for Swift Concurrency explains it at length. The author wrote a book on Swift concurrency and updates it as new features land, and wrote a series of articles on what is new in Swift 6, 6.1 and 6.2, and says he has made it his business to understand the ins and outs of Swift concurrency. The skill is the result of that work, and the rules in it directly target common Swift concurrency mistakes made by LLMs.

The README is careful about the scope, and the paragraph on what this is not is worth reading closely. Agents already have a solid grounding of the fundamentals of async and await, actors and structured concurrency, so skills that try to reteach them what they already know are just burning tokens. The skill focuses on what actually has an impact.

That is a defensible argument and also a limitation. A skill is a payload the assistant reads into context, so its value is bounded by what the assistant already knows and by what it can be told in a few hundred lines. The category of things it targets is the new, the surprising and the soft-deprecated, not the fundamentals.

The project is MIT licensed, the primary language is recorded as unknown since the payload is Markdown rather than source code, and the last push was on 2026-05-17.

Installing it through the marketplace or npx

There are two install routes, one for Claude Code and one for everything else.

In Claude Code you add the marketplace and then install the plugin:

/plugin marketplace add twostraws/Swift-Concurrency-Agent-Skill
/plugin install swift-concurrency-pro@swift-concurrency-agent-skill

For Codex, Gemini, Cursor and other tools, the route is npx:

npx skills add https://github.com/twostraws/swift-concurrency-agent-skill --skill swift-concurrency-pro

The README handles the obvious failure case for that second command, and it is a good sign about the documentation that it does. If you get the error npx: command not found, it means you do not currently have Node installed, and you need to run:

brew install node

And if that fails, the README says it usually means you need to install Homebrew first.

The npx route has two selection controls worth knowing about. When using npx, you can select exactly which agents you want to use during the installation, and you can select whether the skill should be installed just for one project or made available for all your projects. The per-project option is the one to pick if you are evaluating the skill on one codebase rather than committing to it.

There is also a manual route: you can clone the whole repository and install it however you want. The repository root confirms the shape, with a .claude-plugin/ directory for the Claude Code plugin manifest, a swift-concurrency-pro/ directory holding the skill payload, a CODE_OF_CONDUCT.md and a LICENSE file.

For Xcode users there is a video walkthrough linked from the README, How to Install and Use Agent Skills in Xcode, which covers the case the command line instructions do not.

Triggering it, and scoping a review

The skill is named Swift Concurrency Pro and it is triggered in whichever way the host tool supports.

In Claude Code the invocation is a slash command:

/swift-concurrency-pro

In Codex it is prefixed with a dollar sign:

$swift-concurrency-pro

And in either case you can append a specific instruction to narrow the job rather than ask for everything. The README's example on Claude is to ask it to make sure the project takes full advantage of Swift concurrency, and on Codex to ask for help migrating the project to task groups. That distinction matters in practice: a scoped request turns the skill into a targeted review of one concern, where an unscoped one asks for a general concurrency pass over the codebase.

Natural language also works, and the README gives the form:

Use the Swift Concurrency Pro skill to look for potential concurrency problems in this project.

So the skill is invocable three ways, by slash command, by dollar-prefixed command, and by describing what you want in a sentence. That last route is the one that will matter most once you have several skills installed, since the assistant can pick the right one from the request.

The naming convention across the author's projects is worth noticing, because it explains why the skill is called Pro rather than just Swift Concurrency. The README lists sibling skills for SwiftUI, SwiftData and Swift Testing, and points to a Swift Agent Skills repository for more. The Pro suffix appears to be the series name, so the naming tells you which family a skill belongs to when several are installed at once.

Why the author thinks a skill beats a reference guide

The strongest argument in the README is an economic one, and it comes from the contributing guidelines as much as from the pitch.

Keep your Markdown concise. There is a token cost to using skills, particularly with SKILL.md, so please respect the token budgets of users. Do not repeat things that LLMs already know, because it burns tokens for no benefit. Focus on edge cases, surprises, soft deprecations, and similar.

That third guideline is the interesting one, because it names the actual categories of value. Edge cases are where a model's confident default answer is wrong. Surprises are where the language behaves differently from what a reader expects. Soft deprecations are where an API still compiles but is on its way out, and a model trained earlier will still recommend it.

Against a reference guide, the difference is that the skill is not read by you at all. It is read by the assistant, in the context of the task, so every line competes with the code in your repository for the same attention. A documentation page that a developer skims once has no such competition, and that is precisely the argument for keeping the skill narrow: a broader document is a better reference and a worse skill.

The alternative the author rules out is a general Swift concurrency curriculum, and the reason given is that agents already have a solid grounding of the fundamentals. Whether that holds for a given model and a given codebase is the empirical question, and the README does not claim to have measured it. There are no accuracy figures, no benchmark of defects found before and after, and no comparison against running the review without the skill.

So the value proposition rests on an argument about relevance rather than on evidence about outcomes, which is a reasonable thing for a documentation project but worth holding loosely.

Scope: Swift 6.2, iOS 26, and the version boundary

The badges at the top of the README state the target plainly: designed for iOS 26 and later, and designed for Swift 6.2 and later.

That boundary is the whole reason this skill can exist in a useful form. A model trained earlier will happily write code against a Swift concurrency API that has since been superseded, and it will do so fluently, because the older API was correct when it was written. The version-specific features named in the coverage list are where that risk concentrates, and @concurrent is the clearest example, since it is a Swift 6.2 feature tied to the upcoming isolation model.

The README's rule for contributors, focus on new features they are not trained on and older features they frequently make mistakes with, is the same point from the other direction. The skill covers both the new and the old-wrong, which means its value is not tied to a single Swift release cycle and not tied to a single model generation.

The author context supports the claim. The README links articles on what is new in Swift 6, Swift 6.1 and Swift 6.2, and says the book and articles are updated regularly as new features are added, which implies the skill is maintained on a similar rhythm rather than written once. The version history here shows a single release, 1.0.0 from 2026-03-11, with the last push on 2026-05-17, so the payload has been edited since the tagged release without a new tag.

The practical consequence for an adopter is that you should expect to install from the repository rather than pin a version, since a single 1.0.0 tag says nothing about whether the content matches the Swift release you are on, and there is no changelog in the repository to tell you what changed since.

Where Swift Concurrency Pro fits, and where it stops

The comparison worth making is with the alternatives you already have for getting a model to write correct concurrent Swift.

Against asking the model directly with no skill, the difference is that the skill adds a curated set of rules the model does not have from training, and gives it a specific vocabulary and specific failure modes to check. The author is explicit that the rules target common Swift concurrency mistakes made by LLMs, which is a claim about the gap between what a model knows and what it needs to be told.

Against a reference guide or a book, the difference is where the attention goes. A book is written for a human who reads it once and remembers it. A skill is written for a model that reads it every time, in a context window that also holds your code, and it competes there. The book's value is depth and continuity; the skill's value is that it arrives at the moment of the review.

The limits are the same ones the README states about itself, and they are real. It is not a general Swift concurrency course, and by design it will not teach the fundamentals, so a developer who does not already understand actors will get less out of the output than the skill's structure implies. It carries no measurement of its own effectiveness. It targets one ecosystem and one language, and it targets specific tool hosts, so an assistant outside the listed set may not be able to load a skill at all.

And there is a dependency worth naming plainly. The whole approach depends on the host tool's skill mechanism being mature and on the model actually following the rules it is given. A rule in a Markdown file is advice, not enforcement, and the README does not claim otherwise.

For a team already using Claude Code, Codex or Cursor on Swift and hitting concurrency mistakes in generated code, this is a cheap and specific remedy with a clear rationale behind its rules. For a team that has already solved that with prompt engineering of its own, it is a well-curated version of the same idea.

The licence is MIT, which the README says permits commercial use, modification, distribution and private use, and the project asks for contributions under the same terms so it can benefit the most people. The author is Paul Hudson, who writes free Swift tutorials on Hacking with Swift, and the skill is one of a family of them.

Editorial conclusion

Swift Concurrency Pro suits a team using an AI coding assistant on Swift code where concurrency correctness matters, since the skill concentrates on the specific mistakes models make rather than on a general Swift curriculum, and it can be run as a targeted review of one project or one migration. It is the wrong tool if you want a reference document, because a skill is a prompt payload the assistant reads rather than documentation you read yourself, and it is the wrong tool if your project is below Swift 6.2 or iOS 26, since the badges state that those are the versions it was designed for. Before installing, add the marketplace with /plugin marketplace add twostraws/Swift-Concurrency-Agent-Skill and then install the plugin, and read the contributing guidance about token budgets if you plan to add checks of your own.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. twostraws/Swift-Concurrency-Agent-Skill on GitHub