SwiftUI Pro: an agent skill that treats token cost as a design constraint

A skill that ships rules rather than code

SwiftUI Pro is an agent skill, not a library. Nothing here compiles, and there is no package to add to a project. It is a set of instructions that an AI coding assistant loads and then applies while writing or reviewing SwiftUI code. The repository description says it plainly: an agent skill that helps AI coding assistants write smarter, simpler, and more modern SwiftUI.

The stated coverage is broad and worth reading as a syllabus: navigation, layout, animations, state management, VoiceOver, and deprecated API, with the framing that these target the mistakes LLMs actually make. That last clause is the design thesis. Rather than trying to teach SwiftUI from the beginning, the skill is aimed at the specific failure modes of a model that already knows a great deal but reaches for a deprecated pattern or a layout that quietly costs performance.

Three sibling skills from the same author cover adjacent ground: SwiftData Pro, Swift Concurrency Pro, and Swift Testing Pro. The author also points to a Swift Agent Skills repository as the place to find more, which suggests this is one entry in a growing personal catalogue rather than a one-off experiment.

The repository itself is thin in a way that is easy to misread. GitHub reports no primary language for it, which is accurate: the tree is Markdown, an `assets/` directory, a `.claude-plugin/` directory, a LICENSE, a Code of Conduct, and the `swiftui-pro/` directory that holds the skill itself. It was last pushed on 2026-04-20, with 4806 stars and only 11 open issues, and it is MIT licensed.

Installing through npx, or through the Claude Code plugin marketplace

The primary install path is a single npx command, which is what makes the skill reachable from Claude Code, Codex, Gemini and Cursor at once. The tool asks you which agents to target and whether the skill should apply to one project or to all of them:

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

The README is unusually thorough about failure here. If npx is not found, the message is that Node is missing, and the fix is Homebrew:

brew install node

If that fails, Homebrew itself is not installed, so the README links to the Homebrew site rather than leaving the reader guessing. That is a small detail, but it is the difference between an install section that works on a clean machine and one that assumes a configured environment.

Claude Code users have a second route, added in the 1.1.0 release, which registers the repository as a marketplace and then installs the plugin:

/plugin marketplace add twostraws/SwiftUI-Agent-Skill
/plugin install swiftui-pro@swiftui-agent-skill

Those two lines are plugin slash commands rather than shell commands, so they belong in the assistant rather than in a terminal. Running them the other way round does nothing useful. Xcode users are pointed to a video walkthrough instead, which is an honest admission that Xcode's support is instructional rather than automated.

There is also a plain option: clone the repository and install it however you want. For anyone who needs the skill vendored into a repository so every contributor gets identical guidance, that path matters more than the convenience of npx.

Triggering the skill, narrowly or in plain language

Once installed the skill is invoked by name, and the naming differs by tool because the syntax differs. In Claude Code it is a slash command, and in Codex it is a dollar-prefixed invocation:

/swiftui-pro

The equivalent in Codex is `$swiftui-pro`. Both accept extra instructions to narrow the scope, and the README gives two examples that are more useful than the bare invocation: checking only for deprecated API on Claude, and focusing only on accessibility in Codex. Scoped invocation is the mode most people should default to, because a full rules pass over a large file produces a lot of output that you then have to triage.

The skill also triggers from ordinary language, so a request like asking the assistant to use the skill to look for performance problems in the project works without any command syntax. That path depends on the assistant noticing the skill exists, which is exactly what installation is for.

Three numbered takeaways emerge from the invocation model. First, the skill does not run continuously in the background; you ask for it, so it fits a review workflow rather than a guardrail workflow. Second, the same rules can be applied at different scopes, which makes it usable both as a pre-commit check on one file and as a broad audit across a project. Third, the name is consistent across tools even though the invocation prefix is not, so muscle memory transfers between assistants even when the syntax does not.

The contribution guide is the most interesting file here

Most skill repositories document how to add checks. This one spends its contribution section on why you should not. Three rules, and they are worth quoting rather than paraphrasing. Keep the Markdown concise, because there is a token cost to using skills, particularly with SKILL.md, and readers have token budgets too. Do not repeat things that LLMs already know, because that burns tokens for no benefit; focus instead on edge cases, surprises, soft deprecations, and similar. And all work must be MIT licensed so that as many people as possible benefit.

That is a real editorial position, and it has an interesting implication. The value of a skill is not its coverage but its residue: a model already knows that a button is a button. A rule earns its place only if it encodes something the model reliably gets wrong, such as a button made invisible to VoiceOver or a layout change that quietly costs performance. Under this policy, adding rules is a cost, not a contribution.

The 1.1.0 release shows how the policy is applied. It added Label style and LabeledContent guidance, which is a concrete API addition, but it also adjusted the extract all computed views rule so that user-specified overrides are allowed. Adding a rule and then carving out an exception to it is the maintenance cost of this kind of project, and doing both in one release suggests the author reviews rules with the same scepticism the guide asks contributors to bring.

The initial 1.0.0 release from 2026-03-11 is described in one line as the core rules agents should follow. The whole project therefore fits in two releases over about five weeks, with the 1.1.0 work landing on the same day as the last push to the repository.

Where the documentation stops and the skill begins

The honest boundary here is that this repository's visible content is installation, invocation, licensing and contribution policy. The rules themselves live under the `swiftui-pro/` directory, and the repository listing at this level shows that directory as a single entry rather than exposing its files. So the README tells you what the skill covers and how to invoke it, and it does not let you read the rules without installing.

That is a defensible design for a distribution that targets four different assistants, since the packaging format is the thing that has to be consistent. It is still a difference from the kind of repository you can audit from a browser, and it is worth spending the two minutes to install it somewhere disposable before you let it loose across a codebase.

Provenance is clearer than the packaging. The README states that the skill was originally created by Paul Hudson, who writes the Hacking with Swift tutorials, and that it builds on an earlier AGENTS.md file of his own, meaning that years of accumulated practice were converted into the skill format rather than written for it. The rules are therefore not a synthesis of the wider community's SwiftUI advice; they are one practitioner's habits, with the editorial gate described above applied to them.

There is a supporting article linked from the README that covers the reasoning behind the skill in more depth, and an MIT license that the README spells out as permitting commercial use, modification, distribution and private use. For most teams the practical question is not whether the license allows it but whether the rules match your own house style, and the fastest way to find out is to run a scoped invocation against a file you already know well.

Editorial conclusion

The interesting part of this repository is not the rule list, it is the editorial policy written around the rule list. Asking contributors not to repeat what models already know, and to spend the token budget on soft deprecations and surprises instead, is a sharper statement about agent skills than any feature claim. Two practical notes for anyone adopting it. The install path differs by tool, and the Claude Code plugin route is the one added most recently, so a stale assistant may only offer the npx route. And because the rule content lives in a `swiftui-pro/` subdirectory rather than at the root, you are installing a directory whose internals the repository does not display, which is worth reading once before you trust it across a codebase.

Frequently asked questions

Official sources

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