Macos swiftui architect
Skill Xopoko/build-swift-apps/skills/macos-swiftui-architect
Build or refactor native macOS SwiftUI scenes and components: windows, commands, toolbars, settings, split views, inspectors, menu bar extras, keyboard workflows, and desktop layouts.From its SKILL.md
npx -y skills add Xopoko/build-swift-apps --skill macos-swiftui-architectAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.8 KB, 815 tokens by cl100k_base, as published. Nobody here has run it
macOS SwiftUI Architect
Use for macOS SwiftUI scene/component choices. Use macos-runtime-debugger for build/run, macos-view-architect for large-file extraction, and macos-appkit-bridge for AppKit-only behavior.
Start
- Existing project: read nearest scene/root view, identify interaction model, then open the relevant file from
references/components-index.md. - New app: choose scene model first:
WindowGroup,Window,Settings,MenuBarExtra, orDocumentGroup. - For menu-bar apps that should also show normal windows, use
@NSApplicationDelegateAdaptor,.regularactivation policy, and activate on launch. - Use
WindowGroup(..., id:)for a primary launched window;Window(...)for auxiliary/on-demand singleton windows. - Decide state ownership before writing views: app-wide, scene/window scoped, or local.
Desktop Rules
- Design for pointer, keyboard, menus, multiple windows, toolbars, sidebars, inspectors, context menus, and search.
- Keep scenes explicit; do not hide settings, utility windows, or menu-bar flows inside one giant
ContentView. - Prefer system colors/materials and semantic foreground styles; avoid hardcoded white roots and opaque custom sidebars unless requested.
- Use
@SceneStoragefor per-window ephemeral state and@AppStoragefor preferences. - Prefer stable sidebar selection and
NavigationSplitViewover iOS-style push navigation when persistent structure helps. - Keep primary actions available through UI chrome and keyboard/menu paths.
- Use SwiftUI-native APIs first; switch to
macos-appkit-bridgefor responder chain, panels, low-level windows, or text system control.
Sidebar Pattern
Native source-list rows: one leading icon, one title, and optional secondary detail line. Put dense metadata/cards in detail or inspector panes, not every sidebar row.
List(selection: $selection) {
ForEach(items) { item in
HStack(spacing: 10) {
Image(systemName: item.systemImage).frame(width: 16).foregroundStyle(.secondary)
VStack(alignment: .leading, spacing: 2) {
Text(item.title).lineLimit(1)
if let detail = item.detail {
Text(detail).font(.caption).foregroundStyle(.secondary).lineLimit(1)
}
}
}
.tag(item.id)
}
}
.listStyle(.sidebar)
Let NavigationSplitView sidebars use native materials. Apply custom surfaces only to detail cards or inspector sections.
State Ownership
| Scenario | Pattern |
|---|---|
| Local control state | @State |
| Child mutates parent value | @Binding |
Root-owned @Observable | @State |
| Injected observable/service | property or @Environment(Type.self) |
| Window selection/expansion | @SceneStorage when practical |
| Durable preference | @AppStorage |
| Legacy observable | @StateObject owner, @ObservedObject injected |
Avoid
One app-sized ContentView; touch-first flows without desktop affordances; actions only behind gestures; menu bar labels over 30 characters; settings as a main-window destination; card sidebars inside .sidebar lists unless requested; opaque split-pane backgrounds by default; AppKit bridges before SwiftUI scenes/commands/windows have been tried.
New Scene
Pick scene type/state ownership, place actions in content/toolbar/commands/inspector/settings, choose layout, split files by responsibility, add keyboard/menu/toolbar exposure, then build/run and check multiwindow behavior, settings entry points, and selection stability.
References
references/components-index.mdreferences/windowing.mdreferences/settings.mdreferences/commands-menus.mdreferences/split-inspectors.mdreferences/menu-bar-extra.md
What ships with it: 7 files
9.9 KB alongside SKILL.md
agents/
- openai.yaml322 B
references/
- commands-menus.md1.1 KB
- components-index.md998 B
- menu-bar-extra.md3.0 KB
- settings.md1.4 KB
- split-inspectors.md1.2 KB
- windowing.md1.9 KB
Gives 0 of the 12 instructions most architecture codebase skills give in 815 tokens
Counted across 858 of the 1,304 authors here whose files we hold, read 2026-09-06
- Apply the deletion test to identify shallow modulesin 32 of 858, across 31 files
- Read domain glossary and ADRs before exploringin 22 of 858, across 19 files
- Use Tailwind and Mermaid via CDN for reportsin 21 of 858, across 18 files
- Document architecture decision recordsin 20 of 858, across 12 files
- Offer to record ADRs for rejected candidatesin 17 of 858, across 14 files
- Limit primary navigation to four to seven itemsin 17 of 858, across 7 files
- Write HTML report to the system temp directoryin 17 of 858, across 14 files
- Read product marketing context before asking questionsin 16 of 858, across 6 files
- Use Mermaid graph TD for visual sitemapsin 15 of 858, across 5 files
- Ensure every page has at least one internal linkin 15 of 858, across 5 files
- Use ASCII tree format for page hierarchy draftsin 15 of 858, across 5 files
- Enforce lowercase URLs with hyphensin 15 of 858, across 5 files
Said here and by no other author read
- Identify interaction model before editing
- Choose scene model before writing code
- Decide state ownership before writing views
- Use WindowGroup for primary launched windows
- Use Window for auxiliary singleton windows
- Design for pointer and keyboard interaction
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.