In part 1 I covered what I have installed globally: the seven skills I use in almost any iOS or macOS session. This last part covers everything else, which are the skills that only make sense when an app does something specific: sells subscriptions, exposes actions to Siri, shows widgets, stores data with Core Data.
I don’t install those globally. I put them inside the project that needs them, so they only cost context while I work in that repo.
If you landed directly on this part and don’t know what a skill is, start with part 0.
How to install a skill in a project
In Claude Code, project skills live in .claude/skills/ inside the repo. The process is the same as in part 1 (clone, scan, copy only the folder, note the commit), with a different destination:
git clone --depth 1 https://github.com/AvdLee/Core-Data-Agent-Skill /tmp/core-data
cd ~/.claude/skills/skill-scanner && uv run scripts/scan_skill.py /tmp/core-data/core-data-expert
mkdir -p ~/path/to/your-app/.claude/skills
cp -R /tmp/core-data/core-data-expert ~/path/to/your-app/.claude/skills/
Then you decide whether .claude/skills/ goes into version control. If you work with other people, committing it makes sense: the whole team uses the same instructions. If it’s a personal project or you’d rather not version third-party content, it goes in .gitignore.
Every community skill I mention below I reviewed and ran through skill-scanner before writing this post. None of them had findings.
If your app sells something: StoreKit 2
There are two families here covering the same ground, and my one-source-per-topic rule applies: pick one, not both.
- rshankras/claude-code-apple-skills:
paywall-generatorbuilds a subscription paywall with StoreKit 2 and SwiftUI, andsubscription-lifecyclecovers what happens after the purchase: grace periods, billing retry, offer codes, win-back offers, plan changes, and subscription status tracking. These are the ones I chose for my apps with subscriptions. storekitfrom dpearson2699/swift-ios-skills: a single skill that implements and reviews purchases and subscriptions, includingSubscriptionStoreView, entitlement verification, and the different purchase types. It’s the better option if you already have purchases working and want to review them.
About that second repository: its license is PolyForm Perimeter 1.0.0. It allows using the skills in commercial work, even in closed-source projects. What it doesn’t allow is using them to offer a product that competes with them, like another skill pack. The repository has dozens of skills; copy only the ones you’ll use.
If your app talks to Siri, Shortcuts, or Spotlight: App Intents
The best ones here are Apple’s, and they come as a pair:
app-intents-specialist: best practices that don’t change from release to release. It catches mistakes that aren’t obvious:perform()isSendable, not@MainActor; the system can retry it, so irreversible work goes last; anAppEntity’sidmust be stable across launches and devices;AppEnumraw values are persisted as strings, so you never renumber them.app-intents-whats-new-27: what’s new in iOS 26 and iOS 27, likesupportedModesinstead of the deprecatedopenAppWhenRun, undoable intents,requestChoice, interactive snippets, Visual Intelligence, and migrating from@AssistantIntentto@AppIntent(schema:).
The two split the work explicitly: each one tells the agent when to use the other. You install them from the Xcode 27 export, same as in part 1.
If your app has widgets
widget-generator (rshankras) generates WidgetKit widgets for the Home Screen and Lock Screen, with their timeline provider, interactive elements, and App Intents configuration.
The alternative is widgetkit from dpearson2699. Again, just one.
If your widget is configurable, pair it with the App Intents skills from the previous section: a widget’s configuration is an intent.
If your app uses Core Data
Antoine van der Lee’s core-data-expert covers the full stack: setup, fetch requests and NSFetchedResultsController, saving and merge conflicts, threading and Swift Concurrency, batch operations, persistent history, migrations, performance, and CloudKit sync.
Core Data isn’t dead. If your app has been on the App Store for years, it probably uses it, and migrating to SwiftData isn’t always worth it. For when it is worth it, there’s migration-patterns (rshankras), which covers that migration and others: UIKit to SwiftUI, ObservableObject to @Observable, Objective-C to Swift, and StoreKit 1 to StoreKit 2.
If your app uses Apple Intelligence
foundation-models (rshankras) covers the on-device model framework: text generation, structured output, and tool calling.
It’s one of the most valuable skills, because it’s a recent API with little presence in the models’ training data.
If your app plays music
musickit from dpearson2699 covers Apple Music integration: catalog search, subscription flows, playback queue, remote controls, and Now Playing info.
If your app is in more than one language
ios-localization from dpearson2699 covers String Catalogs (.xcstrings), stable key naming, LocalizedStringKey and LocalizedStringResource, plurals, number and date formatting, right-to-left layout, and Dynamic Type.
For writing and protecting tests
In part 1 I installed modernize-tests globally to migrate old tests. For writing new tests I use another one:
swift-testing-expertby Antoine van der Lee: test structure,#expectand#require, traits and tags, parameterized tests, parallel execution, patterns for waiting on async code, and how to fix flaky tests. There’s another Swift Testing skill by Paul Hudson; I picked this one to avoid having two sources.
Before a big refactor, especially one I’m going to hand to an agent, I use two from rshankras:
characterization-test-generator: writes tests that capture what the code does today, even if it isn’t ideal. That way, if the refactor changes something by accident, a test fails.flow-walkthrough: walks through complete flows in the simulator with XCUITest, takes a screenshot per step, and checks the navigation graph for dead-end screens. It catches mistakes a code review won’t.
Both create and run files, so they ask for permission to run commands and write. That’s expected; just keep it in mind.
For understanding SwiftUI more deeply
Two skills I don’t install globally, but that I bring into a project when the problem is SwiftUI itself:
swiftui-specialist(Apple): the official best-practices skill. As I said in part 1, I’m comparing it againstswiftui-expert-skillon real projects before deciding which one stays global.data-flow(rshankras): SwiftUI’s mental model, meaning view identity, lifetime, and dependencies, who owns each piece of state, and how Observation tracks changes property by property. It’s the one you need when state resets for no apparent reason or a view recomputes too often.
If your app uses Firebase
From firebase/agent-skills, Firebase’s official repository:
firebase-crashlytics: setting up and using Crashlytics.xcode-project-setup: safely modifies the Xcode project file (.pbxproj) to add Swift Packages and link files. It’s more useful than it sounds, because hand-editing the.pbxprojis one of the things an agent breaks most easily.
If your builds are slow
Antoine van der Lee’s Xcode Build Optimization is six skills that work together: they benchmark your builds, find which files take longest to compile, review project and Swift Package Manager settings, and propose fixes.
They ship Python scripts that run xcodebuild on your machine, including clean builds for measuring. I read them: they only work locally and don’t connect to the internet. Still, expect a full analysis to take as long as several builds of your project.
Before submitting for review
Three things I run before shipping:
audit-xcode-security-settings(Apple): audits the project’s security settings and gradually enables Enhanced Security, compiler warnings, and static analyzer checks. I run it once per app and repeat it when I change something big in the configuration.privacy-manifests(rshankras): thePrivacyInfo.xcprivacy, required-reason APIs, tracking domains, third-party SDK declarations, and App Tracking Transparency.rejection-handler(rshankras): checks the app against the most common rejection reasons before you submit and, if you get rejected, helps you respond in the Resolution Center or appeal.
As an alternative to those last two there’s app-store-review from dpearson2699, which does a similar audit in a single skill. One or the other.
What I’ve reviewed but don’t use in depth yet
There are two collections that passed the scanner and that I have on my radar, but that I don’t have enough experience with yet to recommend without caveats:
- app-store-connect-cli-skills: they automate TestFlight, metadata, submissions, and signing through
asc, a community command-line tool for App Store Connect. They need an App Store Connect API key. If you try them, create a key with the minimum role you need, never an admin one. - aso-skills: App Store listing optimization. The ones I’m interested in are
aso-audit,keyword-research, andmetadata-optimization. They work without an account; if you connect Appeeky’s service (through its API or MCP server), they work with real search data.
The Xcode MCP server
A skill gives the agent knowledge. An MCP server gives it tools: in Xcode’s case, things like building, running tests, or searching Apple’s documentation.
Xcode 27 includes mcpbridge, a bridge that connects an external agent to Xcode’s MCP tools. It’s what device-interaction, the skill from part 1, needs to work outside Xcode’s own assistant.
To connect it to Claude Code:
- In Xcode 27’s settings, in the Intelligence section, allow external agents to use Xcode’s tools.
- Register the server:
claude mcp add --scope user --transport stdio xcode -- xcrun mcpbridge
mcpbridge connects to the Xcode selected with xcode-select, so Xcode needs to be open while you use it.
If you need more control over the simulator than Xcode offers, there’s Sentry’s MobileBuildMCP, formerly XcodeBuildMCP. Keep two things in mind: it sends telemetry to Sentry (you can turn it off) and it leaves a process running in the background.
Summary by app type
| If your app… | Install in the project |
|---|---|
| Sells subscriptions or purchases | paywall-generator + subscription-lifecycle, or storekit |
| Integrates with Siri, Shortcuts, or Spotlight | app-intents-specialist + app-intents-whats-new-27 |
| Has widgets | widget-generator or widgetkit |
| Uses Core Data | core-data-expert (+ migration-patterns if migrating) |
| Uses Apple Intelligence | foundation-models |
| Plays music | musickit |
| Is in several languages | ios-localization |
| Needs new tests or is heading into a big refactor | swift-testing-expert, characterization-test-generator, flow-walkthrough |
| Uses Firebase | firebase-crashlytics, xcode-project-setup |
| Builds slowly | Xcode Build Optimization |
| Is about to ship | audit-xcode-security-settings, privacy-manifests, rejection-handler |
Wrapping up the series
If I had to keep one idea from all this, it’s that less is more. A well-chosen skill saves the agent hours of guessing; ten skills covering the same thing confuse it. The value isn’t in having many, but in having the right ones for what you’re building today.
To recap:
- Part 0: what a skill is and why it matters that Apple publishes its own.
- Part 1: the seven global ones and how to decide what goes global.
- Part 2 (this one): what gets installed per project, depending on what each app does.
And three habits that apply to any skill you find after reading this: review it before installing it, install only the folder you need, and review it again when a new version comes out.