By name: swiftui-feature-builder description: Plan and implement SwiftUI, iOS, iPadOS, or macOS features with clean architecture, state ownership, accessibility, tests, and verification. Use when asked to build or modify an Apple app feature.
SwiftUI Feature Builder
Use this workflow to plan and implement Apple app features without large unreviewed rewrites. Prefer existing project patterns and keep changes scoped.
References
- Read
references/feature-planning-checklist.mdbefore planning. - Read
references/swiftui-component-guidelines.mdbefore changing SwiftUI view structure. - Use
references/output-contract.mdfor final reporting.
Prefer targeted search, project maps, and bundled scripts before reading many files.
Workflow
- Understand the requested feature and success criteria.
- Inspect project structure, entry points, models, view state, and existing tests.
- Identify the smallest set of files to edit.
- Plan state ownership, data flow, navigation, async work, and persistence boundaries.
- For Liquid Glass or iOS 26-only UI work, confirm the deployment target and iOS 17 fallback strategy before implementation.
- Implement small changes with clear verification checkpoints.
- Add accessibility labels, traits, Dynamic Type behavior, and keyboard or pointer support where relevant.
- Add focused tests when project structure supports them.
- Verify build, tests, or static checks when safe.
- Summarize changes, tests, verification, and follow-up improvements.
Guardrails
- Avoid huge rewrites unless the user explicitly asks and the risk is documented.
- Do not move business logic into SwiftUI views.
- Do not introduce new architecture patterns when the existing project has a clear one.
- Do not build, run, or capture screens when the user has not approved that workflow.
- Do not silently remove iOS 17 support when adding Liquid Glass or iOS 26 UI. Ask whether to keep the iOS 17 UI path, build a separate non-glass fallback, or intentionally raise the minimum OS.
Output
Use references/output-contract.md.