iOS Architect

Keep token usage low by loading only the references needed for the current request.

Load Strategy

1. Always read references/intake.md first.
2. Read only the references relevant to the build type:

New app from scratch

• references/new-app-scaffold.md
• references/feature-scaffold.md
• references/database-and-migrations.md
• references/testing-concurrency-di.md
• If screenshots or UI/snapshot testing: references/screenshots.md

New feature

• references/feature-scaffold.md
• If persistence changes: references/database-and-migrations.md
• If tests/concurrency concerns: references/testing-concurrency-di.md
• If screenshots or UI/snapshot testing: references/screenshots.md

New cross-domain shared service or model

• references/testing-concurrency-di.md
• If DB-backed: references/database-and-migrations.md

New database migration

• references/database-and-migrations.md

New local SPM package

• references/new-app-scaffold.md
• references/testing-concurrency-di.md

Do not bulk-load all references when the task is narrow.

Cross-Skill Handoffs

• If custom UI components, theming, or Liquid Glass styling → use the ios-design-system skill.
• If networking implementation (API client setup, token management, retry/offline), navigation/routing overhaul, privacy audit, or on-device AI → use the ios-platform skill. Feature scaffolding (Domain/Data/Presentation structure) stays in this skill.

Shared Placement Rule

• Default all model/repository/view-model ownership to the feature that uses it.
• Use Shared only for true cross-domain capabilities consumed by at least two domains/features (e.g. Settings).
• Keep shared capabilities domain-scoped (Shared/Settings/...) with their own Domain/Data/Presentation split.
• Never create catch-all buckets such as Shared/Models or Shared/Data.

Execution Contract

1. Run intake first (build type, name, flow, fields, data source, integrations, test scope).
   • If the user does not answer intake questions (e.g., non-interactive context), state safe defaults and proceed to generation immediately. Never stop at intake.
2. Generate ALL three layers for every feature — Domain, Data, AND Presentation:
   • Domain — model struct(s) + repository protocol
   • Data — repository implementation (+ records if persistence is used)
   • Presentation — at least one ViewModel (@Observable @MainActor) AND at least one SwiftUI View that consumes it
   • Skipping the Presentation layer is never acceptable. Every feature must have a working View + ViewModel.
   • Keep each layer in the owning feature by default; only promote to shared for proven cross-domain reuse.
3. For new-app scaffolds: generate Tuist config AND app code (entry point, root navigation, first feature with all three layers) in the same response. Never stop after emitting only project configuration files.
4. Use modern APIs (@Observable, @MainActor, Swift Concurrency, Swift Testing).
5. Validate generated output:
   • New Tuist app: tuist generate + one build
   • Feature/module changes: targeted build/tests
6. Report created files, validations run, and assumptions.

Sister Skills

• ios-design-system — design tokens, UI components, Liquid Glass styling
• ios-platform — networking, navigation, privacy, Foundation Models