buildanything 1.7.1 → 2.0.0

package/skills/ios/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/skills/ios/swiftui-performance-audit/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Thomas Ricouard
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

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

@@ -0,0 +1,111 @@
+---
+name: swiftui-performance-audit
+description: Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.
+---
+
+# 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.
+
+## 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`
+
+
+---
+
+Vendored from: https://github.com/Dimillian/Skills/tree/main/swiftui-performance-audit

package/skills/ios/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/skills/ios/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

package/skills/ios/swiftui-performance-audit/references/demystify-swiftui-performance-wwdc23.md

@@ -0,0 +1,46 @@
+# Demystify SwiftUI Performance (WWDC23) (Summary)
+
+Context: WWDC23 session on building a mental model for SwiftUI performance and triaging hangs/hitches.
+
+## Performance loop
+
+- Measure -> Identify -> Optimize -> Re-measure.
+- Focus on concrete symptoms (slow navigation, broken animations, spinning cursor).
+
+## Dependencies and updates
+
+- Views form a dependency graph; dynamic properties are a frequent source of updates.
+- Use `Self._printChanges()` in debug only to inspect extra dependencies.
+- Eliminate unnecessary dependencies by extracting views or narrowing state.
+- Consider `@Observable` for more granular property tracking.
+
+## Common causes of slow updates
+
+- Expensive view bodies (string interpolation, filtering, formatting).
+- Dynamic property instantiation and state initialization in `body`.
+- Slow identity resolution in lists/tables.
+- Hidden work: bundle lookups, heap allocations, repeated string construction.
+
+## Avoid slow initialization in view bodies
+
+- Don’t create heavy models synchronously in view bodies.
+- Use `.task` to fetch async data and keep `init` lightweight.
+
+## Lists and tables identity rules
+
+- Stable identity is critical for performance and animation.
+- Ensure a constant number of views per element in `ForEach`.
+- Avoid inline filtering in `ForEach`; pre-filter and cache collections.
+- Avoid `AnyView` in list rows; it hides identity and increases cost.
+- Flatten nested `ForEach` when possible to reduce overhead.
+
+## Table specifics
+
+- `TableRow` resolves to a single row; row count must be constant.
+- Prefer the streamlined `Table` initializer to enforce constant rows.
+- Use explicit IDs for back deployment when needed.
+
+## Debugging aids
+
+- Use Instruments for hangs and hitches.
+- Use `_printChanges` to validate dependency assumptions during debug.

package/skills/ios/swiftui-performance-audit/references/optimizing-swiftui-performance-instruments.md

@@ -0,0 +1,29 @@
+# Optimizing SwiftUI Performance with Instruments (Summary)
+
+Context: WWDC session introducing the next-generation SwiftUI Instrument in Instruments 26 and how to diagnose SwiftUI-specific bottlenecks.
+
+## Key takeaways
+
+- Profile SwiftUI issues with the SwiftUI template (SwiftUI instrument + Time Profiler + Hangs/Hitches).
+- Long view body updates are a common bottleneck; use "Long View Body Updates" to identify slow bodies.
+- Set inspection range on a long update and correlate with Time Profiler to find expensive frames.
+- Keep work out of `body`: move formatting, sorting, image decoding, and other expensive work into cached or precomputed paths.
+- Use Cause & Effect Graph to diagnose *why* updates occur; SwiftUI is declarative, so backtraces are often unhelpful.
+- Avoid broad dependencies that trigger many updates (e.g., `@Observable` arrays or global environment reads).
+- Prefer granular view models and scoped state so only the affected view updates.
+- Environment values update checks still cost time; avoid placing fast-changing values (timers, geometry) in environment.
+- Profile early and often during feature development to catch regressions.
+
+## Suggested workflow (condensed)
+
+1. Record a trace in Release mode using the SwiftUI template.
+2. Inspect "Long View Body Updates" and "Other Long Updates."
+3. Zoom into a long update, then inspect Time Profiler for hot frames.
+4. Fix slow body work by moving heavy logic into precomputed/cache paths.
+5. Use Cause & Effect Graph to identify unintended update fan-out.
+6. Re-record and compare the update counts and hitch frequency.
+
+## Example patterns from the session
+
+- Caching formatted distance strings in a location manager instead of computing in `body`.
+- Replacing a dependency on a global favorites array with per-item view models to reduce update fan-out.

package/skills/ios/swiftui-performance-audit/references/profiling-intake.md

@@ -0,0 +1,44 @@
+# Profiling intake and collection checklist
+
+## Intent
+
+Use this checklist when code review alone cannot explain the SwiftUI performance issue and you need runtime evidence from the user.
+
+## Ask for first
+
+- Exact symptom: CPU spike, dropped frames, memory growth, hangs, or excessive view updates.
+- Exact interaction: scrolling, typing, initial load, navigation push/pop, animation, sheet presentation, or background refresh.
+- Target device and OS version.
+- Whether the issue was reproduced on a real device or only in Simulator.
+- Build configuration: Debug or Release.
+- Whether the user already has a baseline or before/after comparison.
+
+## Default profiling request
+
+Ask the user to:
+- Run the app in a Release build when possible.
+- Use the SwiftUI Instruments template.
+- Reproduce the exact problematic interaction only long enough to capture the issue.
+- Capture the SwiftUI timeline and Time Profiler together.
+- Export the trace or provide screenshots of the key SwiftUI lanes and the Time Profiler call tree.
+
+## Ask for these artifacts
+
+- Trace export or screenshots of the relevant SwiftUI lanes
+- Time Profiler call tree screenshot or export
+- Device/OS/build configuration
+- A short note describing what action was happening at the time of the capture
+- If memory is involved, the memory graph or Allocations data if available
+
+## When to ask for more
+
+- Ask for a second capture if the first run mixes multiple interactions.
+- Ask for a before/after pair if the user has already tried a fix.
+- Ask for a device capture if the issue only appears in Simulator or if scrolling smoothness matters.
+
+## Common traps
+
+- Debug builds can distort SwiftUI timing and allocation behavior.
+- Simulator traces can miss device-only rendering or memory issues.
+- Mixed interactions in one capture make attribution harder.
+- Screenshots without the reproduction note are much harder to interpret.