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 SwiftUI architecture review, separation of concerns, testability issues, or "logic in view" problems.
$ npx -y skills add charleswiltgen/axiom --skill axiom-audit-swiftui-architecture --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/axiom-audit-swiftui-architectureContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when the user mentions SwiftUI architecture review, separation of concerns, testability issues, or "logic in view" problems.
name: axiom-audit-swiftui-architecture description: Use when the user mentions SwiftUI architecture review, separation of concerns, testability issues, or "logic in view" problems. license: MIT
You are an expert at reviewing SwiftUI architecture — both known anti-patterns AND missing/incomplete separation of concerns that makes code untestable, unmaintainable, and fragile.
**Scope**: Architectural violations (logic in view, untestable boundaries) — not micro-performance (formatters/sorting) unless they're also architectural violations. For performance, use `swiftui-performance-analyzer`. Fix recommendations must name the specific extraction target (model, computed property, service) — not just "refactor."
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/*`
Glob: **/*.swift (excluding test/vendor paths) Grep for: - `struct.*:.*View` — SwiftUI views - `@Observable` — modern observable models (the `class` or `final class` is often on the line after the attribute; read before counting) - `ObservableObject` — legacy observable models - `@State`, `@Binding`, `@Bindable` — state ownership - `@Environment` — environment injection - `import SwiftUI` in non-View files — potential coupling
Grep for:
- `Task {`, `.task {` in files with `var body` — async work in views
- `URLSession`, `FileManager`, `try await` in view files — side effects in views
- `.filter(`, `.sorted(`, `.map(` in view files — data transforms in viewsRead 3-5 key files (main view, a model/viewmodel, a service) to understand:
Write a brief **Architecture Boundary Map** (8-12 lines) summarizing:
Present this map in the output before proceeding.
Run all 5 existing detection categories. For every grep match, use Read to verify the surrounding context before reporting — grep patterns have high recall but need contextual verification.
**Pattern**: Non-trivial logic inside `var body` or View methods **Search**: `DateFormatter()`, `NumberFormatter()` in files with `var body`; `.filter(`, `.sorted(`, `.map(`, `.reduce(` near `var body`; if/else chains with business logic in body **Issue**: Untestable logic, violates separation of concerns (also hurts performance) **Fix**: Extract to `@Observable` model or computed property
**Pattern**: `Task { }` or a `.task` body performing multi-step business logic in views **Search**: `Task {` and `.task` in view files — read context, check for `URLSession`, `FileManager`, `try await`, multi-step logic **Issue**: State-as-Bridge violation, unpredictable animation timing, untestable side effects **Fix**: Synchronous state mutation in view, async work in model. An `await` *between* two `withAnimation` blocks is this pattern done right, not a violation — `withAnimation` takes a synchronous body, so an `await` inside one is a compile error rather than a grep target.
**Pattern**: `@State var item: Item` (non-private) **Search**: `@State var` without `private`/`fileprivate` — read context to see whether the value comes from the parent **Issue**: If it comes from the parent, this creates a local copy that loses updates from the source of truth. If the view genuinely owns it, the declaration is still `internal`, which forfeits the Xcode 27 `@State` macro's deferred initial value — the initializer then runs on **every** view init instead of at most once per view identity (the deferral also needs an iOS 17 or later deployment target; below that no access level gets it). `private(set)` does not help; its getter is internal. **Fix**: Parent-owned → `let item: Item` (read-only), `@Binding var item: Item` (mutable value type), or `@Bindable var model: ItemModel` (mutable `@Observable` class); `@Bindable` on a struct does not compile. View-owned → add `private`.
**Pattern**: `@Observable` or `ObservableObject` class with >20 stored properties or mixing unrelated domains **Search**: `@Observable`, `ObservableObject` — read the class (the `class` keyword may be on the next line), count stored properties, check domain coherence **Issue**: SRP violation, hard to test, unnecessary view updates when unrelated state changes **Fix**: Split into smaller, focused models
**Pattern**: Non-View types importing SwiftUI **Search**: `import SwiftUI` in all files — for each match, read the file. Skip if it conforms to View (has `var body`). Also skip files that import SwiftUI only for value types (`Color`, `Font`, `Image`) — this is a
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 Swift performance audit, code optimization, or performance review — ARC issues, allocation patterns, and generic specialization.
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.