The Apple skills repo loads 23 category descriptions into context and hides 164 skills behind them

The plugin puts 23 category skills in context and routes the other 141 on demand

The design decision that makes a 164-skill library usable is that you do not load 164 skills. Installing through the plugin surfaces the library as 23 category skills, and each category skill routes to its sub-skills on demand, so only 23 short descriptions sit in context at any time.

/plugin marketplace add rshankras/claude-code-apple-skills
/plugin install apple-skills@indie-apple-stack

You reach them as `/apple-skills:generators`, `/apple-skills:testing` and so on. The context cost is proportional to the number of categories rather than the number of skills, which is the whole trick.

The counting is not naive and the project is explicit about it. The stated total is 164 skills across 23 categories, with the rule that single-skill categories count their category file while other index files are not counted. That rule is enforced in CI by `scripts/check-counts.sh`, so the number on the front page is generated rather than maintained by hand. A contributor adding a skill therefore has to decide which side of that rule it falls on, which is a small but real design constraint on the directory layout.

63 of the 164 are generators, and 77 are process rather than platform knowledge

Read the category table as a distribution rather than a list. Generators account for 63, Product for 14, Testing and App Store for 12 each, iOS for 10. Add Generators and Product and you have 77 of 164 skills, close to half the library, aimed at taking a project from an idea to a submitted app rather than at explaining how a platform behaves.

The tail of the distribution is where the intent shows. Seven categories hold exactly one skill each: Security, Core ML, watchOS, SwiftData, MapKit, Foundation and Release Review. Apple Intelligence holds 3, Legal 2, visionOS 2, Shared 2. So the depth is concentrated on shipping, and the coverage of individual framework areas is a single file apiece.

Those singletons are still real content. Security covers privacy manifests and required reason APIs, Core ML covers Vision and NaturalLanguage model integration, watchOS covers watch apps, complications, health and fitness and widgets, Foundation covers AttributedString updates, MapKit covers the GeoToolbox and place descriptors. But a team building a watch app should know they are working from one skill in that category rather than a set.

Plugin installs follow main, and the only pinned snapshot is a manual clone at an era tag

There is no version pinning on the plugin route, and the front page says so directly. You always track `main`, and updating is a single command:

/plugin marketplace update indie-apple-stack

The repository has no GitHub releases at all, so a plugin subscriber has no release to pin to. The documented alternative is a manual clone at an annotated tag, where era tags mark each WWDC content boundary:

git clone --branch wwdc25-era-final https://github.com/rshankras/claude-code-apple-skills.git

and then copying `skills/` by hand. So the choice is explicit rather than accidental: continuous updates from main for convenience, or a frozen WWDC-era snapshot that you have to install yourself. The CHANGELOG is the index of those boundaries, which means the rollback story depends on someone remembering to tag.

That framing also explains the last push date. This is a collection that moves with Apple's own release cycle rather than on its own schedule, so the tag scheme is the release mechanism and the changelog is the release notes.

Copying the directory and installing the plugin are not the same thing

The manual route copies a directory into a skills folder, either per project or globally:

cp -r claude-code-apple-skills/skills your-project/.claude/skills/
cp -r claude-code-apple-skills/skills ~/.claude/skills/

That copies `skills/`, not the plugin manifest, and the plugin manifest is what produces the 23 category entries. The front page does not say whether the category routing survives a plain directory copy, and given that the routing is described as a property of the plugin install, the reasonable expectation is that a copied tree exposes the raw sub-skill directories instead of the 23 grouped categories. That is the opposite of the context saving the plugin route is built around.

Two other install details are easy to miss. The same marketplace carries a second package from a different repository, so one `marketplace add` gives you both the knowledge layer and the workflow layer:

/plugin install apple@indie-apple-stack

The two packages are named differently, `apple-skills` and `apple`, from the same `indie-apple-stack` marketplace. Installing one does not install the other, and nothing on the page says so.

Several generators name a specific vendor, so the output is decided before you run them

The generator table is where the library stops being neutral. `analytics-setup` produces protocol-based analytics and names TelemetryDeck and Firebase as the implementations. `error-monitoring` covers crash reporting with Sentry and Crashlytics. `ci-cd-setup` chooses between GitHub Actions and Xcode Cloud. `auth-flow` is Sign in with Apple plus biometrics, and `paywall-generator` is StoreKit 2 subscriptions specifically, not a generalized purchase layer.

Others are platform-bound in a less obvious way. `localization-setup` uses string catalogs, `deep-linking` covers both URL schemes and universal links, `test-generator` targets Swift Testing and XCTest, `preview-data-generator` produces SwiftUI preview sample data with a state and appearance variant matrix, and `persistence-setup` is SwiftData with optional iCloud.

The table stops mid-row. The last visible entry is `feature-flags` with a description beginning `Local/remote fe`, which is as far as the front page goes. That is one truncated cell rather than a missing section, but it does mean the last generator's scope is not stated. Reading the list as a menu is the right frame; each of these skills is a decision about your stack that has already been made for you.

Four repositories, four layers, and one marketplace carrying two of them

The library positions itself as the knowledge layer of a four-repository stack, and the table names what each layer is for.

| Layer | What it is | |---|---| | Knowledge | 164 skills for how to build right | | Workflow | 53 `/apple:*` commands, spec-driven idea to App Store | | Action | 7 agents, GitHub issue to App Store | | Integration | 65+ MCP tools against the live App Store Connect API |

Only the knowledge layer is in this repository, and the intro says plainly to use one or all of them. The consequence for context is arithmetic: this repo contributes 23 category descriptions under the plugin route, the workflow layer contributes 53 commands, and the action layer 7 agents. Those are separate installs from a single marketplace entry, which is convenient for setup and unhelpful for anyone trying to work out what is loaded.

The Action layer's framing is also the honest one about what these tools are for: an agent that takes a GitHub issue and produces an App Store submission is doing something most teams would want a human checkpoint inserted into, and the front page does not claim otherwise.

watchOS gets one skill, tvOS is absent, and the directory tree stops mid-comment

The opening sentence names iOS, macOS, watchOS and visionOS, and the category table backs three of those with real depth. iOS holds 10 skills covering code review, UI review, navigation, iPad, migration, accessibility and audits, plus simulator and device runs. macOS holds 8, covering Tahoe APIs, SwiftData and an AppKit bridge. visionOS holds 2, on spatial design and widget development.

There is no tvOS category, and no Mac Catalyst entry either, despite the project describing itself as Apple platform development and shipping an App Store workflow layer that would have to target it. That is an omission rather than a stated exclusion.

The directory listing is also incomplete. It walks `skills/ios/`, `skills/macos/`, `skills/product/`, then `skills/generators/` with nine named sub-directories and a `(63 total)` marker, and stops at `skills/growth/` with a comment that breaks after `Growth audit,`. So twenty of the twenty-three category directories are not shown in the tree on the front page, and the ones that are shown illustrate the pattern: category directory, sub-directories per skill, category file for the singletons.

The documentation table does route you onward: `docs/USAGE.md` for new versus existing apps, `docs/ROADMAP.md` for status, `CHANGELOG.md` for era tags, and `skills/product/WORKFLOW.md` for the full idea to App Store path.

Editorial conclusion

Use this library if you are building for Apple platforms with Claude Code and want the routing rather than the volume. The category layer is the actual product: 23 short descriptions in context instead of 164, with sub-skills pulled in on demand, and a skill-creator and skill-auditor pair for extending the set yourself. The generator half is the part that will save you the most time, since sign-in, StoreKit 2 subscriptions, APNs, deep links and accessibility are all there as named skills rather than as things to re-prompt for. Two things to settle first. Decide which install route you want, because they are not equivalent: the plugin route gives you the category routing and follows main, while the copy route gives you the directory and no stated version story, so the only stable snapshot anywhere is a manual clone at an era tag. And read the vendor names in the generator table before you run one, since several of these skills pick a specific service for you. Two smaller checks: the category table has no tvOS entry despite the project describing itself as Apple platform development, and watchOS has a single skill. Neither is disqualifying, both are the kind of thing worth knowing before you plan a launch around a category that turns out to be one file deep. What this is not is a substitute for Apple's own documentation or for the HIG. It is a set of instructions written by one person, kept in step with WWDC seasons by tagging era boundaries, and it will drift from the platform faster than Apple's own material does.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. rshankras/claude-code-apple-skills on GitHub