AIAgent SkillsXcodeStoreKitProductivity

Agent Skills, part 2: what to install depending on the kind of app

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-generator builds a subscription paywall with StoreKit 2 and SwiftUI, and subscription-lifecycle covers 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.
  • storekit from dpearson2699/swift-ios-skills: a single skill that implements and reviews purchases and subscriptions, including SubscriptionStoreView, 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() is Sendable, not @MainActor; the system can retry it, so irreversible work goes last; an AppEntity’s id must be stable across launches and devices; AppEnum raw values are persisted as strings, so you never renumber them.
  • app-intents-whats-new-27: what’s new in iOS 26 and iOS 27, like supportedModes instead of the deprecated openAppWhenRun, undoable intents, requestChoice, interactive snippets, Visual Intelligence, and migrating from @AssistantIntent to @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-expert by Antoine van der Lee: test structure, #expect and #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 against swiftui-expert-skill on 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 .pbxproj is 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): the PrivacyInfo.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, and metadata-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:

  1. In Xcode 27’s settings, in the Intelligence section, allow external agents to use Xcode’s tools.
  2. 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 purchasespaywall-generator + subscription-lifecycle, or storekit
Integrates with Siri, Shortcuts, or Spotlightapp-intents-specialist + app-intents-whats-new-27
Has widgetswidget-generator or widgetkit
Uses Core Datacore-data-expert (+ migration-patterns if migrating)
Uses Apple Intelligencefoundation-models
Plays musicmusickit
Is in several languagesios-localization
Needs new tests or is heading into a big refactorswift-testing-expert, characterization-test-generator, flow-walkthrough
Uses Firebasefirebase-crashlytics, xcode-project-setup
Builds slowlyXcode Build Optimization
Is about to shipaudit-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.