← ClaudeAtlas

macos-swiftui-architectlisted

Build or refactor native macOS SwiftUI scenes and components: windows, commands, toolbars, settings, split views, inspectors, menu bar extras, keyboard workflows, and desktop layouts.
Xopoko/plug-n-skills · ★ 3 · Web & Frontend · score 76
Install: claude install-skill Xopoko/plug-n-skills
# 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`, or `DocumentGroup`. - For menu-bar apps that should also show normal windows, use `@NSApplicationDelegateAdaptor`, `.regular` activation 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 `@SceneStorage` for per-window ephemeral state and `@AppStorage` for preferences. - Prefer stable sidebar selection and `NavigationSplitView` over iOS-style push navigation when persistent structure helps. - Keep primary actions available through UI chrome and keyboa