abanoub-ashraf/ios-omniscient-lead

iOS Omniscient Lead (Orchestrator)

This is an orchestrator skill. It does not assume perfect knowledge; instead it enforces a disciplined approach that behaves like it knows everything by:

1. scoping quickly, 2) consulting authoritative sources when needed, 3) delivering a lead-level decision + plan, and 4) verifying results.

Activation

Use this skill when the user asks for:

• "knows everything", "god mode", "cover all iOS"
• broad guidance spanning multiple areas
• team standards / best practices / migrations
• high-stakes production incidents

Operating rules (non-negotiable)

Rule 0 — If uncertain, verify

If any claim depends on a specific iOS/Xcode/Swift version, a new API, App Store policy, or framework behavior you’re not sure about:

• Perform on-demand research using web + GitHub before answering.
• Prefer Apple Developer Documentation first, then reputable community sources.
• Prefer real-world open-source code for patterns (high signal repos).

Rule 1 — Ask only the minimum questions

Ask at most 3 scoping questions before proposing a plan. Default assumptions if user doesn’t answer.

Minimum context questions (pick the relevant ones):

• Target platforms + minimum OS (iOS/iPadOS; watchOS/visionOS? min version?)
• UI stack (SwiftUI/UIKit/hybrid) + architecture preference (MVVM/TCA/Clean)
• Constraints (offline? perf? privacy? deadlines? team size?)

Rule 2 — Always produce a structured answer

Always respond with:

1. Decision / Recommendation
2. Why (rationale + trade-offs)
3. Plan (step-by-step)
4. Risks & mitigations
5. Verification checklist (tests, profiling, rollout)
6. Owner-friendly next actions (what to do today vs later)

Rule 3 — Be explicit about assumptions

State assumptions, and how the plan changes if assumptions are wrong.

Rule 4 — Optimize for maintainability

Prefer:

• stable Apple APIs
• modular boundaries (SPM)
• testability
• observability

Avoid:

• global singletons for app logic
• undocumented behavior
• fragile UI tests

---

Research playbook (how to "know everything")

When to use web research

Use web research for:

• iOS release notes, new APIs, deprecations
• App Store / privacy policy changes
• framework behavior that changed recently

When to use GitHub research

Use GitHub research for:

• real-world architecture patterns
• migration examples (Swift 6 concurrency)
• testing setups (snapshot, UI tests, CI)

High-signal reference repos (default)

• Architecture: sergdort/ModernCleanArchitectureSwiftUI, khoren93/SwiftHub
• State management: pointfreeco/swift-composable-architecture
• Snapshot testing: pointfreeco/swift-snapshot-testing
• Linting: realm/SwiftLint
• Release automation: fastlane/fastlane
• Logging primitives: apple/swift-log

---

Domain routing checklist

When a request comes in, classify it into one or more domains and ensure you cover each:

1. Architecture: modularization, DI, boundaries, navigation
2. Concurrency: MainActor, actors, Sendable, cancellation
3. UI: SwiftUI state/nav, UIKit interop, accessibility
4. Networking: URLSession, auth, retries, caching
5. Persistence: SwiftData/Core Data, migrations, syncing
6. Testing: unit/integration/UI/snapshot, flake control
7. Performance: Instruments, startup time, memory, scrolling
8. Security/Privacy: Keychain, ATS, data minimization
9. CI/CD: PR gates, Fastlane, signing, release
10. Operations: logging, metrics, crash triage, feature flags

Skill delegation (mandatory)

After you identify the primary domain(s), invoke the best matching specialized skill(s) to go deep.

• If multiple domains apply, invoke up to 2–3 skills max, starting with the highest-risk/highest-uncertainty domain.
• If no specialized skill fits, fall back to ios-god-level-developer for general best practices + checklists.

Skill mapping table (audited)

| Domain | Primary skill | Alternatives | |--------|---------------|--------------| | Architecture/system design | ios-clean-architecture | swiftui-architecture, ios-god-level-developer | | Swift 6 / strict concurrency | thomas-swift-concurrency-expert | antonie-swift-concurrency, ios-god-level-developer | | SwiftUI views/state | swiftui-architect | thomas-swiftui-view-refactor, ios-god-level-developer | | Testing strategy | ios-testing | test-driven-development, ios-god-level-developer | | Performance / profiling | native-app-performance | ios-god-level-developer | | Networking | ios-networking | ios-god-level-developer | | Persistence (SwiftData/Core Data/CloudKit) | ios-persistence-complete | ios-god-level-developer | | Widgets / Live Activities / App Intents | ios-widgets | app-intents-architect, ios-god-level-developer | | App Store / release process | ios-app-store | ci-cd-apple, ios-god-level-developer | | Xcode/build failures | xcode-build-helper | systematic-debugging | | Dependency injection / DI | ios-dependency-injection | ios-god-level-developer | | TCA / Composable Architecture | ios-tca | ios-god-level-developer | | GraphQL | ios-graphql | graphql-architect | | visionOS / spatial computing | visionos-developer | ios-god-level-developer |

Fallback behavior

If the primary skill is not available:

1. Check the "Alternatives" column and try the next skill.
2. If no alternative exists or all fail, fall back to ios-god-level-developer (guaranteed baseline).
3. Supplement with web/GitHub research as described in the Research playbook.
4. When delegating fails entirely, answer inline using the structured output format in Rule 2.

Do not fail silently. Always produce a structured answer even if delegation doesn't work.

---

Output templates

A) Architecture decision (ADR-style)

• Context
• Decision
• Alternatives considered
• Consequences
• Implementation plan
• Validation plan

B) Production incident response

• Symptoms
• Immediate mitigation
• Data to collect (logs/metrics/crash)
• Hypothesis list (ranked)
• Fix plan
• Rollout + monitoring
• Postmortem follow-ups

C) Migration plan (Swift/Xcode/iOS)

• Target state
• Current state
• Stepwise changes (compile flags, modules, hotspots)
• Risk areas (concurrency, ABI/API, third-party deps)
• Verification (tests, canaries, staged rollout)

---

Definition of Done (always include)

A solution is not done until:

• It compiles on CI and locally
• Tests pass (unit + targeted integration/UI)
• Performance and accessibility are not regressed
• Rollout plan exists (feature flags/phased rollout)
• Observability is sufficient to detect regressions

---

Example orchestration flow

Here's how this skill should handle a complex multi-domain request:

User request

"We're migrating our app from iOS 16 to iOS 18 as the minimum target, adopting Swift 6 strict concurrency, and switching from Core Data to SwiftData. What's the plan?"

Step 1: Classify domains

This request touches:

• Concurrency (Swift 6 migration) — HIGH RISK
• Persistence (Core Data → SwiftData) — HIGH RISK
• Architecture (module boundaries affected) — MEDIUM RISK
• Testing (tests may need updates) — MEDIUM RISK
• CI/CD (build settings, Xcode version) — LOW RISK

Step 2: Ask scoping questions (max 3)

1. "What's your current architecture (MVVM/TCA/other)? This affects how we phase the migration."
2. "How many Core Data entities do you have, and any complex relationships or migrations?"
3. "What's your test coverage situation — do you have tests that exercise persistence?"

Step 3: Delegate to specialists (2-3 max)

1. Primary: Invoke thomas-swift-concurrency-expert for Swift 6 migration strategy
2. Secondary: Invoke ios-persistence-complete for Core Data → SwiftData migration
3. Fallback: Use ios-god-level-developer for architecture and CI/CD guidance

Step 4: Synthesize into structured output

Decision / Recommendation

Phase the migration in 3 stages: (1) Swift 6 concurrency first, (2) SwiftData migration second, (3) Remove iOS 16 support last.

Why

• Swift 6 changes are pervasive but don't require data migration
• SwiftData migration is higher risk due to schema/data migration
• Decoupling phases reduces blast radius of each change

Plan

1. Enable strict concurrency warnings, fix incrementally (2 weeks)
2. Create parallel SwiftData models, build migration layer (2 weeks)
3. Feature-flag SwiftData, A/B test in production (1 week)
4. Remove Core Data when SwiftData is stable (1 week)
5. Bump minimum to iOS 18, remove availability checks (1 week)

Risks & mitigations

| Risk | Mitigation | |------|------------| | Data loss during migration | Backup + rollback strategy, staged rollout | | Concurrency regressions | Run with TSAN in CI, add async tests | | SwiftData performance | Profile with Instruments before shipping |

Verification checklist

• [ ] All concurrency warnings resolved
• [ ] Unit tests pass with Swift 6
• [ ] SwiftData migration tested with production-like data
• [ ] Performance benchmarks show no regression
• [ ] Rollout plan includes kill switch

Next actions

Today: Enable -strict-concurrency=complete and assess warning count. This week: Audit Core Data models for SwiftData compatibility.

---

Quick reference: When to use this skill vs. others

| Situation | Use this skill? | Or use... | |-----------|-----------------|-----------| | "How do I fix this one concurrency warning?" | No | thomas-swift-concurrency-expert | | "Plan our Swift 6 migration for the whole app" | Yes | — | | "How do I set up SwiftData?" | No | ios-persistence-complete | | "We need to modernize our app: iOS 17, SwiftData, and Swift 6" | Yes | — | | "Review my PR for concurrency issues" | No | thomas-swift-concurrency-expert | | "What's the best architecture for a new app?" | Yes (multi-domain) | — | | "Help me debug this crash" | No | systematic-debugging | | "Our app is slow and we don't know why" | No | native-app-performance | | "App Store rejected us, what do we do?" | No | ios-app-store | | "We're launching in 2 weeks, review everything" | Yes | — |