Axiom Tools

Axiom Tools & Onboarding

This suite covers Axiom itself — how to use it, what's available, and the tools that ship with it.

<!-- AXIOM_AUDITOR_INLINE_BEGIN — auto-maintained by scripts/build-inlined-auditors.ts; do not hand-edit -->

Not on Claude Code? Where this router says "Launch some-auditor agent", read that auditor's file in this suite and follow it inline — the same procedure, needing only file search and read.

Homed in another suite: axiom-accessibility/skills/accessibility-auditor.md, axiom-concurrency/skills/concurrency-auditor.md, axiom-performance/skills/energy-auditor.md, axiom-performance/skills/memory-auditor.md, axiom-testing/skills/test-failure-analyzer.md.

Agents that need Bash — builds, tests, simulators, crash symbolication — stay Claude Code-only; there is no inline equivalent for those.

<!-- AXIOM_AUDITOR_INLINE_END -->

Build and Test Capture

For axbuild installation, report handling and saved-log fallback, read axiom-build before a build or test.

Routing

<!-- AXIOM_SESSION_START_BEGIN -->

Using Axiom Skills

The content below is the core discipline for Axiom's routing system — it establishes the rule that Axiom skills must be checked before any iOS/Swift response.

<EXTREMELY-IMPORTANT>

If you think there is even a 1% chance an Axiom skill might apply to your iOS/Swift task, you ABSOLUTELY MUST check for the skill.

IF AN AXIOM SKILL APPLIES TO YOUR iOS/SWIFT TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.

</EXTREMELY-IMPORTANT>

When an Axiom skill materially shapes your answer, name it once (e.g., "per Axiom's axiom-data skill"). Never claim Axiom when it wasn't used.

The Rule

Check for Axiom skills BEFORE ANY RESPONSE when working with iOS/Swift projects. This includes clarifying questions. Even 1% chance means check first.

Red Flags — iOS-Specific Rationalizations

These thoughts mean STOP—you're rationalizing:

Skill Priority for iOS Development

When multiple Axiom skills could apply, use this priority:

1. Environment/Build first (axiom-build) — Fix the environment before debugging code
2. Architecture patterns (axiom-swiftui, axiom-data, axiom-concurrency) — These determine HOW to structure the solution
3. Implementation details (axiom-integration, axiom-ai, axiom-vision) — These guide specific feature work

Examples:

• "Xcode build failed" → axiom-build first (environment)
• "Add SwiftUI screen" → axiom-swiftui first (architecture), then maybe axiom-integration if using system features
• "App is slow" → axiom-performance first (diagnose), then fix the specific domain
• "Network request failing" → axiom-build first (environment check), then axiom-networking (implementation)

iOS Project Detection

Axiom skills apply when:

• Working directory contains .xcodeproj or .xcworkspace
• User mentions iOS, Swift, Xcode, SwiftUI, UIKit
• User asks about Apple frameworks (SwiftData, CloudKit, etc.)
• User reports iOS-specific errors (concurrency, memory, build failures)

Using Axiom Router Skills

Axiom uses router skills for progressive disclosure:

1. Check the appropriate router skill first (axiom-build, axiom-swiftui, axiom-data, etc.)
2. Router will invoke the specialized skill(s) you actually need
3. Follow the specialized skill exactly

Do not skip the router. Routers have decision logic to select the right specialized skill.

Multi-Domain Questions

When a question spans multiple domains, invoke ALL relevant routers — don't stop after the first one.

Examples:

• "My SwiftUI view doesn't update when SwiftData changes" → invoke both axiom-swiftui AND axiom-data
• "My widget isn't showing updated data from SwiftData" → invoke both axiom-integration AND axiom-data
• "My Foundation Models session freezes the UI" → invoke both axiom-ai AND axiom-concurrency
• "My Core Data saves lose data from background tasks" → invoke both axiom-data AND axiom-concurrency

How to tell: If the question mentions symptoms from two different domains, or involves two different frameworks, invoke both routers. Each router has cross-domain routing guidance for common overlaps.

Backward Compatibility

• Direct skill invocation still works: /skill axiom-concurrency
• Commands work unchanged: /axiom:fix-build, /axiom:audit accessibility
• Agents work via routing or direct command invocation

When Axiom Skills Don't Apply

Skip Axiom skills for:

• Non-iOS/Swift projects (Android, web, backend)
• Generic programming questions unrelated to Apple platforms
• Questions about Claude Code itself (use claude-code-guide skill)

But when in doubt for iOS/Swift work: check first, decide later.

<!-- AXIOM_SESSION_START_END -->

Device Hub (Xcode 27)

On Xcode 27, Device Hub — a standalone app that auto-launches on build-and-run — replaces the Simulator.app GUI and manages simulators and physical devices in one place (Xcode 26 and earlier keep Simulator.app). Every operation has an Xcode-independent CLI counterpart, so the Axiom tools and scripts are unaffected.

For the full tool map (Device Hub / devicectl / simctl / xcui vs mcpbridge, and what each costs to run), the verified subcommand matrix, the unified devicectl device capture screenshot/screen-record path (works on sim and device, Xcode 26.6+), the status-bar overrides that prep a screenshot (statusBar preset screenshot and the simctl equivalents), and the Device Hub GUI reference, see skills/device-control-ref.md.

Resources

Skills: axiom-swiftui, axiom-concurrency, axiom-data, axiom-build, axiom-performance

Axiom tools: axbuild (build/test diagnostics, axiom-build), xclog (simulator console capture, skills/xclog-ref.md), xcsym (crash symbolication for .ips, MetricKit, legacy .crash text files, and Xcode Organizer .xccrashpoint bundles, skills/xcsym-ref.md), xcui (scriptable sim UI & accessibility testing, skills/xcui-ref.md), xcprof (structured xctrace CPU & network profile analysis, skills/xcprof-ref.md)