opencode-skills-antigravity 1.0.12 → 1.0.14

package/bundled-skills/swift-concurrency-expert/references/swiftui-concurrency-tour-wwdc.md

@@ -0,0 +1,33 @@
+# SwiftUI Concurrency Tour (Summary)
+
+Context: SwiftUI-focused concurrency overview covering actor isolation, Sendable closures, and how SwiftUI runs work off the main thread.
+
+## Main-actor default in SwiftUI
+
+- `View` is `@MainActor` isolated by default; members and `body` inherit isolation.
+- Swift 6.2 can infer `@MainActor` for all types in a module (new language mode).
+- This default simplifies UI code and aligns with UIKit/AppKit `@MainActor` APIs.
+
+## Where SwiftUI runs code off the main thread
+
+- SwiftUI may evaluate some view logic on background threads for performance.
+- Examples: `Shape` path generation, `Layout` methods, `visualEffect` closures, and `onGeometryChange` closures.
+- These APIs often require `Sendable` closures to reflect their runtime semantics.
+
+## Sendable closures and data-race safety
+
+- Accessing `@MainActor` state from a `Sendable` closure is unsafe and flagged by the compiler.
+- Prefer capturing value copies in the closure capture list (e.g., copy a `Bool`).
+- Avoid sending `self` into a sendable closure just to read a single property.
+
+## Structuring async work with SwiftUI
+
+- SwiftUI action callbacks are synchronous so UI updates (like loading states) can be immediate.
+- Use `Task` to bridge into async contexts; keep async bodies minimal.
+- Use state as the boundary: async work updates model/state; UI reacts synchronously.
+
+## Performance-driven concurrency
+
+- Offload expensive work from the main actor to avoid hitches.
+- Keep time-sensitive UI logic (animations, gesture responses) synchronous.
+- Separate UI code from long-running async work to improve responsiveness and testability.

package/bundled-skills/swiftui-liquid-glass/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: swiftui-liquid-glass
+description: Implement or review SwiftUI Liquid Glass APIs with correct fallbacks and modifier order.
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# SwiftUI Liquid Glass
+
+## Overview
+Use this skill to build or review SwiftUI features that fully align with the iOS 26+ Liquid Glass API. Prioritize native APIs (`glassEffect`, `GlassEffectContainer`, glass button styles) and Apple design guidance. Keep usage consistent, interactive where needed, and performance aware.
+
+## When to Use
+
+- When the user wants to adopt or review Liquid Glass in SwiftUI UI.
+- When you need correct API usage, fallback handling, or modifier ordering for Liquid Glass.
+
+## Workflow Decision Tree
+Choose the path that matches the request:
+
+### 1) Review an existing feature
+- Inspect where Liquid Glass should be used and where it should not.
+- Verify correct modifier order, shape usage, and container placement.
+- Check for iOS 26+ availability handling and sensible fallbacks.
+
+### 2) Improve a feature using Liquid Glass
+- Identify target components for glass treatment (surfaces, chips, buttons, cards).
+- Refactor to use `GlassEffectContainer` where multiple glass elements appear.
+- Introduce interactive glass only for tappable or focusable elements.
+
+### 3) Implement a new feature using Liquid Glass
+- Design the glass surfaces and interactions first (shape, prominence, grouping).
+- Add glass modifiers after layout/appearance modifiers.
+- Add morphing transitions only when the view hierarchy changes with animation.
+
+## Core Guidelines
+- Prefer native Liquid Glass APIs over custom blurs.
+- Use `GlassEffectContainer` when multiple glass elements coexist.
+- Apply `.glassEffect(...)` after layout and visual modifiers.
+- Use `.interactive()` for elements that respond to touch/pointer.
+- Keep shapes consistent across related elements for a cohesive look.
+- Gate with `#available(iOS 26, *)` and provide a non-glass fallback.
+
+## Review Checklist
+- **Availability**: `#available(iOS 26, *)` present with fallback UI.
+- **Composition**: Multiple glass views wrapped in `GlassEffectContainer`.
+- **Modifier order**: `glassEffect` applied after layout/appearance modifiers.
+- **Interactivity**: `interactive()` only where user interaction exists.
+- **Transitions**: `glassEffectID` used with `@Namespace` for morphing.
+- **Consistency**: Shapes, tinting, and spacing align across the feature.
+
+## Implementation Checklist
+- Define target elements and desired glass prominence.
+- Wrap grouped glass elements in `GlassEffectContainer` and tune spacing.
+- Use `.glassEffect(.regular.tint(...).interactive(), in: .rect(cornerRadius: ...))` as needed.
+- Use `.buttonStyle(.glass)` / `.buttonStyle(.glassProminent)` for actions.
+- Add morphing transitions with `glassEffectID` when hierarchy changes.
+- Provide fallback materials and visuals for earlier iOS versions.
+
+## Quick Snippets
+Use these patterns directly and tailor shapes/tints/spacing.
+
+```swift
+if #available(iOS 26, *) {
+    Text("Hello")
+        .padding()
+        .glassEffect(.regular.interactive(), in: .rect(cornerRadius: 16))
+} else {
+    Text("Hello")
+        .padding()
+        .background(.ultraThinMaterial, in: RoundedRectangle(cornerRadius: 16))
+}
+```
+
+```swift
+GlassEffectContainer(spacing: 24) {
+    HStack(spacing: 24) {
+        Image(systemName: "scribble.variable")
+            .frame(width: 72, height: 72)
+            .font(.system(size: 32))
+            .glassEffect()
+        Image(systemName: "eraser.fill")
+            .frame(width: 72, height: 72)
+            .font(.system(size: 32))
+            .glassEffect()
+    }
+}
+```
+
+```swift
+Button("Confirm") { }
+    .buttonStyle(.glassProminent)
+```
+
+## Resources
+- Reference guide: `references/liquid-glass.md`
+- Prefer Apple docs for up-to-date API details.

package/bundled-skills/swiftui-liquid-glass/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "SwiftUI Liquid Glass"
+  short_description: "Build SwiftUI Liquid Glass features"
+  default_prompt: "Use $swiftui-liquid-glass to implement or review a SwiftUI feature using Liquid Glass APIs."

package/bundled-skills/swiftui-liquid-glass/references/liquid-glass.md

@@ -0,0 +1,280 @@
+# Implementing Liquid Glass Design in SwiftUI
+
+## Overview
+
+Liquid Glass is a dynamic material introduced in iOS that combines the optical properties of glass with a sense of fluidity. It blurs content behind it, reflects color and light from surrounding content, and reacts to touch and pointer interactions in real time. This guide covers how to implement and customize Liquid Glass effects in SwiftUI applications. You should always seek guides on Liquid Glass when asked for help adopting new Apple design.
+
+Key features of Liquid Glass:
+- Blurs content behind the material
+- Reflects color and light from surrounding content
+- Reacts to touch and pointer interactions
+- Can morph between shapes during transitions
+- Available for standard and custom components
+
+## Basic Implementation
+
+### Adding Liquid Glass to a View
+
+The simplest way to add Liquid Glass to a view is using the `glassEffect()` modifier:
+
+```swift
+Text("Hello, World!")
+    .font(.title)
+    .padding()
+    .glassEffect()
+```
+
+By default, this applies the regular variant of Glass within a Capsule shape behind the view's content.
+
+### Customizing the Shape
+
+You can specify a different shape for the Liquid Glass effect:
+
+```swift
+Text("Hello, World!")
+    .font(.title)
+    .padding()
+    .glassEffect(in: .rect(cornerRadius: 16.0))
+```
+
+Common shape options:
+- `.capsule` (default)
+- `.rect(cornerRadius: CGFloat)`
+- `.circle`
+
+## Customizing Liquid Glass Effects
+
+### Glass Variants and Properties
+
+You can customize the Liquid Glass effect by configuring the `Glass` structure:
+
+```swift
+Text("Hello, World!")
+    .font(.title)
+    .padding()
+    .glassEffect(.regular.tint(.orange).interactive())
+```
+
+Key customization options:
+- `.regular` - Standard glass effect
+- `.tint(Color)` - Add a color tint to suggest prominence
+- `.interactive(Bool)` - Make the glass react to touch and pointer interactions
+
+### Making Interactive Glass
+
+To make Liquid Glass react to touch and pointer interactions:
+
+```swift
+Text("Hello, World!")
+    .font(.title)
+    .padding()
+    .glassEffect(.regular.interactive(true))
+```
+
+Or more concisely:
+
+```swift
+Text("Hello, World!")
+    .font(.title)
+    .padding()
+    .glassEffect(.regular.interactive())
+```
+
+## Working with Multiple Glass Effects
+
+### Using GlassEffectContainer
+
+When applying Liquid Glass effects to multiple views, use `GlassEffectContainer` for better rendering performance and to enable blending and morphing effects:
+
+```swift
+GlassEffectContainer(spacing: 40.0) {
+    HStack(spacing: 40.0) {
+        Image(systemName: "scribble.variable")
+            .frame(width: 80.0, height: 80.0)
+            .font(.system(size: 36))
+            .glassEffect()
+
+        Image(systemName: "eraser.fill")
+            .frame(width: 80.0, height: 80.0)
+            .font(.system(size: 36))
+            .glassEffect()
+    }
+}
+```
+
+The `spacing` parameter controls how the Liquid Glass effects interact with each other:
+- Smaller spacing: Views need to be closer to merge effects
+- Larger spacing: Effects merge at greater distances
+
+### Uniting Multiple Glass Effects
+
+To combine multiple views into a single Liquid Glass effect, use the `glassEffectUnion` modifier:
+
+```swift
+@Namespace private var namespace
+
+// Later in your view:
+GlassEffectContainer(spacing: 20.0) {
+    HStack(spacing: 20.0) {
+        ForEach(symbolSet.indices, id: \.self) { item in
+            Image(systemName: symbolSet[item])
+                .frame(width: 80.0, height: 80.0)
+                .font(.system(size: 36))
+                .glassEffect()
+                .glassEffectUnion(id: item < 2 ? "1" : "2", namespace: namespace)
+        }
+    }
+}
+```
+
+This is useful when creating views dynamically or with views that live outside of an HStack or VStack.
+
+## Morphing Effects and Transitions
+
+### Creating Morphing Transitions
+
+To create morphing effects during transitions between views with Liquid Glass:
+
+1. Create a namespace using the `@Namespace` property wrapper
+2. Associate each Liquid Glass effect with a unique identifier using `glassEffectID`
+3. Use animations when changing the view hierarchy
+
+```swift
+@State private var isExpanded: Bool = false
+@Namespace private var namespace
+
+var body: some View {
+    GlassEffectContainer(spacing: 40.0) {
+        HStack(spacing: 40.0) {
+            Image(systemName: "scribble.variable")
+                .frame(width: 80.0, height: 80.0)
+                .font(.system(size: 36))
+                .glassEffect()
+                .glassEffectID("pencil", in: namespace)
+
+            if isExpanded {
+                Image(systemName: "eraser.fill")
+                    .frame(width: 80.0, height: 80.0)
+                    .font(.system(size: 36))
+                    .glassEffect()
+                    .glassEffectID("eraser", in: namespace)
+            }
+        }
+    }
+
+    Button("Toggle") {
+        withAnimation {
+            isExpanded.toggle()
+        }
+    }
+    .buttonStyle(.glass)
+}
+```
+
+The morphing effect occurs when views with Liquid Glass appear or disappear due to view hierarchy changes.
+
+## Button Styling with Liquid Glass
+
+### Glass Button Style
+
+SwiftUI provides built-in button styles for Liquid Glass:
+
+```swift
+Button("Click Me") {
+    // Action
+}
+.buttonStyle(.glass)
+```
+
+### Glass Prominent Button Style
+
+For a more prominent glass button:
+
+```swift
+Button("Important Action") {
+    // Action
+}
+.buttonStyle(.glassProminent)
+```
+
+## Advanced Techniques
+
+### Background Extension Effect
+
+To stretch content behind a sidebar or inspector with the background extension effect:
+
+```swift
+NavigationSplitView {
+    // Sidebar content
+} detail: {
+    // Detail content
+        .background {
+            // Background content that extends under the sidebar
+        }
+}
+```
+
+### Extending Horizontal Scrolling Under Sidebar
+
+To extend horizontal scroll views under a sidebar or inspector:
+
+```swift
+ScrollView(.horizontal) {
+    // Scrollable content
+}
+.scrollExtensionMode(.underSidebar)
+```
+
+## Best Practices
+
+1. **Container Usage**: Always use `GlassEffectContainer` when applying Liquid Glass to multiple views for better performance and morphing effects.
+
+2. **Effect Order**: Apply the `.glassEffect()` modifier after other modifiers that affect the appearance of the view.
+
+3. **Spacing Consideration**: Carefully choose spacing values in containers to control how and when glass effects merge.
+
+4. **Animation**: Use animations when changing view hierarchies to enable smooth morphing transitions.
+
+5. **Interactivity**: Add `.interactive()` to glass effects that should respond to user interaction.
+
+6. **Consistent Design**: Maintain consistent shapes and styles across your app for a cohesive look and feel.
+
+## Example: Custom Badge with Liquid Glass
+
+```swift
+struct BadgeView: View {
+    let symbol: String
+    let color: Color
+
+    var body: some View {
+        ZStack {
+            Image(systemName: "hexagon.fill")
+                .foregroundColor(color)
+                .font(.system(size: 50))
+
+            Image(systemName: symbol)
+                .foregroundColor(.white)
+                .font(.system(size: 30))
+        }
+        .glassEffect(.regular, in: .rect(cornerRadius: 16))
+    }
+}
+
+// Usage:
+GlassEffectContainer(spacing: 20) {
+    HStack(spacing: 20) {
+        BadgeView(symbol: "star.fill", color: .blue)
+        BadgeView(symbol: "heart.fill", color: .red)
+        BadgeView(symbol: "leaf.fill", color: .green)
+    }
+}
+```
+
+## References
+
+- [Applying Liquid Glass to custom views](https://developer.apple.com/documentation/SwiftUI/Applying-Liquid-Glass-to-custom-views)
+- [Landmarks: Building an app with Liquid Glass](https://developer.apple.com/documentation/SwiftUI/Landmarks-Building-an-app-with-Liquid-Glass)
+- [SwiftUI View.glassEffect(_:in:isEnabled:)](https://developer.apple.com/documentation/SwiftUI/View/glassEffect(_:in:isEnabled:))
+- [SwiftUI GlassEffectContainer](https://developer.apple.com/documentation/SwiftUI/GlassEffectContainer)
+- [SwiftUI GlassEffectTransition](https://developer.apple.com/documentation/SwiftUI/GlassEffectTransition)
+- [SwiftUI GlassButtonStyle](https://developer.apple.com/documentation/SwiftUI/GlassButtonStyle)

package/bundled-skills/swiftui-performance-audit/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: swiftui-performance-audit
+description: Audit SwiftUI performance issues from code review and profiling evidence.
+risk: safe
+source: "Dimillian/Skills (MIT)"
+date_added: "2026-03-25"
+---
+
+# SwiftUI Performance Audit
+
+## Quick start
+
+Use this skill to diagnose SwiftUI performance issues from code first, then request profiling evidence when code review alone cannot explain the symptoms.
+
+## When to Use
+
+- When the user reports slow rendering, janky scrolling, layout thrash, or high CPU in SwiftUI.
+- When you need a code-first audit plus Instruments guidance if profiling evidence is required.
+
+## Workflow
+
+1. Classify the symptom: slow rendering, janky scrolling, high CPU, memory growth, hangs, or excessive view updates.
+2. If code is available, start with a code-first review using `references/code-smells.md`.
+3. If code is not available, ask for the smallest useful slice: target view, data flow, reproduction steps, and deployment target.
+4. If code review is inconclusive or runtime evidence is required, guide the user through profiling with `references/profiling-intake.md`.
+5. Summarize likely causes, evidence, remediation, and validation steps using `references/report-template.md`.
+
+## 1. Intake
+
+Collect:
+- Target view or feature code.
+- Symptoms and exact reproduction steps.
+- Data flow: `@State`, `@Binding`, environment dependencies, and observable models.
+- Whether the issue shows up on device or simulator, and whether it was observed in Debug or Release.
+
+Ask the user to classify the issue if possible:
+- CPU spike or battery drain
+- Janky scrolling or dropped frames
+- High memory or image pressure
+- Hangs or unresponsive interactions
+- Excessive or unexpectedly broad view updates
+
+For the full profiling intake checklist, read `references/profiling-intake.md`.
+
+## 2. Code-First Review
+
+Focus on:
+- Invalidation storms from broad observation or environment reads.
+- Unstable identity in lists and `ForEach`.
+- Heavy derived work in `body` or view builders.
+- Layout thrash from complex hierarchies, `GeometryReader`, or preference chains.
+- Large image decode or resize work on the main thread.
+- Animation or transition work applied too broadly.
+
+Use `references/code-smells.md` for the detailed smell catalog and fix guidance.
+
+Provide:
+- Likely root causes with code references.
+- Suggested fixes and refactors.
+- If needed, a minimal repro or instrumentation suggestion.
+
+## 3. Guide the User to Profile
+
+If code review does not explain the issue, ask for runtime evidence:
+- A trace export or screenshots of the SwiftUI timeline and Time Profiler call tree.
+- Device/OS/build configuration.
+- The exact interaction being profiled.
+- Before/after metrics if the user is comparing a change.
+
+Use `references/profiling-intake.md` for the exact checklist and collection steps.
+
+## 4. Analyze and Diagnose
+
+- Map the evidence to the most likely category: invalidation, identity churn, layout thrash, main-thread work, image cost, or animation cost.
+- Prioritize problems by impact, not by how easy they are to explain.
+- Distinguish code-level suspicion from trace-backed evidence.
+- Call out when profiling is still insufficient and what additional evidence would reduce uncertainty.
+
+## 5. Remediate
+
+Apply targeted fixes:
+- Narrow state scope and reduce broad observation fan-out.
+- Stabilize identities for `ForEach` and lists.
+- Move heavy work out of `body` into derived state updated from inputs, model-layer precomputation, memoized helpers, or background preprocessing. Use `@State` only for view-owned state, not as an ad hoc cache for arbitrary computation.
+- Use `equatable()` only when equality is cheaper than recomputing the subtree and the inputs are truly value-semantic.
+- Downsample images before rendering.
+- Reduce layout complexity or use fixed sizing where possible.
+
+Use `references/code-smells.md` for examples, Observation-specific fan-out guidance, and remediation patterns.
+
+## 6. Verify
+
+Ask the user to re-run the same capture and compare with baseline metrics.
+Summarize the delta (CPU, frame drops, memory peak) if provided.
+
+## Outputs
+
+Provide:
+- A short metrics table (before/after if available).
+- Top issues (ordered by impact).
+- Proposed fixes with estimated effort.
+
+Use `references/report-template.md` when formatting the final audit.
+
+## References
+
+- Profiling intake and collection checklist: `references/profiling-intake.md`
+- Common code smells and remediation patterns: `references/code-smells.md`
+- Audit output template: `references/report-template.md`
+- Add Apple documentation and WWDC resources under `references/` as they are supplied by the user.
+- Optimizing SwiftUI performance with Instruments: `references/optimizing-swiftui-performance-instruments.md`
+- Understanding and improving SwiftUI performance: `references/understanding-improving-swiftui-performance.md`
+- Understanding hangs in your app: `references/understanding-hangs-in-your-app.md`
+- Demystify SwiftUI performance (WWDC23): `references/demystify-swiftui-performance-wwdc23.md`

package/bundled-skills/swiftui-performance-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "SwiftUI Performance Audit"
+  short_description: "Audit SwiftUI runtime performance"
+  default_prompt: "Use $swiftui-performance-audit to review this SwiftUI code for performance issues and suggest concrete fixes."

package/bundled-skills/swiftui-performance-audit/references/code-smells.md

@@ -0,0 +1,150 @@
+# Common code smells and remediation patterns
+
+## Intent
+
+Use this reference during code-first review to map visible SwiftUI patterns to likely runtime costs and safer remediation guidance.
+
+## High-priority smells
+
+### Expensive formatters in `body`
+
+```swift
+var body: some View {
+    let number = NumberFormatter()
+    let measure = MeasurementFormatter()
+    Text(measure.string(from: .init(value: meters, unit: .meters)))
+}
+```
+
+Prefer cached formatters in a model or dedicated helper:
+
+```swift
+final class DistanceFormatter {
+    static let shared = DistanceFormatter()
+    let number = NumberFormatter()
+    let measure = MeasurementFormatter()
+}
+```
+
+### Heavy computed properties
+
+```swift
+var filtered: [Item] {
+    items.filter { $0.isEnabled }
+}
+```
+
+Prefer deriving this once per meaningful input change in a model/helper, or store derived view-owned state only when the view truly owns the transformation lifecycle.
+
+### Sorting or filtering inside `body`
+
+```swift
+List {
+    ForEach(items.sorted(by: sortRule)) { item in
+        Row(item)
+    }
+}
+```
+
+Prefer sorting before render work begins:
+
+```swift
+let sortedItems = items.sorted(by: sortRule)
+```
+
+### Inline filtering inside `ForEach`
+
+```swift
+ForEach(items.filter { $0.isEnabled }) { item in
+    Row(item)
+}
+```
+
+Prefer a prefiltered collection with stable identity.
+
+### Unstable identity
+
+```swift
+ForEach(items, id: \.self) { item in
+    Row(item)
+}
+```
+
+Avoid `id: \.self` for non-stable values or collections that reorder. Use a stable domain identifier.
+
+### Top-level conditional view swapping
+
+```swift
+var content: some View {
+    if isEditing {
+        editingView
+    } else {
+        readOnlyView
+    }
+}
+```
+
+Prefer one stable base view and localize conditions to sections or modifiers. This reduces root identity churn and makes diffing cheaper.
+
+### Image decoding on the main thread
+
+```swift
+Image(uiImage: UIImage(data: data)!)
+```
+
+Prefer decode and downsample work off the main thread, then store the processed image.
+
+## Observation fan-out
+
+### Broad `@Observable` reads on iOS 17+
+
+```swift
+@Observable final class Model {
+    var items: [Item] = []
+}
+
+var body: some View {
+    Row(isFavorite: model.items.contains(item))
+}
+```
+
+If many views read the same broad collection or root model, small changes can fan out into wide invalidation. Prefer narrower derived inputs, smaller observable surfaces, or per-item state closer to the leaf views.
+
+### Broad `ObservableObject` reads on iOS 16 and earlier
+
+```swift
+final class Model: ObservableObject {
+    @Published var items: [Item] = []
+}
+```
+
+The same warning applies to legacy observation. Avoid having many descendants observe a large shared object when they only need one derived field.
+
+## Remediation notes
+
+### `@State` is not a generic cache
+
+Use `@State` for view-owned state and derived values that intentionally belong to the view lifecycle. Do not move arbitrary expensive computation into `@State` unless you also define when and why it updates.
+
+Better alternatives:
+- precompute in the model or store
+- update derived state in response to a specific input change
+- memoize in a dedicated helper
+- preprocess on a background task before rendering
+
+### `equatable()` is conditional guidance
+
+Use `equatable()` only when:
+- equality is cheaper than recomputing the subtree, and
+- the view inputs are value-semantic and stable enough for meaningful equality checks
+
+Do not apply `equatable()` as a blanket fix for all redraws.
+
+## Triage order
+
+When multiple smells appear together, prioritize in this order:
+1. Broad invalidation and observation fan-out
+2. Unstable identity and list churn
+3. Main-thread work during render
+4. Image decode or resize cost
+5. Layout and animation complexity