buildanything 1.8.0 → 2.0.0

package/skills/ios/ios-hig/references/accessibility.md

@@ -1,81 +0,0 @@
-# Accessibility
-
-Apple Human Interface Guidelines for accessible iOS app design.
-
-## Critical Rules
-
-- Provide meaningful accessibility labels/hints for icon-only controls and custom components
-- Ensure Dynamic Type works end-to-end; avoid layouts that collapse at larger sizes
-- Maintain readable contrast and avoid conveying meaning by color alone
-- Respect platform accessibility settings (Reduce Motion/Transparency) when relevant
-- Prefer system controls that come with good accessibility defaults
-
-## Examples
-
-### Icon-Only Buttons
-
-```swift
-// ✅ Icon-only button with accessible label
-Button(action: model.refresh) {
-    Image(systemName: "arrow.clockwise")
-}
-.accessibilityLabel("Refresh")
-.accessibilityHint("Reloads the list")
-
-// ❌ Icon-only control with no label; VoiceOver reads "arrow.clockwise"
-Button(action: model.refresh) {
-    Image(systemName: "arrow.clockwise")
-}
-```
-
-### Dynamic Type Support
-
-```swift
-// ✅ Dynamic Type with proper layout
-VStack(alignment: .leading, spacing: 8) {
-    Text(item.title)
-        .font(.headline)
-        .lineLimit(2)
-
-    if let summary = item.summary {
-        Text(summary)
-            .font(.body)
-            .foregroundStyle(.secondary)
-            .lineLimit(3)
-    }
-}
-
-// ❌ Hard-coded sizes that don't scale
-VStack(alignment: .leading) {
-    Text(item.title)
-        .font(.system(size: 14))
-        .lineLimit(1)
-}
-```
-
-### Reduce Motion
-
-```swift
-// ✅ Respect Reduce Motion setting
-@Environment(\.accessibilityReduceMotion) var reduceMotion
-
-var body: some View {
-    content
-        .animation(reduceMotion ? .none : .spring, value: isExpanded)
-}
-
-// ❌ Always animate regardless of setting
-var body: some View {
-    content
-        .animation(.spring, value: isExpanded)
-}
-```
-
-## Summary
-
-**Key Principles**:
-1. Use `.accessibilityLabel()` and `.accessibilityHint()` for icon-only controls
-2. Support Dynamic Type with system font styles
-3. Maintain sufficient color contrast
-4. Respect accessibility settings like Reduce Motion
-5. Prefer system controls with built-in accessibility

package/skills/ios/ios-hig/references/content.md

@@ -1,142 +0,0 @@
-# Content
-
-Apple Human Interface Guidelines for content, empty states, writing, and typography.
-
-## Table of Contents
-1. [Empty States](#empty-states)
-2. [Writing and Labels](#writing-and-labels)
-3. [Typography and Dynamic Type](#typography-and-dynamic-type)
-
-## Empty States
-
-### Critical Rules
-
-- Use empty states to **explain what this screen is** and **what to do next**
-- Prefer lightweight guidance (one sentence + primary action) over multi-step tutorials
-- Keep onboarding contextual: explain features at the moment the user needs them
-- Avoid placeholder junk content that looks real; make it obvious when content is sample/demo
-
-### Examples
-
-```swift
-// ✅ Helpful empty state with a clear next step
-ContentUnavailableView {
-    Label("No links yet", systemImage: "link")
-} description: {
-    Text("Save links to find them quickly later.")
-} actions: {
-    Button("Add link", systemImage: "plus") { model.presentAddLink() }
-        .buttonStyle(.borderedProminent)
-}
-
-// ❌ Empty UI with no explanation
-List { }
-```
-
-## Writing and Labels
-
-### Critical Rules
-
-- Prefer **plain language** and short phrases; avoid jargon and developer terms
-- Buttons should describe the action ("Save", "Add link"), not vague labels ("OK", "Yes")
-- Keep terminology consistent across the app (e.g., "Link" vs "URL"); choose one and stick to it
-- Error messages should explain the problem and the next step, without blame
-
-### Examples
-
-```swift
-// ✅ Clear action labels and consistent terminology
-Button("Add link", systemImage: "plus") { model.addLink() }
-Button("Save", action: model.save)
-
-// Error message example
-Text("Could not save link. Check your connection and try again.")
-
-// ❌ Vague and inconsistent
-Button("OK") { model.save() }
-Button("Add URL") { model.addLink() }
-
-// Error message without guidance
-Text("Error: Save failed")
-```
-
-### Writing Guidelines
-
-**Button Labels**:
-- ✅ "Delete", "Save", "Add link"
-- ❌ "OK", "Yes", "No"
-
-**Error Messages**:
-- ✅ "Could not load items. Pull to refresh."
-- ❌ "Error code 404"
-
-**Terminology Consistency**:
-- Choose one term and use it throughout
-- "Link" not "URL" or "Website"
-- "Save" not "Add" or "Create" interchangeably
-
-## Typography and Dynamic Type
-
-### Critical Rules
-
-- Use **Dynamic Type** styles (`.body`, `.headline`, `.caption`) instead of hard-coded sizes
-- Prefer **short, scannable labels**; use secondary text (`.secondary`) for supporting detail
-- Avoid truncation for critical info; if truncation can happen, provide an alternative (multi-line, disclosure, copy)
-- Use appropriate alignment and line limits; avoid overly dense paragraphs
-- Ensure text remains legible in accessibility sizes (test with larger sizes)
-
-### Examples
-
-```swift
-// ✅ Dynamic Type + predictable wrapping for important content
-VStack(alignment: .leading, spacing: 8) {
-    Text(item.title)
-        .font(.headline)
-        .lineLimit(2)
-
-    if let summary = item.summary {
-        Text(summary)
-            .font(.body)
-            .foregroundStyle(.secondary)
-            .lineLimit(3)
-    }
-}
-
-// ❌ Hard-coded sizes and single-line truncation for critical info
-VStack(alignment: .leading) {
-    Text(item.title)
-        .font(.system(size: 14))
-        .lineLimit(1)
-    Text(item.summary ?? "")
-        .font(.system(size: 11))
-        .lineLimit(1)
-}
-```
-
-### Dynamic Type Styles
-
-Use system text styles that scale with Dynamic Type:
-- `.largeTitle`, `.title`, `.title2`, `.title3`
-- `.headline`, `.body`, `.callout`
-- `.subheadline`, `.footnote`, `.caption`, `.caption2`
-
-```swift
-// ✅ System styles that scale
-Text("Main heading")
-    .font(.title2)
-Text("Body content")
-    .font(.body)
-Text("Supporting detail")
-    .font(.caption)
-    .foregroundStyle(.secondary)
-```
-
-## Summary
-
-**Key Principles**:
-1. Use `ContentUnavailableView` for helpful empty states
-2. Write clear, action-oriented button labels
-3. Keep terminology consistent throughout the app
-4. Error messages explain the problem and next step
-5. Use Dynamic Type styles, never hard-coded sizes
-6. Allow important text to wrap (don't truncate critical info)

package/skills/ios/ios-hig/references/feedback.md

@@ -1,123 +0,0 @@
-# Feedback
-
-Apple Human Interface Guidelines for motion, haptics, loading states, and error handling.
-
-## Table of Contents
-1. [Motion and Haptics](#motion-and-haptics)
-2. [Status and Error Feedback](#status-and-error-feedback)
-
-## Motion and Haptics
-
-### Critical Rules
-
-- Motion should be **purposeful**: reinforce state change, hierarchy, or causality—not decoration
-- Keep animations **subtle and consistent**; avoid stacking multiple effects (scale + rotate + blur) for routine interactions
-- Respect accessibility settings (Reduce Motion); don't rely on animation as the only feedback
-- Use haptics sparingly for meaningful moments (confirmations, errors), not for every tap
-
-### Examples
-
-```swift
-// ✅ Subtle animation tied to state change
-withAnimation(.spring(response: 0.35, dampingFraction: 0.85)) {
-    model.isExpanded.toggle()
-}
-
-// ❌ Excessive motion for routine UI; feels noisy and fatiguing
-withAnimation(.easeInOut(duration: 2.0)) {
-    model.isExpanded.toggle()
-}
-// Plus additional scale/rotation/blur effects on the entire screen
-```
-
-### Motion Guidelines
-
-**Purposeful Animation**:
-- State transitions (expanding/collapsing)
-- Hierarchy changes (list reordering)
-- Causality (deletion leading to list reflow)
-
-**Animation Parameters**:
-- Spring response: 0.3-0.4 seconds
-- Damping fraction: 0.8-0.9 (less bouncy)
-- Easing: Prefer springs over linear or custom curves
-
-**Accessibility**:
-- Always respect `@Environment(\.accessibilityReduceMotion)`
-- Provide non-animated alternatives
-- Don't use motion as the only feedback mechanism
-
-## Status and Error Feedback
-
-### Critical Rules
-
-- Always show **state feedback** for async work: loading, success, failure, and empty
-- Prefer **inline** status for local issues (validation) and **alerts** for exceptional interruptions
-- Make errors **actionable**: explain what happened in plain language and offer a next step (retry, fix input, dismiss)
-- Avoid blaming the user; avoid exposing raw system error text
-- Use system patterns for empty states (`ContentUnavailableView`) and progress (`ProgressView`)
-
-### Examples
-
-```swift
-// ✅ Clear empty state and recoverable error with retry
-Group {
-    if model.isLoading {
-        ProgressView("Loading…")
-    } else if model.items.isEmpty {
-        ContentUnavailableView(
-            "No items",
-            systemImage: "tray",
-            description: Text("Add your first item to get started.")
-        )
-    } else {
-        List(model.items) { item in Text(item.title) }
-    }
-}
-.alert("Couldn't load items", isPresented: $model.isShowingError) {
-    Button("Retry", action: model.reload)
-    Button("Cancel", role: .cancel) {}
-} message: {
-    Text("Check your connection and try again.")
-}
-
-// ❌ Silent failures and raw errors; no next step
-List(model.items) { item in Text(item.title) }
-// On error: print(error) and keep stale UI with no feedback
-```
-
-### Status Guidelines
-
-**Loading States**:
-- Use `ProgressView` for async operations
-- Show progress for operations >1 second
-- Provide context ("Loading items…")
-
-**Empty States**:
-- Use `ContentUnavailableView` for empty collections
-- Explain what the view is for
-- Provide a primary action to get started
-
-**Error States**:
-- Use alerts for unexpected errors that interrupt flow
-- Use inline validation for expected errors (form fields)
-- Always provide a recovery action
-
-**Error Messages**:
-- ✅ "Couldn't save item. Check your connection and try again."
-- ❌ "Error: NetworkError.timeout"
-
-**Next Steps**:
-- Retry button for transient failures
-- Fix input guidance for validation errors
-- Dismiss or cancel for unrecoverable errors
-
-## Summary
-
-**Key Principles**:
-1. Keep motion subtle, purposeful, and tied to state changes
-2. Respect Reduce Motion accessibility setting
-3. Always show feedback for async operations (loading, empty, error)
-4. Make errors actionable with plain language and recovery steps
-5. Use system patterns (`ProgressView`, `ContentUnavailableView`, alerts)
-6. Prefer inline validation for expected errors, alerts for exceptional interruptions

package/skills/ios/ios-hig/references/interaction.md

@@ -1,199 +0,0 @@
-# Interaction
-
-Apple Human Interface Guidelines for touch targets, input, navigation, layout, and hierarchy.
-
-## Table of Contents
-1. [Touch Targets and Input](#touch-targets-and-input)
-2. [Navigation and Flows](#navigation-and-flows)
-3. [Layout, Hierarchy, and Grouping](#layout-hierarchy-and-grouping)
-
-## Touch Targets and Input
-
-### Critical Rules
-
-- Use system controls (`Button`, `Toggle`, `TextField`, `Picker`) rather than custom hit-testing
-- Ensure **comfortable hit targets**; avoid tiny icons-only tap areas
-- Prefer **clear labels** over icon-only actions; use SF Symbols consistently with text where appropriate
-- Use appropriate keyboard/input behaviors (submit labels, autocorrection/capitalization) for the field's purpose
-- Avoid gesture-only interactions for primary actions; make actions discoverable
-
-### Examples
-
-```swift
-// ✅ Tappable control with label + icon; clear intent
-Button("Add item", systemImage: "plus") {
-    model.add()
-}
-.buttonStyle(.borderedProminent)
-
-// ✅ TextField with appropriate keyboard
-TextField("Email", text: $email)
-    .keyboardType(.emailAddress)
-    .textInputAutocapitalization(.never)
-    .autocorrectionDisabled()
-
-// ❌ Tiny icon-only tap target; poor discoverability
-Image(systemName: "plus")
-    .onTapGesture {
-        model.add()
-    }
-```
-
-## Navigation and Flows
-
-### Critical Rules
-
-- Prefer **NavigationStack + navigationDestination** for drill-in flows; keep navigation shallow where possible
-- Use **modals** for short, self-contained tasks (create, edit, pick); always provide a clear way to dismiss
-- Keep **back behavior predictable**: don't override system expectations; preserve navigation state when reasonable
-- Avoid "choice paralysis": limit top-level destinations; group related settings and utilities
-- Prefer system placements: `.confirmationAction` for Save/Done, `.cancellationAction` for Cancel
-
-### Examples
-
-```swift
-// ✅ Predictable drill-in navigation; modal only for creation
-NavigationStack {
-    List(items) { item in
-        NavigationLink(item.title, value: item.id)
-    }
-    .navigationDestination(for: Item.ID.self) { id in
-        ItemDetailView(id: id)
-    }
-    .toolbar {
-        ToolbarItem(placement: .primaryAction) {
-            Button("Add", systemImage: "plus") { model.isPresentingCreate = true }
-        }
-    }
-    .sheet(isPresented: $model.isPresentingCreate) {
-        NavigationStack { CreateItemView() }
-    }
-}
-
-// ✅ Modal with clear dismiss path
-NavigationStack {
-    CreateItemView()
-        .navigationTitle("New Item")
-        .toolbar {
-            ToolbarItem(placement: .cancellationAction) {
-                Button("Cancel", action: dismiss)
-            }
-            ToolbarItem(placement: .confirmationAction) {
-                Button("Save", action: model.save)
-            }
-        }
-}
-
-// ❌ Everything is a modal; unclear back/exit paths
-VStack {
-    Button("Open item") { model.showItem.toggle() }
-}
-.sheet(isPresented: $model.showItem) {
-    ItemDetailView(id: model.selectedID)
-        .toolbar { Button("Save") {} } // no Cancel, no navigation context
-}
-```
-
-### Navigation Guidelines
-
-**Use NavigationStack for**:
-- Browsing hierarchical content
-- Drill-down patterns
-- Main app navigation
-
-**Use Modals (.sheet, .fullScreenCover) for**:
-- Creating new content
-- Editing existing content
-- Short, self-contained tasks
-- Pickers and selections
-
-**Always provide**:
-- Clear dismiss buttons for modals
-- Consistent back button behavior
-- Confirmation for destructive actions
-
-## Layout, Hierarchy, and Grouping
-
-### Critical Rules
-
-- Design around **content first**: prioritize the primary task and content; remove decorative UI that doesn't help comprehension
-- Create **clear hierarchy**: one primary action per screen; secondary actions are visually subordinate
-- Use **consistent spacing and alignment** to communicate grouping; avoid "random" padding values across the app
-- Prefer system containers (`List`, `Form`, `Section`, `Toolbar`, `NavigationStack`) that encode platform layout conventions
-- Avoid dense UI: keep line lengths readable and allow whitespace for scanning
-
-### Examples
-
-```swift
-// ✅ Hierarchy + grouping via Sections; one primary action in toolbar
-NavigationStack {
-    List {
-        Section("Details") {
-            TextField("Title", text: $model.title)
-            TextField("Notes", text: $model.notes, axis: .vertical)
-        }
-
-        Section("Metadata") {
-            Toggle("Pinned", isOn: $model.isPinned)
-        }
-    }
-    .navigationTitle("New item")
-    .toolbar {
-        ToolbarItem(placement: .confirmationAction) {
-            Button("Save", action: model.save)
-        }
-    }
-}
-
-// ✅ Clear visual hierarchy with system components
-VStack(spacing: 16) {
-    // Primary action
-    Button("Continue", action: model.continue)
-        .buttonStyle(.borderedProminent)
-        .controlSize(.large)
-
-    // Secondary action
-    Button("Skip for now", action: model.skip)
-        .buttonStyle(.borderless)
-        .foregroundStyle(.secondary)
-}
-
-// ❌ Flat wall-of-controls with unclear priority
-VStack(spacing: 3) {
-    Text("New item").font(.title2)
-    TextField("Title", text: $model.title).padding(1)
-    TextField("Notes", text: $model.notes).padding(23)
-    Toggle("Pinned", isOn: $model.isPinned)
-    Button("Save", action: model.save)
-    Button("Delete", action: model.delete)
-}
-```
-
-### Layout Guidelines
-
-**Visual Hierarchy**:
-- One primary action per screen (prominent button style)
-- Secondary actions are visually subordinate (borderless, smaller)
-- Destructive actions are clearly marked (`.destructive` role)
-
-**Spacing and Grouping**:
-- Use `Section` in `List` or `Form` to group related controls
-- Consistent spacing values (8, 12, 16, 20, 24)
-- Whitespace communicates relationships
-
-**System Containers**:
-- `List` for browsable content
-- `Form` for data entry
-- `Section` for grouping
-- `Toolbar` for actions
-- `NavigationStack` for hierarchies
-
-## Summary
-
-**Key Principles**:
-1. Use system controls with comfortable hit targets
-2. NavigationStack for drill-down, modals for tasks
-3. Always provide clear dismiss paths
-4. One primary action per screen
-5. Use sections and spacing for grouping
-6. Prefer system containers over custom layouts

package/skills/ios/ios-hig/references/performance-platform.md

@@ -1,129 +0,0 @@
-# Performance and Platform Conventions
-
-Apple Human Interface Guidelines for performance, responsiveness, and platform-native patterns.
-
-## Table of Contents
-1. [Performance and Responsiveness](#performance-and-responsiveness)
-2. [Platform Conventions](#platform-conventions)
-
-## Performance and Responsiveness
-
-### Critical Rules
-
-- Optimize for **perceived performance**: show progress quickly, keep interactions responsive, and avoid blocking the main actor
-- Use incremental loading patterns where appropriate; avoid doing heavy work during view rendering
-- Prefer clear placeholder/progress UI over a frozen screen
-- Avoid unnecessary animations, shadows, and effects that degrade scrolling performance
-
-### Examples
-
-```swift
-// ✅ Immediate feedback and non-blocking load
-VStack {
-    if model.isLoading {
-        ProgressView("Loading…")
-    } else {
-        List(model.items) { item in Text(item.title) }
-    }
-}
-.task { await model.loadIfNeeded() }
-
-// ❌ Heavy synchronous work during view body; causes jank
-var body: some View {
-    let items = model.computeExpensiveListSynchronously()
-    return List(items) { item in Text(item.title) }
-}
-```
-
-### Performance Guidelines
-
-**Perceived Performance**:
-- Show UI immediately, even if data isn't ready
-- Use `ProgressView` or skeleton states while loading
-- Keep interactions responsive (<100ms feedback)
-- Avoid blocking the main thread
-
-**Async Work**:
-- Use `.task { }` for async loading in views
-- Move heavy computation to background tasks
-- Never do expensive work in `body` or computed properties
-
-**Rendering Performance**:
-- Avoid heavy shadows, blurs, or complex gradients in scrolling views
-- Use `LazyVStack`/`LazyHStack` for large lists
-- Profile with Instruments if scrolling feels janky
-
-**Loading Patterns**:
-- Show skeleton/placeholder UI immediately
-- Load data incrementally when appropriate
-- Provide progress indication for operations >1 second
-
-## Platform Conventions
-
-### Critical Rules
-
-- Prefer system components before custom UI (Lists, Forms, toolbars, menus, context menus)
-- Use SF Symbols consistently and pair icons with text for clarity when appropriate
-- Keep controls and terminology consistent with iOS conventions (Done/Cancel, Back, Edit)
-- Avoid recreating iOS UI patterns with bespoke visuals unless you have a strong UX reason
-
-### Examples
-
-```swift
-// ✅ System toolbar placements and familiar labels
-.toolbar {
-    ToolbarItem(placement: .cancellationAction) {
-        Button("Cancel", role: .cancel) { model.cancel() }
-    }
-    ToolbarItem(placement: .confirmationAction) {
-        Button("Done", action: model.done)
-    }
-}
-
-// ❌ Custom "Close" / "Okay" in random placements; inconsistent with platform
-.toolbar {
-    ToolbarItem(placement: .automatic) { Button("Okay") {} }
-    ToolbarItem(placement: .automatic) { Button("Close") {} }
-}
-```
-
-### Platform Guidelines
-
-**System Components**:
-- `List` for browsable content
-- `Form` for settings and data entry
-- `Toolbar` for actions
-- `NavigationStack` for hierarchical navigation
-- `Menu` and context menus for secondary actions
-
-**SF Symbols**:
-- Use SF Symbols for icons (system-provided, adapts to Dynamic Type)
-- Pair icons with text labels for clarity
-- Use consistent symbols throughout the app
-- Prefer standard symbols over custom icons
-
-**Platform Terminology**:
-- ✅ "Done", "Cancel", "Save", "Delete", "Edit"
-- ❌ "Okay", "Close", "Submit", "Remove", "Modify"
-
-**Standard Placements**:
-- `.cancellationAction` - Cancel/Back (leading on modals)
-- `.confirmationAction` - Done/Save (trailing on modals)
-- `.destructive` role for Delete actions
-- `.primaryAction` for main toolbar actions
-
-**Consistency**:
-- Follow iOS patterns for common flows (creation, editing, deletion)
-- Use standard gestures (swipe to delete, pull to refresh)
-- Respect system settings (Dynamic Type, Reduce Motion, Reduce Transparency)
-
-## Summary
-
-**Key Principles**:
-1. Show UI immediately; load data asynchronously
-2. Use `ProgressView` and skeleton states while loading
-3. Avoid heavy work during view rendering
-4. Prefer system components over custom UI
-5. Use SF Symbols and standard terminology
-6. Follow platform conventions for toolbar placements and actions
-7. Keep controls and terminology consistent with iOS