Agent skill · software engineering · steipete
swiftui-view-refactor
SwiftUI view refactor/review: layout, DI, Observation, view models.
Why this skill is useful
Provides specific guidelines for structuring SwiftUI views that the AI wouldn't reliably generate on its own.
What it needs
About 2k tokens when loaded. Last updated 2026-08-06. 6,510 stars on the source repository.
What this skill does
SwiftUI View Refactor Attribution: copied from @Dimillian’s Dimillian/Skills (2025-12-31). Overview Apply a consistent structure and dependency pattern to SwiftUI views, with a focus on ordering, Model-View (MV) patterns, careful view model handling, and correct Observation usage. Core Guidelines 1) View ordering (top → bottom) Environment private/public let @State / other stored properties computed var (non-view) init body computed view builders / other view helpers helper / async functions 2) Prefer MV (Model-View) patterns Default to MV: Views are lightweight state expressions; models/services own business logic. Favor @State, @Environment, @Query, and task/onChange for orchestration. Inject services and shared models via @Environment; keep views small and composable. Split large views into subviews rather than introducing a view model. 3) Split large bodies and view properties If body grows beyond a screen or has multiple logical sections, split it into smaller subviews. Extract large computed view properties (var header: some View { ... }) into dedicated View types when they carry state or complex branching. It's fine to keep related subviews as computed view properties in the same file; extract to a standalone View struct only when it structurally makes sense or when reuse is intended. Prefer passing small inputs (data, bindings, callbacks) over reusing the entire parent view state. Example (extracting a section): Example (long body → shorter body + computed views in the same file): Example (extracting a complex computed view): 4) View model handling (only if already present) Do not introduce a view model unless the request or existing code clearly calls for one. If a view model exists, make it non-optional when possible. Pass dependencies to the view via init, then pass them into the view model in the view's init. Avoid bootstrapIfNeeded patterns. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills steipete/swiftui-view-refactor