In part 0 I explained what an agent skill is and how an agent loads it. Today is the practical part: what I have installed globally, why these and not others, how to install them, and how I use them day to day.
Everything that follows is written from my workflow, which is Claude Code. If you use Codex or Cursor, the skills’ content is the same; only the folder where they live changes, and I point that out in the installation section.
How I decide what goes global
A global skill is available in all my sessions, in any project. That’s convenient, but it has a cost: its description enters the context of every session, whether I use it or not. So I apply four criteria before installing anything globally:
- I use it in almost any iOS or macOS session, regardless of the project. Concurrency, SwiftUI, tests, SDK changes: those show up in all my apps. If a skill depends on a technology only some apps use (StoreKit, App Intents, Core Data), it gets installed inside that project. I cover those in part 2.
- One source per topic. If two skills cover the same thing, they compete to activate and sometimes contradict each other. I pick one.
- Nothing goes in without review. I read the
SKILL.mdand any scripts, run it through a scanner, copy only the skill’s folder, and note the commit I reviewed. - Each one has to earn its place. A description costs between 40 and 230 tokens per session. Not much per skill, but it adds up.
The set
Of the nine global skills I mentioned in part 0, six are for Apple development. The other three are for Android, because several of my apps exist there too, and they’re out of scope for this series. To those six I add swiftui-expert-skill, which I installed before doing this review and which passed the filter without trouble.
| Skill | Author | What I use it for |
|---|---|---|
swiftui-whats-new-27 | Apple | SwiftUI changes in the iOS 27 SDK |
modernize-tests | Apple | Migrating from XCTest to Swift Testing |
device-interaction | Apple | Verifying in the simulator that a UI change works |
swiftui-expert-skill | Antoine van der Lee | Day-to-day SwiftUI, performance, and Liquid Glass |
swift-concurrency | Antoine van der Lee | Data races, Sendable, actors, and the Swift 6 migration |
swiftdata-pro | Paul Hudson | Models, predicates, and CloudKit in SwiftData |
skill-scanner | Sentry | Auditing any skill before installing it |
The three from Apple
swiftui-whats-new-27
Covers what changed in SwiftUI with iOS 27 and the releases that shipped alongside it: @State is now a macro, reorderable containers, swipe actions outside List, caching in AsyncImage, toolbar changes, and presenting alerts from an optional binding.
Why it’s global: all my apps compile against the iOS 27 SDK, so these changes show up in any project. It’s also exactly the kind of knowledge a model can’t have because of its training cutoff.
When it activates: when errors that didn’t exist before show up after updating the SDK. The most common case is @State: errors like “used before being initialized” or “invalid redeclaration of synthesized property” in code that compiled perfectly with iOS 26.
modernize-tests
It does two things: migrates tests from XCTest to Swift Testing, and updates existing Swift Testing tests to use the recommended patterns.
Why it’s global: I follow the rule of migrating the tests I touch, one file at a time. That happens in any project.
Worth knowing: not everything can be migrated, and the skill respects that. UI tests (the ones using XCUIAutomation) and tests that measure performance with measure { ... } stay in XCTest. If a file mixes both, it migrates the tests it can and leaves the rest.
device-interaction
It’s a subagent skill: the main agent hands verification off to another agent, which launches the app in the simulator, takes screenshots, inspects the UI hierarchy, taps buttons, and reports what it found. It’s meant to be used after a change that affects the interface.
Why it’s global: the most expensive mistake I know is calling a UI change done without ever seeing it work. This skill closes that gap.
What it needs: it uses Xcode 27’s device tools. Inside Xcode’s coding assistant it already has them. Other agents need the Xcode MCP server connected; I explain that in part 2, along with everything else that gets installed per project.
The four from the community
swiftui-expert-skill
Antoine van der Lee’s (SwiftLee) SwiftUI skill is broad: state management, view composition, performance, lists and scrolling, animation, accessibility, charts, macOS-specific APIs, and Liquid Glass adoption on iOS 26 and later. It ships one reference per topic, and the agent only reads the one it needs.
It can also analyze Instruments traces: hand it a .trace file or ask it to record one, and it helps find hangs, animation hitches, and views that recompute too often. That part includes scripts that run on your machine, so I read them before installing it.
Why it’s global: almost everything I do on iOS and macOS is SwiftUI.
swift-concurrency
Also by Antoine van der Lee. It diagnoses concurrency problems, converts callback-based code to async/await, and guides the Swift 6 migration: tasks, actors, @MainActor, Sendable, and related compiler warnings.
Why it’s global: concurrency errors show up in any Swift 6 project, and it’s an area where the model gets things wrong easily without good instructions. A bad fix (a @MainActor where it doesn’t belong, or a nonisolated(unsafe) to quiet the compiler) compiles, but hides the problem.
swiftdata-pro
By Paul Hudson (Hacking with Swift). It writes, reviews, and improves SwiftData code using modern APIs. Its references cover the core rules for models, predicates, indexing, class inheritance, and CloudKit sync.
Why it’s global: technically it breaks my first criterion, since SwiftData is a technology not all my apps use. But several of my active projects use it, so I’d rather pay for its description in every session than remember to install it in each repo.
skill-scanner
By Sentry. It reviews a skill before you install it, looking for prompt injection, malicious scripts, excessive permissions, exposed secrets, and dependency risks.
Why it’s global: it’s the one that reviews all the others, so it’s the first one I install. One detail: the scanner flags itself as suspicious, because it contains attack examples so it can detect them. That’s an expected false positive.
What I left out of the global set
This part matters as much as the previous one, because it explains the decisions.
swiftui-specialist (Apple). It’s the official SwiftUI best-practices skill, and the source couldn’t be better. But it covers the same topic as swiftui-expert-skill, and my second criterion says one source per topic. Right now I’m trying it per project to compare them on real code. Apple’s is more precise on its topics (invalidation with @Observable, identity in ForEach, Environment, localization, soft-deprecated APIs); the community one covers more ground. When I decide, I’ll update this post.
app-intents-specialist, app-intents-whats-new-27, and audit-xcode-security-settings (Apple). All three are very good, but they depend on the project or the moment: the App Intents ones only help if the app exposes intents, and the security audit runs once per app before shipping. They’re in part 2.
uikit-app-modernization, adopt-c-bounds-safety, and building-document-based-swiftui-applications (Apple). I don’t use them because they don’t fit what I build: my apps are 100% SwiftUI, I have no C code, and none of them are document-based. If your app is UIKit, integrates C libraries, or is a document editor, they’re probably among the first you should install.
How to install them
For Claude Code, global skills live in ~/.claude/skills/. If you use Codex or Cursor, swap that path for ~/.agents/skills/ in every command.
Step 1: skill-scanner, first
mkdir -p ~/.claude/skills
git clone --depth 1 https://github.com/getsentry/skills /tmp/sentry-skills
cp -R /tmp/sentry-skills/skills/skill-scanner ~/.claude/skills/The scanner uses uv to manage its Python dependencies. With uv installed, this is how you check a skill:
cd ~/.claude/skills/skill-scanner
uv run scripts/scan_skill.py /path/to/the/skillStep 2: Apple’s
Export them from Xcode 27 to a temporary folder and copy only the ones you’ll use:
xcrun agent skills export /tmp/apple-skills
cp -R /tmp/apple-skills/swiftui-whats-new-27 ~/.claude/skills/
cp -R /tmp/apple-skills/modernize-tests ~/.claude/skills/
cp -R /tmp/apple-skills/device-interaction ~/.claude/skills/Apple’s skills come inside Xcode, so I don’t run them through the scanner, but I do read them.
Step 3: the community ones
For each one: clone, scan, copy only the skill’s folder, and note the commit.
# swift-concurrency
git clone --depth 1 https://github.com/AvdLee/Swift-Concurrency-Agent-Skill /tmp/swift-concurrency
cd ~/.claude/skills/skill-scanner && uv run scripts/scan_skill.py /tmp/swift-concurrency/skills/swift-concurrency
cp -R /tmp/swift-concurrency/skills/swift-concurrency ~/.claude/skills/
# swiftui-expert-skill
git clone --depth 1 https://github.com/AvdLee/SwiftUI-Agent-Skill /tmp/swiftui-expert
cd ~/.claude/skills/skill-scanner && uv run scripts/scan_skill.py /tmp/swiftui-expert/swiftui-expert-skill
cp -R /tmp/swiftui-expert/swiftui-expert-skill ~/.claude/skills/
# swiftdata-pro
git clone --depth 1 https://github.com/twostraws/SwiftData-Agent-Skill /tmp/swiftdata
cd ~/.claude/skills/skill-scanner && uv run scripts/scan_skill.py /tmp/swiftdata/swiftdata-pro
cp -R /tmp/swiftdata/swiftdata-pro ~/.claude/skills/To note the commit you reviewed:
git -C /tmp/swift-concurrency log -1 --format='%h %cs'Several of these repositories can also be installed as Claude Code plugins. Copying just the folder lets you pin the version you reviewed, and avoids pulling in things you didn’t ask for.
Step 4: check
Skills load when a session starts, so open a new one. To confirm a skill is active, ask the agent for something in its area: when it uses the skill, you’ll see it invoke it by name.
Quick usage guide
Skills activate on their own when your request matches their description. You don’t need to name them. Still, you can ask for one explicitly (“use the swift-concurrency skill to…”) when you want to make sure the agent loads it.
| Situation | What I ask the agent | Skill that activates |
|---|---|---|
I updated to the iOS 27 SDK and @State throws errors | ”This file stopped compiling with the iOS 27 SDK; fix the @State errors.” | swiftui-whats-new-27 |
| I touched an old test file | ”Migrate this file from XCTest to Swift Testing.” | modernize-tests |
| I finished a change on a screen | ”Verify in the simulator that the sign-up flow works.” | device-interaction |
| A list feels slow | ”Check why this list recomputes so much while scrolling.” | swiftui-expert-skill |
| The compiler flags a data race | ”Fix this Sendable warning without silencing it.” | swift-concurrency |
A @Query doesn’t update | ”Review this SwiftData model and query.” | swiftdata-pro |
| I found a new skill | ”Scan this skill before I install it.” | skill-scanner |
If a skill activates when it shouldn’t, or never activates, the problem is almost always its description. It’s the only thing the agent reads to decide.
Maintenance
- Apple’s skills change with each Xcode release. After updating, I export them again to a temporary folder, compare with what I have installed, and replace whatever changed.
- The community ones are pinned to the commit I reviewed. Every quarter I check what changed in the original repository and, if an update is worth it, I repeat the process: clone, scan, copy. I never update without reviewing.
In part 2, tomorrow, it’s time for what gets installed per project: StoreKit, App Intents, Core Data, widgets, testing, App Store prep, and the Xcode MCP server.