Axiom: 280 packaged skills and 42 agents for Apple platform code

A corpus distributed as plugins, not a library you depend on

Axiom is a collection of skills, agents, commands and tools for Apple platform development, packaged for AI coding harnesses. The package description names the target stack precisely: Swift 6, SwiftUI, Liquid Glass, Apple Intelligence, and the xOS family of iOS, iPadOS, watchOS and tvOS. The repository's own `package.json` describes the same scope and declares the version as `27.5.0`.

The delivery model is the interesting part. There is no runtime library to import and no API your app links against. Instead the repository ships per-harness plugin directories: `.claude-plugin/`, `.cursor-plugin/`, `axiom-codex/`, `axiom-cursor/`, `axiom-mcp/` and `axiom-pi/`. The `pi` block in the package manifest points at `.claude-plugin/plugins/axiom/skills` for skills and `axiom-pi/src/index.ts` for extensions, which shows that one source of content is projected into each harness's expected layout.

That projection is generated, not hand-maintained. The build script chain in `package.json` runs a series of generators, one per target, in sequence: `build:audit-areas`, `build:shared`, `build:auditors`, `build:codex`, `build:cursor`, `build:mcp` and `build:docs`. Each target also has a check mode, `check:codex` and `check:cursor`, which run the same generators in a verification mode rather than writing output. There is a `check:refs` script that validates cross-references, and a `check:ci` script that runs unit tests, hook tests and a leak scan.

So the content is single-source and the per-harness trees are build artifacts. That is the right structure for something like this, and it is also why the `scripts/` directory is larger than you might expect for a prompt collection.

Four native tools that give the assistant access to the running app

The most concrete part of Axiom is not the prompt text. It is the set of four tools that read things an assistant otherwise cannot see.

`xclog` is a console capture tool that gives AI assistants access to simulator and device logs. `xcsym` is a crash symbolication tool for `.ips` files, MetricKit reports and Apple's legacy `.crash` text format, with automatic dSYM discovery and pattern categorisation. `xcui` drives and validates the simulator UI and accessibility, which the documentation describes as tapping by accessibility ID, dumping the accessibility tree, and checking VoiceOver and Dynamic Type. `xcprof` records and analyses CPU and performance traces through `xctrace` without requiring you to open Instruments.

Each of these addresses a specific and common failure in assistant workflows. A language model cannot read a simulator log it was never given, and it cannot symbolicate a crash without the dSYM. The tools close that gap by making the artefacts available locally, which is also why they are described as built-in rather than as instructions the model has to follow.

The `tools/` directory at the repository root is where they live, and the MCP package at `axiom-mcp/` is how they are exposed to harnesses that speak the Model Context Protocol. That directory is a separate package with its own build, `cd axiom-mcp && pnpm run build:bundle`, which is the only step in the root build chain that changes working directory.

The `xcsym` detail about automatic dSYM discovery is worth flagging for anyone with an existing crash triage workflow. It means the tool is trying to remove the manual step of pointing at the right dSYM, which is usually the slow part of reading an `.ips` file.

Installation paths differ by harness, and the Cursor path has a boundary

Axiom documents a separate install path per harness, which is the practical reality of a multi-harness distribution.

For Claude Code, it is a plugin marketplace add, and then you search for "axiom" in the `/plugin` menu and install:

/plugin marketplace add CharlesWiltgen/Axiom

For the Claude app in the browser or on the desktop, the path is Customize > Plugins, then Add > Add marketplace, entering `CharlesWiltgen/Axiom`, then adding the axiom plugin. The documentation explains the split of responsibilities: chat loads the skills, Cowork adds the agents and hooks, and Claude Code picks the plugin up from your account.

Cursor is a native plugin, and its generated bundle is described as including skill routers, agents, `/axiom-*` commands, advisory hooks and automatic discovery of its MCP server configuration. The install guide is linked for the macOS support boundary and local installation steps, which is a hint that the Cursor path has a platform constraint the other paths do not.

The Pi terminal coding agent takes a single command:

pi install git:github.com/CharlesWiltgen/Axiom

For MCP-only setups, covering VS Code, Cursor in MCP-only mode, Gemini CLI and others, there is a dedicated MCP setup guide, and for Xcode with the Claude Agent or Codex there is an Xcode integration guide.

The variety is the point, and also the cost. Every harness has its own notion of what a plugin is, and this project maintains a generator for each. A user on an unusual harness will fall back to the MCP path, which is the only one that is protocol-level rather than convention-level.

The counts are auto-maintained, so treat them as a moving target

The headline numbers in the README are explicitly marked as auto-maintained, with a comment saying the block is maintained by `scripts/set-version.js` and should not be hand-edited. The counts are 280 skills covering UI, data, concurrency, performance, networking, accessibility and more, 42 agents that autonomously scan for issues such as memory leaks, concurrency violations and build problems, and 17 commands for quick audits and diagnostics.

The same auto-generated pattern shows up in the Cursor paragraph, where the skill router, agent and command counts are inserted with placeholder comments so the numbers stay in sync across the documentation. That is tidy engineering, and it also means the numbers in any screenshot or article you read are only accurate for the version it was written against.

The version scheme is the clearest signal about how the project is versioned. The releases are v27.4.0, v27.4.1 and v27.5.0, all published on 2026-10-15, and the README states that Axiom is on a `27.x` beta that tracks Apple's OS 27 developer betas, with OS-27 coverage landing continuously through the beta season and guidance for OS 26 and earlier staying stable. The major version is the OS version. That is a deliberate coupling to Apple's release calendar, and it means an Axiom upgrade can arrive with new OS guidance every time Apple ships a beta.

The stated quality approach is that every discipline skill is TDD-tested against real developer pressure scenarios, with a quality page linked for detail. The repository backs that with `test:unit`, `test:hooks`, `test:routing`, `test:cursor` and a `test:full` script, and a `predeploy` script that gates the release path.

Commands cover the daily loop, agents cover the audit sweep

The interaction model is split into three layers, and the split is the most usable thing in the README.

At the bottom, skills activate automatically based on your question. The documented prompts are the everyday ones: getting a build failure in Xcode, fixing Swift 6 concurrency errors, memory leaks, adding a database column safely, seeing what the app is logging, and symbolizing a crash file.

Above that sit the commands, which you invoke directly and which are prefixed with `/axiom:`:

/axiom:console          # Capture simulator console output
/axiom:analyze-crash    # Parse and triage .ips, MetricKit, or .crash reports
/axiom:fix-build        # Diagnose build failures
/axiom:audit memory     # Scan for memory leaks
/axiom:audit concurrency # Check for data races
/axiom:health-check     # Run all relevant auditors

Above both sit the agents, 42 of them, which run unattended and scan for issues rather than answering a prompt. The commands are the useful middle layer for a developer who knows what they want, and the `health-check` command is a natural entry point because it runs all relevant auditors at once.

What is missing is any statement about how the routing between skills works in detail. The generated Cursor bundle is described as containing skill routers, and there is a `test:routing` script, so routing is tested, but the README does not explain how an ambiguous question is resolved between 280 skills. For a corpus this large, that is the question a reader would most want answered, and it belongs in the documentation site rather than the repository.

The project also has a community layer: an r/axiomdev subreddit for version announcements with changelogs, GitHub issues for defects and feature requests, and GitHub discussions for usage patterns and questions.

MIT licensed, versioned like an SDK, and shipped as many trees

Axiom is MIT licensed, with the licence file in the repository root. That is a permissive grant with no copyleft obligation, so the content can be used, modified and redistributed inside a commercial product, and it is a licensing observation rather than legal advice, with the `LICENSE` file governing.

The versioning deserves attention because it is unusual for a prompt collection. The package version tracks the OS major version, the release tags follow the same numbering, and releases land in a burst on a single day. For a consumer, that means the thing you install is named after the OS you are targeting, which is helpful when you are on the beta and confusing when you are not. A developer on OS 26 reading the README sees 280 skills and a `27.x` beta, and has to work out which parts apply to them. The documentation says the OS 26 and earlier guidance stays stable, which addresses the concern but does not remove the cognitive load.

The distribution shape has a cost too. A single repository with six harness-specific trees, per-harness generators, a check mode for each, cross-reference validation, hook tests, routing tests and a leak scan is a lot of machinery for a set of prompts. That machinery is what makes the multi-harness promise work, and it is also what a fork of this project would have to maintain.

The last push was on 2026-10-13 and the repository is not archived. The `docs/` directory is built with VitePress, with `docs:dev` and `docs:preview` scripts, and the full documentation, skill catalog and guides are published at `charleswiltgen.github.io/Axiom`.

Editorial conclusion

Axiom fits an Apple platform developer who works inside an AI coding harness daily and is annoyed by the same classes of problem, migration data loss, Swift 6 concurrency diagnostics, memory leaks, stalled xcodebuild processes, and who wants the logs and crash files of the running app in reach of the assistant. It does not fit a team that has to work in one specific harness with a locked plugin policy, and it does not fit a team that treats a vendor-neutral build of a large prompt corpus as a liability rather than an asset. Verify first that the harness you use has a documented install path, that the `xclog`, `xcsym`, `xcui` and `xcprof` tools run on your machine with the permissions your project needs, and that the OS 27 beta guidance in the current `27.x` line matches the SDK you have installed, since the project tracks Apple's beta season and the guidance for OS 26 and earlier is stated to be stable.

Frequently asked questions

Official sources

1. CharlesWiltgen/Axiom on GitHub
2. License: MIT
3. Project website
4. README
5. Releases