/ Verzeichnis / Playground / Axiom (xOS Dev Skills)
← Alle Server ↗ GitHub
● Community CharlesWiltgen ⚡ Sofort

Axiom (xOS Dev Skills)

von CharlesWiltgen · CharlesWiltgen/Axiom

Apple-Plattform-Entwicklung, die nicht gegen Swift 6 kämpft — opinionierte Skills für SwiftUI, strukturierte Nebenläufigkeit, @Observable und modernes Build-Tooling.

Axiom ist ein Claude-Code-Skill-Bundle für das Ausliefern von Produktions-Apps auf iOS / iPadOS / watchOS / tvOS. Es erzwingt moderne Konventionen: SwiftUI-first, @Observable statt ObservableObject, async/await statt Completion-Handler, Value-Typen und Swift-6-Nebenläufigkeitsregeln. Enthält Accessibility-Checks, App-Store-Readiness und Xcode-Projekt-Hygiene.

▶ Demo ansehen 📦 Installieren 💡 Anwendungsfälle

Warum nutzen

Hauptfunktionen

Live-Demo

In der Praxis

bereit

Installation

Repository des Autors · Offizielle Dokumentation zu Claude Skills

Anwendungsfälle

Praxisnahe Nutzung: Axiom (xOS Dev Skills)

Einen ViewModel zu @Observable migrieren

👤 iOS-Entwickler, die iOS 17+ übernehmen ⏱ ~45 min advanced

Wann einsetzen: App ist iOS 17+, aber ViewModels sind noch ObservableObject + @Published.

Ablauf
  1. Inventur
    Axiom: alle ObservableObject + @Published im Projekt auflisten. Leaf vs. Shared notieren.✓ Kopiert
    → Liste mit Shape + Abhängigkeits-Hinweisen
  2. Einen migrieren
    ProfileViewModel zu @Observable umstrukturieren. Öffentliche API stabil halten. Bindings der View-Consumer aktualisieren.✓ Kopiert
    → ViewModel migriert; @Bindable in Views verwendet; kein @Published mehr
  3. Prüfen
    xcodebuild für das Schema ausführen. Warnungen melden.✓ Kopiert
    → Sauberer Build; keine Swift-6-Warnungen

Ergebnis: Moderner @Observable-Codebase mit saubereren Views.

Fallstricke
  • Bestehende Tests verlassen sich auf @Published-Projection ($name) — Tests müssen neu geschrieben werden; nicht alle Zugriffsmuster werden direkt gemappt
Kombinieren mit: filesystem · ios-simulator-mcp

Swift-6-Nebenläufigkeits-Warnungen beheben

👤 iOS-Entwickler, die sich auf strikte Swift-6-Nebenläufigkeit vorbereiten ⏱ ~60 min advanced

Wann einsetzen: Der Build ist gelb mit Sendable- / Actor-Warnungen.

Ablauf
  1. Triagieren
    Axiom concurrency-clean: Warnungen klassifizieren in: (1) Actor-Isolation, (2) Sendable-Conformance, (3) Data-Race-Risiko.✓ Kopiert
    → Kategorisierte Liste
  2. Actor-Isolation korrigieren
    Zuerst Kategorie 1 angehen. Minimale Korrekturen vorschlagen; @MainActor auf UI-Typen bevorzugen über globale Isolation.✓ Kopiert
    → Chirurgische Änderungen; kein flächendeckendes @MainActor-Streuen

Ergebnis: Sauberer Swift-6-Build mit intentionalen Nebenläufigkeitsgrenzen.

Fallstricke
  • @MainActor als Abkürzung zum Stummschalten von Warnungen übermäßig verwenden — Skill kennzeichnet das; stattdessen korrektes Actor-Design verwenden

Einen Accessibility-Audit durchführen

👤 iOS-Teams vor dem Release ⏱ ~60 min intermediate

Wann einsetzen: App-Store-Einreichung bald; VoiceOver/Dynamic-Type-Abdeckung gewünscht.

Ablauf
  1. Views scannen
    Axiom a11y: SwiftUI-Views scannen. Fehlende accessibilityLabel, hartcodierte Schriftgrößen, Farben mit geringem Kontrast markieren.✓ Kopiert
    → Pro-View-Issue-Liste
  2. Top-Issues patchen
    Korrekturen für die Top-10-Issues anwenden. Systemfonts für Dynamic Type verwenden.✓ Kopiert
    → Patches angewendet; Build immer noch sauber

Ergebnis: App besteht einen grundlegenden VoiceOver-Walk-through.

Fallstricke
  • Automatisch generierte Labels entsprechen nicht dem mentalen Modell des Benutzers — Mit intentionalen Labels überschreiben
Kombinieren mit: ios-simulator-mcp

Kombinationen

Mit anderen MCPs für 10-fache Wirkung

axiom-xos-skill + ios-simulator-mcp

Skill-Empfehlungen anwenden + auf Simulator testen

Axiom: ProfileVM migrieren. Dann iOS-Simulator: starten, Profilbildschirm screenshoten.✓ Kopiert
axiom-xos-skill + filesystem

Patches im Projekt anwenden

Axiom concurrency-clean: Patches für src/ erstellen. Filesystem: anwenden.✓ Kopiert
axiom-xos-skill + xcodebuildmcp

Build-Verifikation nach Refactoring

Nach Migration XcodeBuild: für Simulator bauen. Warnungen melden.✓ Kopiert

Werkzeuge

Was dieses MCP bereitstellt

WerkzeugEingabenWann aufrufenKosten
vm_migrate_observable viewmodel_path Pro-VM-Migration 0
concurrency_clean scope Swift-6-Vorbereitung 0
a11y_scan scope Vor dem Release 0
appstore_checklist (keine) Vor der Einreichung 0
xcode_hygiene project Regelmäßige Bereinigung 0

Kosten & Limits

Was der Betrieb kostet

API-Kontingent
N/A
Tokens pro Aufruf
Projekt-Scans 10k–40k Token
Kosten in €
Kostenlos
Tipp
Audits auf ein Feature/Ordner begrenzen; nicht eine riesige App auf einmal auffächern

Sicherheit

Rechte, Secrets, Reichweite

Minimale Scopes: filesystem-read filesystem-write
Credential-Speicherung: Keine
Datenabfluss: Keine

Fehlerbehebung

Häufige Fehler und Lösungen

Migration hat @Bindable-Nutzung kaputt gemacht

Einige Views benötigen @Bindable-Wrapper; prüfen, ob der Skill keine übersehen hat

Nebenläufigkeits-Korrekturen ändern Semantik lautlos

Tests nach Migration immer ausführen; Nebenläufigkeitsänderungen sind subtil

A11y-Vorschläge wirken boilerplate-artig

Skill folgt Apple HIG; mit eigenen Labels verfeinern

Alternativen

Axiom (xOS Dev Skills) vs. andere

AlternativeWann stattdessenKompromiss
AvdLee Swift Concurrency SkillNur Nebenläufigkeit, kein breiteres Bundle gewünschtEnger
Apples eigenes Swift MigratorApple-gesegnete Migration gewünschtWeniger interaktiv; weniger projekt-bewusst
twostraws SwiftUI Agent SkillNur SwiftUI-FokusAndere Meinungen

Mehr

Ressourcen

📖 Offizielle README auf GitHub lesen

🐙 Offene Issues ansehen

🔍 Alle 400+ MCP-Server und Skills durchsuchen