New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Swiftui View Refactor

by Dimillian in Dimillian/Skills

Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage.

MITAuto-check passedDevelopment

Install Swiftui View Refactor

skills CLI
$ npx skills add Dimillian/Skills --skill swiftui-view-refactor -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Dimillian/Skills swiftui-view-refactor --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Dimillian/Skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/swiftui-view-refactor .claude/skills/swiftui-view-refactor && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
swiftui-view-refactor
GitHub stars
4k
Used in
5 other repos
Token cost
~2k tokens
SKILL.md length
763 words
Files
3 (incl. references)
Skills in repo
12
Repo updated
First seen
Licence
MIT

At a glance

Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage.

  • Works in 6 steps: View ordering (top → bottom) → Default to MV, not MVVM → Strongly prefer dedicated subview types… → …
  • Cleaning up a SwiftUI view
  • SKILL.md covers Overview, Core Guidelines, Workflow and Notes, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Swiftui View Refactor is an agent skill from Dimillian/Skills. Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Use when cleaning up a SwiftUI view, splitting long bodies, removing inline actions or side effects, reducing computed some View helpers, or standardizing @Observable and view model initialization patterns.

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `agents/openai.yaml` and `references/mv-patterns.md`).

It sits in Development, covering Refactoring and Design patterns. It works with SwiftUI. The licence is MIT.

When your agent uses it

  • Cleaning up a SwiftUI view
  • Splitting long bodies
  • Removing inline actions
  • Reducing computed some View helpers

Example prompts

  • “/swiftui-view-refactor”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. View ordering (top → bottom)
  2. Default to MV, not MVVM
  3. Strongly prefer dedicated subview types over computed some View helpers
  4. Keep a stable view tree (avoid top-level conditional view swapping)
  5. View model handling (only if already present or explicitly requested)
  6. Observation usage

What it can do on your machine

Read from SKILL.md and the folder at commit 05ba982. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are swift).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Swiftui View Refactor loads about 2k tokens when it runs, and up to ~3.4k if it reads all its reference files. Until then it costs about 107 tokens; SKILL.md has 763 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~107
When it runs · the whole SKILL.md, loaded when a task matches
~2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Dimillian/Skills at commit 05ba982, republished under its MIT licence (© Dimillian). 763 words, ~1,989 tokens.

Download SKILL.mdSave it as .claude/skills/swiftui-view-refactor/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
swiftui-view-refactor
description
Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Use when cleaning up a SwiftUI view, splitting long bodies, removing inline actions or side effects, reducing computed `some View` helpers, or standardizing `@Observable` and view model initialization patterns.

SwiftUI View Refactor

Overview

Refactor SwiftUI views toward small, explicit, stable view types. Default to vanilla SwiftUI: local state in the view, shared dependencies in the environment, business logic in services/models, and view models only when the request or existing code clearly requires one.

Core Guidelines

1) View ordering (top → bottom)
  • Enforce this ordering unless the existing file has a stronger local convention you must preserve.
  • Environment
  • private/public let
  • @State / other stored properties
  • computed var (non-view)
  • init
  • body
  • computed view builders / other view helpers
  • helper / async functions
2) Default to MV, not MVVM
  • Views should be lightweight state expressions and orchestration points, not containers for business logic.
  • Favor @State, @Environment, @Query, .task, .task(id:), and onChange before reaching for a view model.
  • Inject services and shared models via @Environment; keep domain logic in services/models, not in the view body.
  • Do not introduce a view model just to mirror local view state or wrap environment dependencies.
  • If a screen is getting large, split the UI into subviews before inventing a new view model layer.
3) Strongly prefer dedicated subview types over computed some View helpers
  • Flag body properties that are longer than roughly one screen or contain multiple logical sections.
  • Prefer extracting dedicated View types for non-trivial sections, especially when they have state, async work, branching, or deserve their own preview.
  • Keep computed some View helpers rare and small. Do not build an entire screen out of private var header: some View-style fragments.
  • Pass small, explicit inputs (data, bindings, callbacks) into extracted subviews instead of handing down the entire parent state.
  • If an extracted subview becomes reusable or independently meaningful, move it to its own file.

Prefer:

swift
var body: some View {
    List {
        HeaderSection(title: title, subtitle: subtitle)
        FilterSection(
            filterOptions: filterOptions,
            selectedFilter: $selectedFilter
        )
        ResultsSection(items: filteredItems)
        FooterSection()
    }
}

private struct HeaderSection: View {
    let title: String
    let subtitle: String

    var body: some View {
        VStack(alignment: .leading, spacing: 6) {
            Text(title).font(.title2)
            Text(subtitle).font(.subheadline)
        }
    }
}

private struct FilterSection: View {
    let filterOptions: [FilterOption]
    @Binding var selectedFilter: FilterOption

    var body: some View {
        ScrollView(.horizontal, showsIndicators: false) {
            HStack {
                ForEach(filterOptions, id: \.self) { option in
                    FilterChip(option: option, isSelected: option == selectedFilter)
                        .onTapGesture { selectedFilter = option }
                }
            }
        }
    }
}

Avoid:

swift
var body: some View {
    List {
        header
        filters
        results
        footer
    }
}

private var header: some View {
    VStack(alignment: .leading, spacing: 6) {
        Text(title).font(.title2)
        Text(subtitle).font(.subheadline)
    }
}
3b) Extract actions and side effects out of body
  • Do not keep non-trivial button actions inline in the view body.
  • Do not bury business logic inside .task, .onAppear, .onChange, or .refreshable.
  • Prefer calling small private methods from the view, and move real business logic into services/models.
  • The body should read like UI, not like a view controller.
swift
Button("Save", action: save)
    .disabled(isSaving)

.task(id: searchText) {
    await reload(for: searchText)
}

private func save() {
    Task { await saveAsync() }
}

private func reload(for searchText: String) async {
    guard !searchText.isEmpty else {
        results = []
        return
    }
    await searchService.search(searchText)
}
4) Keep a stable view tree (avoid top-level conditional view swapping)
  • Avoid body or computed views that return completely different root branches via if/else.
  • Prefer a single stable base view with conditions inside sections/modifiers (overlay, opacity, disabled, toolbar, etc.).
  • Root-level branch swapping causes identity churn, broader invalidation, and extra recomputation.

Prefer:

swift
var body: some View {
    List {
        documentsListContent
    }
    .toolbar {
        if canEdit {
            editToolbar
        }
    }
}

Avoid:

swift
var documentsListView: some View {
    if canEdit {
        editableDocumentsList
    } else {
        readOnlyDocumentsList
    }
}
5) View model handling (only if already present or explicitly requested)
  • Treat view models as a legacy or explicit-need pattern, not the default.
  • 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 create the view model in the view's init.
  • Avoid bootstrapIfNeeded patterns and other delayed setup workarounds.

Example (Observation-based):

swift
@State private var viewModel: SomeViewModel

init(dependency: Dependency) {
    _viewModel = State(initialValue: SomeViewModel(dependency: dependency))
}
Show full SKILL.md (303 more words)Show less
6) Observation usage
  • For @Observable reference types on iOS 17+, store them as @State in the owning view.
  • Pass observables down explicitly; avoid optional state unless the UI genuinely needs it.
  • If the deployment target includes iOS 16 or earlier, use @StateObject at the owner and @ObservedObject when injecting legacy observable models.

Workflow

  1. Reorder the view to match the ordering rules.
  2. Remove inline actions and side effects from body; move business logic into services/models and keep only thin orchestration in the view.
  3. Shorten long bodies by extracting dedicated subview types; avoid rebuilding the screen out of many computed some View helpers.
  4. Ensure stable view structure: avoid top-level if-based branch swapping; move conditions to localized sections/modifiers.
  5. If a view model exists or is explicitly required, replace optional view models with a non-optional @State view model initialized in init.
  6. Confirm Observation usage: @State for root @Observable models on iOS 17+, legacy wrappers only when the deployment target requires them.
  7. Keep behavior intact: do not change layout or business logic unless requested.

Notes

  • Prefer small, explicit view types over large conditional blocks and large computed some View properties.
  • Keep computed view builders below body and non-view computed vars above init.
  • A good SwiftUI refactor should make the view read top-to-bottom as data flow plus layout, not as mixed layout and imperative logic.
  • For MV-first guidance and rationale, see references/mv-patterns.md.

Large-view handling

When a SwiftUI view file exceeds ~300 lines, split it aggressively. Extract meaningful sections into dedicated View types instead of hiding complexity in many computed properties. Use private extensions with // MARK: - comments for actions and helpers, but do not treat extensions as a substitute for breaking a giant screen into smaller view types. If an extracted subview is reused or independently meaningful, move it into its own file.

© Dimillian, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (references) in swiftui-view-refactor of Dimillian/Skills.

  • SKILL.md
  • agents/openai.yaml
  • references/mv-patterns.md

Open the folder on GitHubat commit 05ba982

Used in 5 other repositories

We found 15 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 5 other GitHub owners. This page covers the copy in Dimillian/Skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Swiftui View Refactor next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Swiftui View Refactor compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Swiftui View Refactor this skillDimillian/Skills4k5 repos~2kAutomated safety check: PassMIT
Swiftui View Refactorharperreed/dotfiles3345 repos~1.3kAutomated safety check: PassNone
RTK Rust Design Patternsrtk-ai/rtk83k—~1.9kAutomated safety check: PassApache-2.0
Architecture PatternsKartikLabhshetwar/better-shot2.4k2 repos~1.4kAutomated safety check: PassCustom licence
AST Visitor Pattern for Unionsprisma/orm48k—~830Automated safety check: PassApache-2.0
Coding Best PracticesKartikLabhshetwar/better-shot2.4k2 repos~1.8kAutomated safety check: PassCustom licence

Similar skills

  • Swiftui View Refactor

    harperreed/dotfiles

    Refactor and review SwiftUI view files for consistent structure, dependency injection, and Observation usage.

    334 GitHub starsUsed in 5 repos~1.3k tokens
    DevelopmentAuto-check passed

  • RTK Rust Design Patterns

    rtk-ai/rtk

    Describes seven Rust design patterns for the RTK CLI filter modules, with when to use each, RTK examples, and notes on when a pattern is overkill.

    83k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

  • Architecture Patterns

    KartikLabhshetwar/better-shot

    Deep dive into software architecture for macOS. An agent skill from KartikLabhshetwar/better-shot.

    2.4k GitHub starsUsed in 2 repos~1.4k tokens
    DevelopmentAuto-check passed

  • AST Visitor Pattern for Unions

    prisma/orm

    Official

    Replaces a plain TypeScript union plus switch statements with frozen subclasses and a visitor interface when several places dispatch on the same variants.

    48k GitHub stars~830 tokensUpdated today
    DevelopmentAuto-check passed

  • Coding Best Practices

    KartikLabhshetwar/better-shot

    Reviews macOS Swift 6+ code for modern idioms, SOLID principles, SwiftData patterns, and concurrency best practices.

    2.4k GitHub starsUsed in 2 repos~1.8k tokens
    DevelopmentAuto-check passed

  • Solid

    ramziddin/solid-skills

    A skill your agent uses when writing code, implementing features, refactoring, planning architecture, designing systems, reviewing code, or debugging.

    606 GitHub stars~2.7k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from Dimillian/Skills

All 12 skills in this repo

  • macOS Spm App Packaging

    Dimillian/Skills

    Scaffold, build, and package SwiftPM-based macOS apps without an Xcode project.

    4k GitHub starsUsed in 5 repos~1.2k tokens
    Auto-check passed

  • React Component Performance

    Dimillian/Skills

    Analyze and optimize React component performance issues (slow renders, re-render thrash, laggy lists, expensive computations).

    4k GitHub starsUsed in 5 repos~1.2k tokens
    Auto-check passed

  • Swiftui UI Patterns

    Dimillian/Skills

    Best practices and example-driven guidance for building SwiftUI views and components, including navigation hierarchies, custom view modifiers, and responsive layouts with stacks and grids.

    4k GitHub starsUsed in 5 repos~1.9k tokens
    Auto-check passed

  • Swift Concurrency Expert

    Dimillian/Skills

    Swift Concurrency review and remediation for Swift 6.2+. An agent skill from Dimillian/Skills.

    4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Auto-check passed

  • GitHub

    Dimillian/Skills

    Interact with GitHub using the gh CLI. An agent skill from Dimillian/Skills.

    4k GitHub stars~480 tokensUpdated 6 mo ago
    Auto-check passed

  • macOS Menubar Tuist App

    Dimillian/Skills

    Build, refactor, or review macOS menubar apps that use Tuist and SwiftUI.

    4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Auto-check passed

Works with

Categories

Questions about Swiftui View Refactor

What does Swiftui View Refactor do?

Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage. Swiftui View Refactor is an agent skill from Dimillian/Skills. Refactor and review SwiftUI view files with strong defaults for small dedicated subviews, MV-over-MVVM data flow, stable view trees, explicit dependency injection, and correct Observation usage.

When should I use Swiftui View Refactor?

Swiftui View Refactor fits situations like: cleaning up a SwiftUI view; splitting long bodies; removing inline actions; reducing computed some View helpers.

How do I install Swiftui View Refactor in Claude Code?

Run `npx skills add Dimillian/Skills --skill swiftui-view-refactor -a claude-code`. Or copy the skill folder (swiftui-view-refactor in Dimillian/Skills) into .claude/skills/swiftui-view-refactor in your project. Claude Code loads it when a task matches its description.

How do I install Swiftui View Refactor in Codex?

Run `npx skills add Dimillian/Skills --skill swiftui-view-refactor -a codex`. Or copy the skill folder (swiftui-view-refactor in Dimillian/Skills) into .agents/skills/swiftui-view-refactor in your project. Codex loads it when a task matches its description.

Can I use Swiftui View Refactor in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Dimillian/Skills --skill swiftui-view-refactor -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/swiftui-view-refactor, .gemini/skills/swiftui-view-refactor, .github/skills/swiftui-view-refactor and .opencode/skills/swiftui-view-refactor in your project.

What does Swiftui View Refactor need to run?

SKILL.md names no scripts, command-line tools or credentials: Swiftui View Refactor is instructions for the agent only.

Does Swiftui View Refactor access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Swiftui View Refactor safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Swiftui View Refactor use?

Swiftui View Refactor is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Swiftui View Refactor use?

About 2k tokens (SKILL.md is roughly 8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.4k tokens, read only when the agent opens those files.

What are the alternatives to Swiftui View Refactor?

Skills that share tags, products or a category with Swiftui View Refactor: Swiftui View Refactor (harperreed/dotfiles, 334 stars), RTK Rust Design Patterns (rtk-ai/rtk, 83k stars), Architecture Patterns (KartikLabhshetwar/better-shot, 2.4k stars) and AST Visitor Pattern for Unions (prisma/orm, 48k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Swiftui View Refactor?

Dimillian (a GitHub user) maintains it in Dimillian/Skills, which has 3,984 GitHub stars. The repository holds 12 skills in this directory. The repository was last updated on March 29, 2026.

Source: Dimillian/Skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.