- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
30 lines
1.5 KiB
Markdown
30 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.
|
|
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 `workspaces/fidelity/project-knowledge/03-context/ios/current-practices.md` for currentness rules.
|
|
3. Read `workspaces/fidelity/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.
|