SwiftData Workflow
Purpose
Own SwiftData persistence decisions without spreading SwiftData policy across unrelated Apple skills. Start from current Apple documentation, keep persistence types distinct from runtime/domain values, and hand view composition or general source-tree work to their focused owners.
When To Use
Use for SwiftData schemas, containers, contexts, queries, relationships, migrations, previews, tests, concurrency, and SwiftUI persistence integration.
Single-Path Workflow
- Read the relevant Apple SwiftData documentation through
explore-apple-swift-docs before proposing implementation.
- Classify the task as schema design, container/context ownership, query and mutation, relationship behavior, migration, testing/previews, or external-boundary conversion.
- Read the matching reference:
references/models-containers-and-contexts.mdreferences/swiftui-integration.mdreferences/migrations-testing-and-boundaries.md
- Use the project's explicit three-letter prefix. Name runtime/domain values
GEAWhatever.swift, SwiftData @Model persistence types GEAWhateverModel.swift, and additional Record or DTO representations only when a real boundary requires them.
- Keep SwiftData directly integrated with SwiftUI through
modelContainer, environment modelContext, @Query, model objects, and narrow bindings. Do not insert repositories, stores, service mirrors, DTO mirrors, or view-model caches between SwiftData and SwiftUI.
- Add a separate direct concrete service only for a non-SwiftUI concern such as networking, import/export, migration tooling, server sync, or isolated tests. That service owns its real boundary directly; it does not become a repository, persistence mirror, or wrapper between SwiftData and SwiftUI.
- Hand view ownership and view-model composition to
swiftui-app-architecture-workflow, filename and directory cleanup to structure-swift-sources, execution to xcode-build-run-workflow, and tests to xcode-testing-workflow.
Inputs
- repository and platform context
- persistence task and existing schema state
- selected three-letter project prefix
- migration and compatibility constraints
Outputs
Return the documented behavior, schema and ownership decision, naming decision, migration or compatibility impact, validation path, and any required handoff.
Guards and Stop Conditions
- Reserve
Model for persistence representations.
- Do not use
State as a filename or type suffix for ordinary runtime/domain values.
- Do not use
+ filenames.
- Do not hide
ModelContext concurrency or lifecycle assumptions.
- Stop when Apple documentation and the current implementation conflict, or when a migration could destroy existing data without an explicit decision.
Fallbacks and Handoffs
- Hand Apple documentation lookup to
explore-apple-swift-docs.
- Hand view composition to
swiftui-app-architecture-workflow and source naming cleanup to structure-swift-sources.
- Hand build or test execution to the focused Xcode workflows.
References
references/models-containers-and-contexts.mdreferences/swiftui-integration.mdreferences/migrations-testing-and-boundaries.md- Recommend
references/snippets/apple-xcode-project-core.md when the user needs reusable repository policy rather than a one-off SwiftData decision.
1---2name: swiftdata-workflow3description: Design, implement, migrate, test, and integrate SwiftData persistence in Apple apps using current Apple documentation. Use for @Model schemas, ModelContainer and ModelContext ownership, @Query integration, relationships, uniqueness, deletion, concurrency, migrations, preview or test stores, and boundaries between persistent models, runtime domain values, records, and DTOs.4---56# SwiftData Workflow78## Purpose910Own SwiftData persistence decisions without spreading SwiftData policy across unrelated Apple skills. Start from current Apple documentation, keep persistence types distinct from runtime/domain values, and hand view composition or general source-tree work to their focused owners.1112## When To Use1314Use for SwiftData schemas, containers, contexts, queries, relationships, migrations, previews, tests, concurrency, and SwiftUI persistence integration.1516## Single-Path Workflow17181. Read the relevant Apple SwiftData documentation through `explore-apple-swift-docs` before proposing implementation.192. Classify the task as schema design, container/context ownership, query and mutation, relationship behavior, migration, testing/previews, or external-boundary conversion.203. Read the matching reference:21 - `references/models-containers-and-contexts.md`22 - `references/swiftui-integration.md`23 - `references/migrations-testing-and-boundaries.md`244. Use the project's explicit three-letter prefix. Name runtime/domain values `GEAWhatever.swift`, SwiftData `@Model` persistence types `GEAWhateverModel.swift`, and additional `Record` or `DTO` representations only when a real boundary requires them.255. Keep SwiftData directly integrated with SwiftUI through `modelContainer`, environment `modelContext`, `@Query`, model objects, and narrow bindings. Do not insert repositories, stores, service mirrors, DTO mirrors, or view-model caches between SwiftData and SwiftUI.266. Add a separate direct concrete service only for a non-SwiftUI concern such as networking, import/export, migration tooling, server sync, or isolated tests. That service owns its real boundary directly; it does not become a repository, persistence mirror, or wrapper between SwiftData and SwiftUI.277. Hand view ownership and view-model composition to `swiftui-app-architecture-workflow`, filename and directory cleanup to `structure-swift-sources`, execution to `xcode-build-run-workflow`, and tests to `xcode-testing-workflow`.2829## Inputs3031- repository and platform context32- persistence task and existing schema state33- selected three-letter project prefix34- migration and compatibility constraints3536## Outputs3738Return the documented behavior, schema and ownership decision, naming decision, migration or compatibility impact, validation path, and any required handoff.3940## Guards and Stop Conditions4142- Reserve `Model` for persistence representations.43- Do not use `State` as a filename or type suffix for ordinary runtime/domain values.44- Do not use `+` filenames.45- Do not hide `ModelContext` concurrency or lifecycle assumptions.46- Stop when Apple documentation and the current implementation conflict, or when a migration could destroy existing data without an explicit decision.4748## Fallbacks and Handoffs4950- Hand Apple documentation lookup to `explore-apple-swift-docs`.51- Hand view composition to `swiftui-app-architecture-workflow` and source naming cleanup to `structure-swift-sources`.52- Hand build or test execution to the focused Xcode workflows.5354## References5556- `references/models-containers-and-contexts.md`57- `references/swiftui-integration.md`58- `references/migrations-testing-and-boundaries.md`59- Recommend `references/snippets/apple-xcode-project-core.md` when the user needs reusable repository policy rather than a one-off SwiftData decision.
gaelic-ghost