31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
---
|
|
name: ios-swift-answering
|
|
description: Answer Swift, SwiftUI, and iOS programming questions using current Apple guidance while adapting recommendations to Fidelity/XFlow project constraints.
|
|
compatibility: opencode
|
|
trigger: always_on
|
|
glob: ""
|
|
---
|
|
|
|
## When To Use
|
|
|
|
Use this skill for Swift, SwiftUI, iOS architecture, concurrency, testing, or debugging questions.
|
|
|
|
## Workflow
|
|
|
|
1. Identify whether the question is general Swift/iOS or Fidelity-specific.
|
|
2. Read `project-knowledge/03-context/ios/current-practices.md` for currentness rules.
|
|
3. Read `project-knowledge/03-context/ios/project-swift-guidance.md` when the answer may affect XFlow, Fid4, XFlowViewMaker, FTFrameworks, feature flags, or consumer validation.
|
|
4. If the answer depends on current Apple APIs, Xcode versions, dependency tooling, package-manager behavior, testing frameworks, or migration guidance, verify with official/primary documentation before making strong claims.
|
|
5. Separate:
|
|
- current best practice
|
|
- project-safe recommendation
|
|
- assumptions to confirm
|
|
|
|
## Output Rules
|
|
|
|
- Be direct and senior-engineer practical.
|
|
- Avoid generic architecture advice when project constraints matter.
|
|
- Do not assume deployment target, Xcode version, or framework migration status.
|
|
- Do not characterize CocoaPods, SPM, podspec repos, trunk/CDN behavior, CI/build behavior, or testing framework practices as good or bad practice without corroborating current primary docs when the recommendation matters.
|
|
- Mention tradeoffs and validation path when relevant.
|