spine-platform-swift

Use when implementing Clean Architecture in iOS apps. Covers Domain/Data/Presentation layers, Use Cases, Repository pattern, DTOs, dependency rule, and testing each layer.

Use when implementing Coordinator navigation pattern in iOS apps. Covers child coordinator lifecycle, Router abstraction, deep linking, tab bar coordination, and communication patterns. Uses Factory pattern for module assembly — see di-module-assembly skill for full Factory details.

Use when implementing classic Apple MVC (Model-View-Controller) in iOS apps. Covers component responsibilities, communication patterns (target-action, delegate, NotificationCenter), Massive ViewController anti-pattern, when MVC is appropriate, and migration paths to MVVM or VIPER.

Use when implementing MVI (Model-View-Intent) architecture pattern in iOS apps. Covers Pure MVI (Intent/State/Reducer) and MVVM+Single State (MVI-like) variants, side-effect handling, Combine + @Observable patterns, and testing. Framework-agnostic — TCA is a specific implementation, see arch-tca.

Use when implementing MVVM (Model-View-ViewModel) architecture pattern in iOS apps. Covers ViewModel design, UI binding with multiple approaches (Closures, Combine, async/await, @Observable, RxSwift), Input/Output pattern, and testing.

Use when implementing navigation in a SwiftUI-first iOS app. Covers NavigationStack + NavigationPath, type-based vs enum-based routing, modal presentation (sheet/cover/popover/alert), TabView, Router class pattern as a SwiftUI alternative to Coordinator, @Environment-based navigation, deep links, and hybrid SwiftUI ↔ UIKit interop.

Use when implementing The Composable Architecture (TCA, swift-composable-architecture by Point-Free) in SwiftUI apps. Covers Reducer/State/Action, Effects, dependencies (@Dependency), the modern @Reducer + @ObservableState observation API, store scoping, navigation (@Presents, StackState/StackAction), bindings, side effects/cancellation, exhaustive vs non-exhaustive TestStore, when TCA is appropriate, and TCA-specific anti-patterns.

Use when implementing VIPER architecture pattern in iOS apps. Covers View, Interactor, Presenter, Entity, Router components, Assembly wiring, and testing.

Use at project bootstrap or major refactor to pick the iOS/macOS architecture stack. Compass-style: 5 input axes (team size, lifetime, domain complexity, UI framework, testing rigor) → one reference stack (MVC, MVVM with a Coordinator or a Router, Hybrid UIKit+SwiftUI, Clean Architecture, VIPER, MVI, TCA). Points to detailed skills, doesn't replace them.

Use when deciding where Swift Concurrency primitives live in a layered iOS app — which layer is @MainActor (View/ViewModel/Presenter/Coordinator/Service/Repository), when to introduce a custom actor, who owns Tasks and where they get cancelled, how cancellation propagates across Coordinator → ViewModel → UseCase → Repository → APIClient, where to place async let / TaskGroup (UseCase vs ViewModel), Sendable boundaries between layers, and background-work-outlives-screen patterns. Architectural placement only — defer language-level questions (actor reentrancy, isolation rules, Sendable conformance, Swift 6 migration) to swift-concurrency:swift-concurrency.

Use when designing where and how an app's object graph is wired — SceneDelegate / AppDelegate / @main App. Covers what belongs in Composition Root (CR), what doesn't, sync vs async bootstrap, scope strategies (app/scene/flow), and testing. DI-framework agnostic.

Use when working with the Factory DI library by hmlongco (FactoryKit) in iOS/macOS apps — registration, property-wrapper injection, scopes, modular containers, contexts, and testing. For Composition Root see di-composition-root; for Coordinator wiring see di-module-assembly.

Use when assembling UI modules (MVVM/MVVM+Coordinator), creating CoordinatorFactory/ModuleFactory, wiring View+ViewModel. Covers Factory pattern that connects DI container with Coordinators without Service Locator. Also covers non-UI factories and late/conditional initialization patterns.

Use when working with Swinject dependency injection in iOS apps. Covers Swinject-specific patterns: object scopes, registrations (basic, autoregister, named, with arguments), Assembly pattern, testing configuration. For Composition Root design see di-composition-root skill; for connecting DI to Coordinators see di-module-assembly skill.

Use when designing how errors flow through a layered iOS app — typed vs untyped errors (Swift 6 typed throws), per-layer error types, mapping between layers (Network → Domain → UI), presentation strategy (alert/inline/banner/empty-state/log), recoverable vs fatal classification, localization, PII-safe logging, retry/cancellation, and reactive-framework error handling.

Platform manifest for spine-platform-swift. Data, not instructions — the five required tables spine-toolkit reads to bind roles, axes, heuristics, topics and entrypoints, and the Driver table this platform declares.

Use when wiring deep links / universal links into an iOS or macOS app — choosing custom URL scheme vs Universal Links vs App Links, Associated Domains entitlement and apple-app-site-association, the architecture-agnostic URL → typed Route parser, every entry point (onOpenURL / application(_:open:) / NSUserActivity / push payload / UNNotificationResponse / Quick Actions / widgets / Spotlight), deferred deep links, cold-start buffering behind auth/onboarding gates, and testing. This skill owns the URL→Route mechanics; it hands the Route to the navigation layer (see arch-coordinator / arch-swiftui-navigation for how a Route reaches a screen).

Use when designing the networking layer of an iOS app — HTTPClient protocol behind framework choice (URLSession/Alamofire/Moya/Get), endpoint design, auth interceptors with token refresh, retry policies (idempotency-aware), pagination patterns, cancellation propagation, multipart/background URLSession, WebSocket/SSE, HTTP-level vs Repository-level caching, framework comparison, mock/stub testing strategies.

Use when generating a Swift API client from an OpenAPI spec — Apple's swift-openapi-generator (SPM plugin), generated types/operations/middleware, transports (URLSession / AsyncHTTPClient), wrapping the generated Client in your own APIClient protocol, error mapping from generated Output enums to domain errors, mocking the generated client, server-side stubs, alternatives (CreateAPI, openapi-generator-cli).

Use when designing local data storage in an iOS app — choosing between Core Data, SwiftData, GRDB/SQLite, Realm, UserDefaults, file storage; Repository as the boundary that hides the framework; background contexts and threading; reactive queries; write patterns and conflict handling; CloudKit sync; encryption / file protection; in-memory testing strategies. For schema migrations see `persistence-migrations`.

Use when designing or shipping a schema migration in an iOS app — Core Data lightweight vs heavyweight + NSEntityMigrationPolicy, SwiftData VersionedSchema/MigrationStage, GRDB DatabaseMigrator, Realm migration block; transformable Codable payloads (evolutionary / lazy / proactive / envelope); progressive multi-step migrations; long-migration UX and atomic backup; failure recovery and telemetry; fixture-based migration tests; Codable snapshot tests.

Use when designing or reviewing Swift Package boundaries — what is public, what is internal, how the package gets its dependencies, and how the host app integrates it. Covers 4 package archetypes (Feature / Library / API-Contract / Engine-SDK) with per-type rules. DI-framework agnostic.

Use when working with Apple's Combine framework — a binding/event-stream tool, not an architecture. Covers publishers, subscribers, subjects, operators, UIKit/SwiftUI integration, ViewModel binding patterns, and testing. Architecture is chosen separately (see arch-mvvm / arch-clean / arch-tca).

Use when working with RxSwift — a binding/event-stream tool, not an architecture. Covers observables, operators, memory management, Driver/Signal UI bindings, ViewModel binding patterns, and testing with RxTest/RxBlocking. Architecture is chosen separately (see arch-mvvm / arch-clean / arch-viper).

Use when a spine-toolkit methodology skill (ops-checklist / feature-requirements / feature-estimation) resolves topic release ops for an Apple project — App Store / TestFlight review, push transport (APNs), crash reporting, Keychain-backed secure storage, transport security, VoiceOver/Dynamic Type accessibility specifics, and the release-review estimation buffer.

Platform half of project setup for Swift/Apple projects. Asks the stack questions of spine-platform-swift's manifest axes and writes the ## Stack and ## Modules blocks of an existing CLAUDE-spine-toolkit.md. Invoked by spine-toolkit:setup, which owns the config file and every other block; not invoked by the user directly. Use when (en): spine-toolkit:setup hands the platform its own config blocks Use when (ru): spine-toolkit:setup передаёт платформе её блоки конфига

Data for whoever writes or reads a test on this platform — one section per value of the manifest's `tests` axis (XCTest, Swift Testing, Quick+Nimble) and the surfaces that force a framework whatever the axis says. Which value a given file takes is decided by `spine-toolkit:test-authoring`; this skill says what that value looks like in code and in a failing run.

Add a new package or incorporate an existing standalone package into the workspace. Use when (en): "add package", "incorporate package", "/workspace-add", "ws add" Use when (ru): "добавь пакет", "включи пакет", "/workspace-add", "пакет в workspace"

Regenerate the marker-delimited sections of workspace docs and the workspace files. Use when (en): "regen docs", "refresh workspace docs", "/workspace-docs-regen" Use when (ru): "обнови docs", "регенерация docs", "/workspace-docs-regen"

Bootstrap a new multi-package SPM workspace. Use when (en): "init workspace", "create workspace", "bootstrap multi-package", "/workspace-init" Use when (ru): "создай workspace", "новый workspace", "инициализируй workspace", "/workspace-init"