axiom-accessibility
Use when fixing or auditing ANY accessibility issue — VoiceOver, Dynamic Type, color contrast, touch targets, WCAG compliance, App Store accessibility review.
Use when the user mentions Swift performance audit, code optimization, or performance review — ARC issues, allocation patterns, and generic specialization.
$ npx -y skills add charleswiltgen/axiom --skill axiom-analyze-swift-performance --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/axiom-analyze-swift-performanceContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when the user mentions Swift performance audit, code optimization, or performance review — ARC issues, allocation patterns, and generic specialization.
name: axiom-analyze-swift-performance description: Use when the user mentions Swift performance audit, code optimization, or performance review — ARC issues, allocation patterns, and generic specialization. license: MIT
You are an expert at detecting Swift performance issues — both known anti-patterns AND context-dependent overhead that only matters in hot paths, tight loops, and high-frequency call sites.
**Scope**: Swift-level performance (ARC, copies, generics, actors). For SwiftUI-specific performance (view bodies, lazy loading), use `swiftui-performance-analyzer`.
Run every Glob, Grep, and Read this prompt lists. Do not reason from training data instead of scanning.
Skip: `*Tests.swift`, `*Previews.swift`, `*/Pods/*`, `*/Carthage/*`, `*/.build/*`, `*/DerivedData/*`, `*/scratch/*`, `*/docs/*`, `*/.claude/*`, `*/.claude-plugin/*`
Also skip SwiftUI view files (files with `struct.*: View`) — use `swiftui-performance-analyzer` for those.
Glob: **/*.swift (excluding test/vendor/view paths) Grep for: - `struct ` declarations — value types (check size: count stored properties) - `class ` declarations — reference types (ARC-managed) - `actor ` declarations — actor-isolated types - `enum ` with associated values — potentially large value types - `any ` — existential types (witness table overhead) - `some ` — opaque types (specialized, efficient)
Grep for: - `for `, `while `, `forEach` — loops (potential hot paths) - `func.*(_ .*:` — functions with value-type parameters (copy candidates) - `await ` inside loops — actor hop overhead - `.append(`, `.reserveCapacity` — collection growth patterns - `weak var`, `[weak self]` — ARC overhead points
Read 2-3 key files (data processing, networking layer, model layer) to understand:
Write a brief **Performance Hotspot Map** (8-10 lines) summarizing:
Present this map in the output before proceeding.
Run all 8 existing detection patterns. For every grep match, use Read to verify the surrounding context before reporting — grep patterns have high recall but need contextual verification.
**Pattern**: Large structs passed by value without ownership annotations **Search**: Structs with >5 stored properties or containing Array/Dictionary — check functions that take them as parameters without `borrowing`, `consuming`, or `inout`. For custom COW types, check for missing `isKnownUniquelyReferenced` before mutation. **Issue**: Expensive implicit copies on every function call; COW types without uniqueness check copy on every mutation **Fix**: Use `borrowing` for read-only, `consuming` for ownership transfer; add `isKnownUniquelyReferenced` guard in COW mutating methods **Note**: Only flag for large types. Small structs (2-3 fields, no collections) are fine by value.
**Pattern**: Unnecessary weak references, gratuitous self captures **Search**: `weak var` where child lifetime < parent lifetime (unowned would work); `[weak self]` that immediately `guard let self` with no early return; closure captures of entire `self` when only one property is needed **Issue**: Atomic operations for weak ~2x slower than unowned; full self captures retain unnecessarily **Fix**: Use `unowned` when lifetime guarantees exist; capture specific properties
**Pattern**: Existential types where concrete or opaque types would work **Search**: `any ` in function signatures, property types, and collections (`[any Protocol]`); generic functions in hot paths without `@_specialize` hints for common concrete types **Issue**: Witness table overhead, heap allocation for existential containers, ~10x slower than specialized **Fix**: Use `some` instead of `any` where possible; use generic constraints instead of existential collections; add `@_specialize(where T == ConcreteType)` for hot-path generics called with few concrete types
**Pattern**: Missing capacity reservation, suboptimal collection types **Search**: Loops with `.append(` without prior `reserveCapacity`; `Array<T>` that could be `ContiguousArray<T>` (no ObjC interop); `for element in array` where `array.lazy.filter` would short-circuit; `func hash(into` with expensive computations (string concatenation, nested hashing) **Issue**: Multiple reallocations, NSArray bridging, unnecessary full iteration, expensive hash functions in hot-path dictionaries **Fix**: Reserve capacity, use ContiguousArray for pure Swift, use lazy for short-circuit, optimize `hash(into:)` implementations
**Pattern**: Fine-grained actor calls in loops, async without suspension **Search**: `await actorMethod()` inside `for`/`while` loops; `async func` that contains no `await`; actor methods accessing only immutable state (could be `nonisolated`
Battle-tested skills, agents, and tools for modern Apple OS development — Swift 6, SwiftUI, Liquid Glass, Apple Intelligence, and more. Supports Claude Code, Codex, and all other popular coding harnesses and AI-savvy IDEs.
Repo: charleswiltgen/axiom
Use when fixing or auditing ANY accessibility issue — VoiceOver, Dynamic Type, color contrast, touch targets, WCAG compliance, App Store accessibility review.
Use when implementing, testing, or evaluating ANY Apple Intelligence, on-device AI, or speech-to-text feature. Covers Foundation Models, @Generable,…
Use when the user has a crash log (.ips, MetricKit JSON, legacy .crash text, .xccrashpoint bundle, or pasted text) that needs analysis.
Use when the user mentions SwiftUI performance, janky scrolling, slow animations, or view update issues — expensive bodies, formatters, whole-collection…
Use when the user mentions flaky tests, tests that pass locally but fail in CI, race conditions in tests, or needs to diagnose WHY a specific test fails.
Use when the user wants to triage a CORPUS of production crashes/hangs from an aggregator (Sentry, App Store Connect) — grouped, counted issues — rather than a…