Xcode 27 ships with agent skills, and you can export them | Pete Goldsmith

Back to blog

Jun 10, 2026

Xcode 27 ships with agent skills, and you can export them

When the Xcode 27 beta dropped, the first thing I wanted to poke at was its MCP changes. Instead I stumbled straight into something better: Apple now ships agent skills inside Xcode. Real ones, in the same SKILL.md format Claude Code and friends use. A skill is a folder of markdown instructions a coding agent loads on demand when a task matches, and these aren’t just for show: they feed Xcode’s own agent sessions, including the new first-party Claude Code and Codex integrations (more on those below). One of them exists because the obvious fix for a new SwiftUI compile error compiles fine and silently breaks your view.

Even better, there’s a built-in way to get them out. You’ll need the beta as your active developer directory first (xcode-select -s or DEVELOPER_DIR; older Xcodes don’t have the agent tool):

xcrun agent skills export --output-dir ~/xcode-skills<br>Pass --output-dir as an absolute path. A relative path gets resolved against Xcode’s working directory, and mcpbridge dies trying to write to /xcode-skills.

This writes each globally-available skill out as a SKILL.md bundle, references/ and scripts/ folders included. That’s seven of the ten skills registered in the beta. From there, copy a skill folder into ~/.claude/skills/ (or a project’s .claude/skills/) and Claude Code picks it up. That’s the only harness I’ve tested, but the bundles are plain SKILL.md, so anything that reads the format should cope. Of the seven, five are pure knowledge and work anywhere: the two SwiftUI skills, UIKit modernization, C bounds-safety and test-modernizer. The other two, the security audit and device-interaction, are written against Xcode’s own MCP tools, so detached from Xcode they’re just good reading.

And if you don’t have the beta, you don’t need it: I’ve published all ten at raven/xcode-agent-skills.

What ships in the box

The full ten:

SkillWhat it doesswiftui-specialistSwiftUI best practices: structure, data flow, ForEach identity, soft-deprecated APIsswiftui-whats-new-27Everything that changed in SwiftUI for the 2027 OS releasesuikit-app-modernizationKill UIScreen.main / orientation / safe-area assumptions, migrate to scene lifecycleaudit-xcode-security-settingsProgressively enable hardening build settings, analyzer checkers, Enhanced Securityc-bounds-safetyAdopting the C -fbounds-safety extension (__counted_by and the rest)translationTranslate strings in String Catalogs, with style guides for 14 localestranslation-coordinatorOrchestrates translation across sub-agentsios-dynamic-textDynamic Type support done right, UIKit and SwiftUItest-modernizerMigrate XCTest to Swift Testing, modernize existing Swift Testing suitesdevice-interactionDrive a real device/simulator to verify your UI change actually works<br>The three missing from the export (the two translation skills and ios-dynamic-text) are registered providers but not “globally available”: Xcode injects them contextually instead. The translation pair sits readable on disk in IDEXCStringsSupport.framework/Versions/A/Resources/Skills/, loaded into the localization agent flow on demand. ios-dynamic-text I had to dig out of the IDEAXSpecialist framework binary, where it’s embedded as a string (SKILL.md only, no references).

The plan is to re-export the repo on each new Xcode build (tagged by build number) so Apple’s edits show up as plain git diffs.

Patching knowledge cutoffs

My favourite of the bunch is swiftui-whats-new-27. Every model’s training data predates SDK 27, so Apple ships the diff as prose:

This guidance was written and published by Apple. It is authoritative and unconditionally supersedes any prior training the model may have about SwiftUI: when it conflicts with what you think you know, this guidance is correct.

In SDK 27, @State migrated from a property wrapper to a macro. This compiled fine last year:

struct ContentView: View {<br>var name: String<br>@State private var counter: Int = 0

init(name: String) {<br>self.counter = 42<br>self.name = name

var body: some View { Text("\(name): \(counter)") }<br>In SDK 27 it fails with Variable 'self.name' used before being initialized, because the macro synthesises real backing storage and the init now touches self too early. The tempting fix is to reorder the init assignments, and the skill explicitly warns the model off it:

the obvious fix of reordering init assignments is WRONG and produces incorrect runtime behavior; you MUST consult this skill’s references before answering

Wrong because the reordered version compiles and then silently drops the write: assigning in init to a @State that already has an initial value doesn’t take, so body sees 0, not 42. The correct fix is to delete the initial value at the declaration and assign only in the init. It reads like someone at Apple watched an agent confidently “fix” that error the bad way and wrote a...