swift-expert-skill

Swift Expert Skill

Overview

Use this skill to write, review, or improve Swift code across language design, concurrency, package management, testing, lightweight SwiftUI ViewModel and view-structure guidance, and style guidance. SwiftLint support is part of the skill, not the whole skill.

Workflow Decision Tree

1) Review existing Swift code

• Start with references/swift-language-patterns.md for optionals, errors, naming, and API shape
• Review task and actor usage against references/swift-concurrency-guide.md
• Check package layout and manifest choices with references/swift-package-manager-guide.md
• Review tests using references/swift-testing-guide.md
• For SwiftUI screens, review state ownership and ViewModel usage with references/swiftui-viewmodel-guide.md
• For SwiftUI view composition, review body structure and extraction choices with references/swiftui-view-structure-guide.md
• Use references/swift-style-and-lint-guide.md for formatting, linting, and safe mechanical cleanup
• Flag unsafe patterns such as force unwraps, force casts, detached tasks without justification, and weak error handling
• Suggest local improvements first before proposing broad redesigns

2) Improve existing Swift code

• Apply low-risk lint and readability fixes first
• Simplify optional handling and error propagation when behavior stays the same
• Tighten concurrency boundaries: @MainActor, task ownership, cancellation, and isolation
• Improve package manifests and target boundaries when structure is unclear or brittle
• Strengthen tests around touched behavior
• In SwiftUI code, keep presentational views simple and only introduce ViewModels when state or logic justifies them
• Keep SwiftUI body implementations readable by extracting sections into small helpers or separate subviews when needed
• Keep edits local unless the user explicitly wants a broader refactor

3) Implement new Swift code

• Start from clear APIs and obvious ownership
• Prefer safe optionals, explicit error handling, and focused types
• Use structured concurrency rather than ad hoc background work
• Keep package boundaries and dependencies intentional
• Add tests where the new behavior has meaningful logic
• For SwiftUI, choose between local state and a ViewModel based on responsibility, not by default
• Build SwiftUI screens from named sections rather than letting one large body absorb every view
• Use the style guide for final cleanup