Swiftui view refactor
A curated collection of agent skills for your AI agents - engineering craft, prompt engineering, design, growth marketing, ...
npx -y skills add mouadja02/skills --skill swiftui-view-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
SwiftUI view refactor/review: layout ordering, DI, Observation, MV patterns, view models.
SKILL.md
3.6 KB, as published. Nobody here has run it
SwiftUI View Refactor
Attribution: Sourced from steipete/agent-scripts by Peter Steinberger. Originally created by @Dimillian from Dimillian/Skills (2025-12-31).
When to Use
- Refactoring SwiftUI views for consistent layout ordering and structure
- Reviewing dependency injection, Observation, and MV patterns
- Extracting subviews and organizing view model relationships
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/publiclet@State/ other stored properties- computed
var(non-view) initbody- 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, andtask/onChangefor 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
bodygrows beyond a screen or has multiple logical sections, split it into smaller subviews. - Extract large computed view properties into dedicated
Viewtypes when they carry state or complex branching. - Prefer passing small inputs (data, bindings, callbacks) over reusing the entire parent view state.
// ✅ Extracted sections
var body: some View {
VStack(alignment: .leading, spacing: 16) {
HeaderSection(title: title, isPinned: isPinned)
DetailsSection(details: details)
ActionsSection(onSave: onSave, onCancel: onCancel)
}
}
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'sinit.
// ✅ Observation-based view model
@State private var viewModel: SomeViewModel
init(dependency: Dependency) {
_viewModel = State(initialValue: SomeViewModel(dependency: dependency))
}
5) Observation usage
- For
@Observablereference types, store them as@Statein the root view. - Pass observables down explicitly as needed; avoid optional state unless required.
Workflow
- Reorder the view to match the ordering rules.
- Favor MV: move lightweight orchestration into the view using
@State,@Environment,@Query,task, andonChange. - If a view model exists, replace optional view models with a non-optional
@Stateview model initialized ininit. - Confirm Observation usage:
@Statefor root@Observableview models, no redundant wrappers. - Keep behavior intact: do not change layout or business logic unless requested.
Notes
- Prefer small, explicit helpers over large conditional blocks.
- Keep computed view builders below
bodyand non-view computed vars aboveinit.