@mmerterden/multi-agent-pipeline 20.17.1 → 20.17.2

package/pipeline/skills/shared/external/hig-platforms/references/ipad-layout.md

@@ -0,0 +1,218 @@
+# iPad layout and windowing
+
+Companion to `../SKILL.md` for the `hig-platforms` skill: how one SwiftUI
+layout adapts from a narrow iPad window to a full external display. Hinged
+iPhone hardware (iPhone Duo) has its own skill, `ios-iphone-duo`.
+
+## Contents
+
+1. [Windows on iPadOS 26](#1-windows-on-ipados-26)
+2. [Size classes, not devices](#2-size-classes-not-devices)
+3. [Choosing a layout tool](#3-choosing-a-layout-tool)
+4. [ViewThatFits](#4-viewthatfits)
+5. [AnyLayout](#5-anylayout)
+6. [A custom Layout](#6-a-custom-layout)
+7. [Scenes, multiple windows and the menu bar](#7-scenes-multiple-windows-and-the-menu-bar)
+8. [Test matrix](#8-test-matrix)
+
+## 1. Windows on iPadOS 26
+
+People choose one of two presentations in Multitasking settings:
+
+- **Full screen**: app windows fill the screen; people switch with the app
+  switcher.
+- **Windowed**: people resize windows freely, keep several on screen,
+  reposition them and bring them to front. The system remembers size and
+  placement.
+
+What this means for layout:
+
+- Support arbitrary sizes. Windows resize fluidly down to a minimum rather
+  than snapping between preset sizes, so a layout cannot assume a short list of
+  widths. Stage Manager (iPadOS 16 and later on supported iPads) already
+  required this.
+- `UIRequiresFullScreen` is deprecated in iPadOS 26. In windowed mode it no
+  longer gives a full-screen app; the system keeps a fixed scene size and
+  scales the app when people resize. Apple asks iPad apps to support
+  multitasking and dynamic resizing instead.
+- Keep leading toolbar items clear of the window controls that appear at the
+  leading edge of the toolbar in windowed mode; move such buttons inward.
+- Set a sensible minimum (and, where useful, maximum) size so the layout never
+  overlaps: `UISceneSizeRestrictions.minimumSize` in UIKit,
+  `.windowResizability(_:)` and `.defaultSize(_:)` on scenes in SwiftUI
+  (iOS 17).
+- Use standard split views: `NavigationSplitView` reflows its columns for every
+  width with system transitions.
+
+## 2. Size classes, not devices
+
+| Context | Horizontal | Vertical |
+|---|---|---|
+| iPad full screen, either orientation | regular | regular |
+| iPad window narrowed to a phone-like width | compact | regular |
+| iPhone portrait | compact | regular |
+| iPhone landscape (most models) | compact | compact |
+
+Read `@Environment(\.horizontalSizeClass)` and `verticalSizeClass`; never
+branch on the device model or on `UIDevice.current.userInterfaceIdiom` for
+layout. A size class says whether there is room for more columns; the
+container's actual size decides the details.
+
+```swift
+@Environment(\.horizontalSizeClass) private var widthClass
+
+var body: some View {
+    if widthClass == .compact {
+        JobList(jobs: jobs)
+    } else {
+        NavigationSplitView {
+            JobList(jobs: jobs)
+        } detail: {
+            JobDetailPlaceholder()
+        }
+    }
+}
+```
+
+`NavigationSplitView` already collapses to a stack in compact width, so the
+branch above is only needed when the compact design differs.
+
+## 3. Choosing a layout tool
+
+| Question | Tool (since) |
+|---|---|
+| Does a list-detail hierarchy need columns? | `NavigationSplitView` (iOS 16) |
+| Which of a few fixed arrangements fits the space? | `ViewThatFits` (iOS 16) |
+| Switch between stack axes while keeping state and animating? | `AnyLayout` (iOS 16) |
+| Size a view relative to its container? | `containerRelativeFrame(_:alignment:)` (iOS 17) |
+| A layout no stack or grid expresses? | A type conforming to `Layout` (iOS 16) |
+| Readable width for long text in a wide window? | `.contentMargins` (iOS 17) or a max width |
+
+Reach for `GeometryReader` last; it takes all offered space and couples the
+view to raw sizes.
+
+## 4. ViewThatFits
+
+Picks the first child that fits the proposed size along the given axes.
+
+```swift
+ViewThatFits(in: .horizontal) {
+    HStack(spacing: 12) {
+        JobSummary(job: job)
+        Spacer()
+        JobActions(job: job)
+    }
+    VStack(alignment: .leading, spacing: 8) {
+        JobSummary(job: job)
+        JobActions(job: job)
+    }
+}
+```
+
+Each candidate is a separate subtree: state inside one is lost when the other
+wins. Keep state above `ViewThatFits`.
+
+## 5. AnyLayout
+
+Wraps a layout type so the arrangement can change while view identity, and so
+state, survives, and the change can animate.
+
+```swift
+@Environment(\.horizontalSizeClass) private var widthClass
+@Environment(\.dynamicTypeSize) private var typeSize
+
+var body: some View {
+    let isNarrow = widthClass == .compact || typeSize.isAccessibilitySize
+    let layout = isNarrow
+        ? AnyLayout(VStackLayout(alignment: .leading, spacing: 12))
+        : AnyLayout(HStackLayout(alignment: .top, spacing: 20))
+
+    layout {
+        PartsList(parts: job.parts)
+        PhotoStrip(photos: job.photos)
+    }
+    .animation(.smooth, value: isNarrow)
+}
+```
+
+`HStackLayout`, `VStackLayout`, `ZStackLayout` and `GridLayout` are the
+built-in layout types to swap between.
+
+## 6. A custom Layout
+
+Conform to `Layout` and implement `sizeThatFits(proposal:subviews:cache:)` and
+`placeSubviews(in:proposal:subviews:cache:)`. A flow layout that wraps chips
+onto new lines is the usual case:
+
+```swift
+struct FlowLayout: Layout {
+    var spacing: CGFloat = 8
+
+    func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) -> CGSize {
+        let maxWidth = proposal.width ?? .infinity
+        var origin = CGPoint.zero
+        var lineHeight: CGFloat = 0
+        var usedWidth: CGFloat = 0
+        for subview in subviews {
+            let size = subview.sizeThatFits(.unspecified)
+            if origin.x > 0, origin.x + size.width > maxWidth {
+                origin.x = 0
+                origin.y += lineHeight + spacing
+                lineHeight = 0
+            }
+            origin.x += size.width + spacing
+            usedWidth = max(usedWidth, origin.x - spacing)
+            lineHeight = max(lineHeight, size.height)
+        }
+        return CGSize(width: usedWidth, height: origin.y + lineHeight)
+    }
+
+    func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) {
+        var origin = bounds.origin
+        var lineHeight: CGFloat = 0
+        for subview in subviews {
+            let size = subview.sizeThatFits(.unspecified)
+            if origin.x > bounds.minX, origin.x + size.width > bounds.maxX {
+                origin.x = bounds.minX
+                origin.y += lineHeight + spacing
+                lineHeight = 0
+            }
+            subview.place(at: origin, proposal: ProposedViewSize(size))
+            origin.x += size.width + spacing
+            lineHeight = max(lineHeight, size.height)
+        }
+    }
+}
+```
+
+A custom layout works with `AnyLayout` too, so it can be swapped in for wide
+windows only.
+
+## 7. Scenes, multiple windows and the menu bar
+
+- Support multiple windows when people might compare two records
+  (`UIApplicationSupportsMultipleScenes`, `WindowGroup(for:)` with a value,
+  `openWindow(value:)`). Offer "Open in New Window" in a context menu rather
+  than opening windows by default.
+- iPadOS 26 adds a menu bar; populate it with `.commands` on the scene, as on
+  the Mac, and give frequent commands keyboard shortcuts.
+- Use the word "window" in user-facing text, never "scene".
+- Do not build custom window frames or controls.
+
+## 8. Test matrix
+
+1. Full screen, portrait and landscape.
+2. Windowed at the minimum size, a phone-like width and a wide width; resize
+   slowly and watch for jumps.
+3. External display.
+4. Largest Dynamic Type size in a narrow window.
+5. Right-to-left: sidebars, swipe edges and back gestures mirror.
+
+Sources:
+[HIG: Windows](https://developer.apple.com/design/human-interface-guidelines/windows),
+[HIG: Layout](https://developer.apple.com/design/human-interface-guidelines/layout),
+[Adopting Liquid Glass: windows and modals](https://developer.apple.com/documentation/technologyoverviews/adopting-liquid-glass),
+[UIRequiresFullScreen](https://developer.apple.com/documentation/bundleresources/information-property-list/uirequiresfullscreen),
+[ViewThatFits](https://developer.apple.com/documentation/swiftui/viewthatfits),
+[AnyLayout](https://developer.apple.com/documentation/swiftui/anylayout),
+[Layout](https://developer.apple.com/documentation/swiftui/layout).

package/pipeline/skills/shared/external/ios-accessibility/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ios-accessibility
-description: "VoiceOver, Voice Control, Switch Control and Full Keyboard Access in SwiftUI, UIKit and AppKit on iOS, iPadOS and macOS: labels, hints, values, traits, accessibilityInputLabels, NSAccessibility, grouping and reading order, @AccessibilityFocusState focus restore, Dynamic Type and @ScaledMetric, rotors, custom actions, XCTest accessibility checks, system accessibility preferences, Accessibility Nutrition Labels and App Store Connect answers. Use when implementing, reviewing or auditing accessibility (a11y). Not for keyboard or directional focus mechanics (Tab order, FocusState, UIFocusGuide): use hig-inputs."
+description: "VoiceOver, Voice Control, Switch Control and Full Keyboard Access in SwiftUI, UIKit and AppKit: labels, traits, grouping, focus restore, Dynamic Type, Large Content Viewer, rotors, custom actions, accessibility checks and Nutrition Labels. Use when implementing, reviewing or auditing accessibility (a11y). Not for keyboard or directional focus mechanics: use hig-inputs."
 metadata:
   source: multi-agent-pipeline
 ---
@@ -23,6 +23,9 @@ References:
   label categories and what passes or fails each one.
 - [Media](references/media-accessibility.md): captions, SDH, audio
   descriptions and `AVMediaCharacteristic`.
+- [Large content and appearance](references/large-content-and-appearance.md):
+  the Large Content Viewer for controls that cannot grow, and how Liquid
+  Glass reacts to Reduce Transparency, Increase Contrast and Reduce Motion.
 
 ## Ground rules
 

package/pipeline/skills/shared/external/ios-accessibility/references/large-content-and-appearance.md

@@ -0,0 +1,135 @@
+# Large Content Viewer, and Liquid Glass with appearance settings
+
+Companion to `../SKILL.md` for the `ios-accessibility` skill.
+
+## Contents
+
+1. [Large Content Viewer](#1-large-content-viewer)
+2. [SwiftUI](#2-swiftui)
+3. [UIKit](#3-uikit)
+4. [Liquid Glass and appearance settings](#4-liquid-glass-and-appearance-settings)
+5. [Checks](#5-checks)
+
+## 1. Large Content Viewer
+
+When text is set to one of the large accessibility sizes, some controls cannot
+grow without breaking the screen: tab bar items, toolbar buttons, segmented
+controls, a compact player bar. For those, the Large Content Viewer shows an
+enlarged label and image in the middle of the screen while the person presses
+and holds the control. System tab bars and toolbars do this already.
+
+Rules from Apple's documentation:
+
+- It is not a replacement for Dynamic Type. Lists, rows and body text must
+  grow; use the viewer only where an element must stay small for a real
+  design reason.
+- Views whose Dynamic Type size is capped with `dynamicTypeSize(_:)` are the
+  typical candidates.
+- If the control also has a long-press action, lengthen that press when the
+  viewer is enabled so people can read the enlarged content first.
+
+## 2. SwiftUI
+
+| API | Since | Use |
+|---|---|---|
+| `accessibilityShowsLargeContentViewer()` | iOS 15 | Default large content built from the view's label and image |
+| `accessibilityShowsLargeContentViewer(_:)` | iOS 15 | Custom large content, for example a `Label` for an icon-only button |
+| `@Environment(\.accessibilityLargeContentViewerEnabled)` | iOS 15 | Whether the viewer is on, to adjust coexisting gestures |
+
+```swift
+struct PlayerBar: View {
+    @Environment(\.accessibilityLargeContentViewerEnabled) private var largeContentViewer
+
+    var body: some View {
+        HStack(spacing: 24) {
+            Button(action: skipBack) {
+                Image(systemName: "gobackward.15")
+            }
+            .accessibilityLabel("Skip back 15 seconds")
+            .accessibilityShowsLargeContentViewer {
+                Label("Skip back 15 seconds", systemImage: "gobackward.15")
+            }
+
+            Button("Play", systemImage: "play.fill", action: play)
+                .labelStyle(.iconOnly)
+                .accessibilityShowsLargeContentViewer()
+        }
+        .dynamicTypeSize(...DynamicTypeSize.xxxLarge)
+        .onLongPressGesture(minimumDuration: largeContentViewer ? 1.2 : 0.5) {
+            showQueue()
+        }
+    }
+}
+```
+
+The cap keeps the bar's layout fixed; the viewer gives the enlarged reading
+back.
+
+## 3. UIKit
+
+| API | Since | Use |
+|---|---|---|
+| `UILargeContentViewerInteraction` | iOS 13 | Adds the press-and-hold gesture to a container view |
+| `UIView.showsLargeContentViewer` | iOS 13 | Opts a view in |
+| `UIView.largeContentTitle`, `largeContentImage` | iOS 13 | What the viewer shows |
+| `UIView.scalesLargeContentImage` | iOS 13 | Scale the image up (useful for template symbols) |
+| `UILargeContentViewerInteraction.isEnabled` | iOS 13 | Whether the viewer is on |
+
+Bar items in system bars are covered by the system. For custom controls, set
+the properties on the view and add the interaction to its container:
+
+```swift
+final class CompactPlayerBar: UIView {
+    private let skipBackButton = UIButton(type: .system)
+
+    override init(frame: CGRect) {
+        super.init(frame: frame)
+        skipBackButton.setImage(UIImage(systemName: "gobackward.15"), for: .normal)
+        skipBackButton.accessibilityLabel = String(localized: "Skip back 15 seconds")
+        skipBackButton.showsLargeContentViewer = true
+        skipBackButton.largeContentTitle = String(localized: "Skip back 15 seconds")
+        skipBackButton.largeContentImage = UIImage(systemName: "gobackward.15")
+        skipBackButton.scalesLargeContentImage = true
+        addSubview(skipBackButton)
+        addInteraction(UILargeContentViewerInteraction())
+    }
+
+    required init?(coder: NSCoder) {
+        fatalError("init(coder:) is not supported")
+    }
+}
+```
+
+## 4. Liquid Glass and appearance settings
+
+On Apple's 26 releases, people can pick a preferred look for Liquid Glass in
+Settings and can turn on Reduce Transparency, Increase Contrast or Reduce
+Motion. Each can remove or modify glass effects. System bars, sheets and
+controls adapt by themselves; custom glass and custom colors do not always.
+
+| Setting | SwiftUI | UIKit | What custom UI must do |
+|---|---|---|---|
+| Reduce Transparency | `accessibilityReduceTransparency` | `UIAccessibility.isReduceTransparencyEnabled` | Text over custom glass or blur stays readable; switch to an opaque fill where it does not |
+| Increase Contrast | `colorSchemeContrast == .increased` | `UIAccessibility.isDarkerSystemColorsEnabled` | Custom colors provide increased-contrast variants; contrast minimums hold |
+| Reduce Motion | `accessibilityReduceMotion` | `UIAccessibility.isReduceMotionEnabled` | Glass morphing and custom transitions become simple fades or instant changes |
+| Bold Text | `legibilityWeight == .bold` | `UIAccessibility.isBoldTextEnabled` | Custom-drawn text follows the heavier weight |
+
+Glass-specific checks (clear glass and its dimming layer, tint contrast, no
+opaque fills behind system bars) and the material rules (where glass belongs,
+regular versus clear, fallbacks) are in `swiftui-liquid-glass`.
+
+## 5. Checks
+
+- Set an accessibility text size, then press and hold every small fixed
+  control (tab items, toolbar buttons, player controls): the viewer appears
+  with a meaningful title and image.
+- Rows and body text grow instead of relying on the viewer.
+- Turn on Reduce Transparency, Increase Contrast and Reduce Motion one at a
+  time and walk every screen with custom glass.
+- The screenshot matrix for a design review lives in `ios-design-review`.
+
+Sources:
+[accessibilityShowsLargeContentViewer()](https://developer.apple.com/documentation/swiftui/view/accessibilityshowslargecontentviewer()),
+[UILargeContentViewerInteraction](https://developer.apple.com/documentation/uikit/uilargecontentviewerinteraction),
+[HIG: Materials](https://developer.apple.com/design/human-interface-guidelines/materials),
+[Adopting Liquid Glass](https://developer.apple.com/documentation/technologyoverviews/adopting-liquid-glass).

package/pipeline/skills/shared/external/ios-design-review/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: ios-design-review
+description: "Design critique and screenshot-based visual QA of iOS screens against the HIG, checked across light and dark, Dynamic Type, RTL, contrast and transparency settings with simulator tools. Use when asking whether a screen looks right, wanting a design pass on screenshots or a build, or visual QA before release, not a Swift code review."
+metadata:
+  source: multi-agent-pipeline
+  date_added: "2026-10-08"
+  not-for: swiftui-pro, ios-accessibility
+---
+
+# iOS design review
+
+A design review looks at what people see and touch: the rendered screen, in
+every appearance it can take. It answers "does this screen meet the platform's
+design bar, and where does it fall short", with evidence a designer or
+developer can act on. It is not a code review; reading Swift for API misuse is
+`swiftui-pro`'s job, and building accessibility support is `ios-accessibility`'s.
+
+The reason to keep the two apart: code that looks correct can still render
+badly (a fixed frame that clips at the largest text size, a tint that fails
+contrast in dark mode), and odd-looking code can render well. Only the screen
+settles a design question.
+
+## Where this sits
+
+| Need | Go to |
+|---|---|
+| Critique a screen against HIG, any appearance | this skill |
+| Pixel and spacing conformance to a Figma frame, every state, mock mode | `/multi-agent:design-check` |
+| One-axis sweep of a whole app | `/multi-agent:test-dark-mode`, `/multi-agent:test-dynamic-type`, `/multi-agent:test-accessibility` |
+| Store screenshot set | `/multi-agent:test-screenshots` |
+| Review the SwiftUI code | `swiftui-pro` |
+| Implement VoiceOver, traits, focus | `ios-accessibility` |
+| Implement or fix Liquid Glass | `swiftui-liquid-glass` |
+| Icons, symbols, haptics, foldable layout | `hig-app-icons`, `ios-sf-symbols`, `ios-haptics`, `ios-iphone-duo` |
+
+Use the commands for breadth (every screen, one axis) and this skill for depth
+(one flow, every axis, judged against the guidelines). When a command already
+produced captures, review those instead of recapturing.
+
+## Inputs and honesty
+
+Accept whatever exists: screenshots, a running simulator, a design render on
+disk, or the source. Say up front which you have, because it bounds what can be
+proven:
+
+- Screenshots only: layout, hierarchy, copy and visible contrast can be judged;
+  touch target sizes, accessibility labels and behaviour cannot.
+- A running simulator: add the accessibility tree (`ios_get_ui_tree`) and
+  element geometry (`design_ui_geometry`) to measure targets and spacing.
+- Source as well: findings can be pinned to `file:line`.
+- A design render: `design_visual_compare` measures insets, gaps and colour
+  against it. Without one, judge against HIG alone and say so.
+
+## The review
+
+Walk the layers in `references/checklist.md`, in order. Each layer has the
+questions to ask and the HIG page that backs them. In short:
+
+1. **Layout**: content inside safe areas, backgrounds may extend past them;
+   consistent margins; alignment; nothing tappable under bars; adapts to width
+   instead of assuming a device size.
+2. **Typography**: text styles rather than fixed sizes, iOS default 17 pt and
+   minimum 11 pt, hierarchy through weight and size, no truncation that hides
+   meaning at large sizes.
+3. **Colour and contrast**: semantic colours, at least 4.5:1 for text up to
+   17 pt and 3:1 for 18 pt or bold, meaning never carried by colour alone.
+4. **Materials and Liquid Glass**: glass on the navigation and control layer,
+   standard materials in the content layer, clear glass only over rich media
+   with a dimming layer when the media is bright.
+5. **Iconography**: SF Symbols weight and scale matched to adjacent text,
+   consistent variants, labels on icon-only controls.
+6. **Navigation and bars**: system bars and tab bars, standard placements,
+   back and close where people expect them.
+7. **Controls and touch**: 44x44 pt default target, 28x28 pt minimum, spacing
+   between adjacent targets, standard controls where they exist.
+8. **Feedback and motion**: every action acknowledged, motion that explains
+   rather than decorates, a reduced alternative under Reduce Motion.
+9. **States**: empty, loading, error, offline, permission denied, long content.
+10. **Content and copy**: short, specific, consistent terms, localized.
+
+## The appearance matrix
+
+A screen is reviewed in each appearance it can take, because each one breaks
+different things. `references/appearance-matrix.md` has, for every row, how to
+set it (toolkit tool or manual setting) and what typically goes wrong.
+
+| Appearance | Set with | Typical failures |
+|---|---|---|
+| Light, dark | `ios_set_appearance` | hard-coded colours, invisible separators, images without a dark variant |
+| Dynamic Type, default to AX5 | `ios_set_content_size` | clipping, truncation, overlapping, fixed-height rows, layouts that never switch to vertical |
+| Right-to-left | `ios_set_locale` with `ar` or `he` (relaunch) | unflipped back chevrons and progress, mirrored artwork, left-aligned text |
+| Increase Contrast | `ios_set_increase_contrast` | custom colours with no high-contrast variant |
+| Reduce Transparency | Settings app, set by hand | glass or blur that does not fall back to an opaque surface |
+| Reduce Motion | Settings app, set by hand | parallax, zooms and repeating symbol effects still playing |
+| Liquid Glass look (Clear or Tinted) | Settings > Display & Brightness, by hand | custom glass that ignores the setting, legibility on Clear |
+
+Not every screen needs every cell. Pick the cells the screen can break (a
+text-heavy form needs every Dynamic Type step; a media player needs Reduce
+Motion and Clear glass), list the ones you skipped and why, and record which
+were set by hand.
+
+## Procedure on a simulator
+
+1. Clean the status bar: `ios_status_bar` with preset `clean`, so captures
+   compare across runs.
+2. Reach the screen with `ui_locate` and `ios_tap_element` rather than
+   coordinates. A locator that resolves to exactly one element survives layout
+   changes; a coordinate does not.
+3. Baseline capture: `ios_screenshot`, `ios_get_ui_tree`, `design_ui_geometry`.
+4. For each chosen matrix cell: set it, wait for the UI to settle, capture
+   again. Batch the sweep with `agent_run_steps` and add `expect_text` or
+   `expect_element` steps so a navigation slip fails the batch instead of
+   producing captures of the wrong screen.
+5. Measure: target sizes and gaps from geometry, contrast from the capture,
+   insets and spacing against the design with `design_visual_compare` when a
+   render exists.
+6. Reset what you changed (appearance, content size, contrast, locale) so the
+   next run starts clean.
+
+The full step list with arguments is in `references/appearance-matrix.md`.
+
+## Reporting
+
+One finding per problem, each with:
+
+- **Layer** from the checklist and **severity**: blocking (unusable, illegible,
+  inaccessible, or a guideline the store enforces), important (clearly below
+  the HIG bar), suggestion (polish).
+- **Where**: `file:line` when the source is known, otherwise screen, element
+  and the matrix cell it appears in.
+- **Evidence**: capture path, UI tree node, measured value against the
+  threshold (for example "close button 32x32 pt, minimum 44x44 pt").
+- **Why it matters** in one sentence, and the **fix direction**.
+
+End with a **Not proven** section: what could not be checked and why (no
+device, setting not available, screenshot-only input, behaviour that needs a
+real device such as haptics). A short honest list is worth more than a long
+confident one. `references/checklist.md` has a report template.
+
+## References
+
+- `references/checklist.md`: the layer-by-layer checklist, thresholds, report template.
+- `references/appearance-matrix.md`: setting each appearance, toolkit procedure, failure catalogue.
+- HIG: https://developer.apple.com/design/human-interface-guidelines/
+- Accessibility thresholds: https://developer.apple.com/design/human-interface-guidelines/accessibility
+- Materials: https://developer.apple.com/design/human-interface-guidelines/materials

package/pipeline/skills/shared/external/ios-design-review/evals/evals.json

@@ -0,0 +1,48 @@
+{
+  "skill_name": "ios-design-review",
+  "evals": [
+    {
+      "id": 0,
+      "name": "settings-screen-matrix-review",
+      "prompt": "Our redesigned Settings screen ships next week. I have the app running on an iPhone 17 simulator with the multi-agent-toolkit MCP connected. Give it a proper design pass, not a code review: tell me what to check, how you would capture it, and what the report should look like.",
+      "expected_output": "Treats the task as a visual design review rather than code review. Chooses relevant appearance-matrix cells (light and dark, Dynamic Type including an accessibility size such as AX5, right-to-left, Increase Contrast, Reduce Transparency, Reduce Motion, Liquid Glass look) and says which can be set with toolkit tools (ios_set_appearance, ios_set_content_size, ios_set_increase_contrast, ios_set_locale) and which must be set by hand in Settings. Navigates with ui_locate and ios_tap_element, captures with ios_screenshot, ios_get_ui_tree and design_ui_geometry, and guards a batch with expect_element or expect_text. Applies HIG thresholds (44x44 pt targets, 4.5:1 text contrast, 17 pt default text). Reports findings with layer, severity, location, evidence and fix, and ends with a Not proven section.",
+      "files": [],
+      "expectations": [
+        "Frames the work as a rendered-screen design review, not a Swift code review",
+        "Covers dark mode and at least one accessibility Dynamic Type size",
+        "Names toolkit tools for setting appearances (ios_set_appearance, ios_set_content_size or ios_set_increase_contrast)",
+        "States that Reduce Transparency, Reduce Motion or the Liquid Glass look have no toolkit switch and are set by hand",
+        "Uses at least one concrete HIG threshold such as 44x44 pt or 4.5:1",
+        "Report format includes evidence per finding and a section for what could not be proven"
+      ]
+    },
+    {
+      "id": 1,
+      "name": "screenshot-only-critique",
+      "prompt": "Here are three screenshots of our checkout flow (light mode only, default text size). The designer says it is ready. Can you critique it against Apple's guidelines and tell me if it is shippable?",
+      "expected_output": "Reviews what screenshots can show (layout, hierarchy, contrast, copy, glass use, symbol consistency) and explicitly states the limits: touch target hit areas, accessibility labels, dark mode, large text, right-to-left and behaviour cannot be judged from three light-mode captures. Does not declare it shippable; lists the missing matrix cells as Not proven and recommends capturing them or running the test-dark-mode and test-dynamic-type commands.",
+      "files": [],
+      "expectations": [
+        "States what cannot be proven from light-mode, default-size screenshots",
+        "Does not declare the flow shippable without the missing appearances",
+        "Mentions dark mode and large Dynamic Type as unchecked",
+        "Points to the dark-mode or dynamic-type test commands, or to capturing those cells",
+        "Keeps findings tied to visible evidence rather than speculation about the code"
+      ]
+    },
+    {
+      "id": 2,
+      "name": "glass-and-contrast-judgement",
+      "prompt": "Design review question: our photo viewer puts a toolbar with clear Liquid Glass over full-screen photos, and the product cards on the home feed also use glassEffect as their background. Text on the toolbar is sometimes hard to read on bright photos. What does Apple's guidance say, and how should the review report it?",
+      "expected_output": "Says Liquid Glass belongs to the navigation and control layer and that content-layer cards should use standard materials, so the card backgrounds are a finding. Accepts clear glass over rich media for the photo toolbar but recommends a dark dimming layer of about 35% when the photo is bright. Suggests checking with the Liquid Glass look set to Clear and Tinted and with Reduce Transparency, and routes the implementation fix to swiftui-liquid-glass. Reports with layer, severity, evidence and fix direction.",
+      "files": [],
+      "expectations": [
+        "Flags glass on content cards as a content-layer misuse",
+        "Recommends standard materials for the content layer",
+        "Recommends a dimming layer of about 35% behind clear glass over bright media",
+        "Mentions checking under Reduce Transparency or the Clear and Tinted look setting",
+        "Routes implementation to swiftui-liquid-glass rather than writing the fix as the review"
+      ]
+    }
+  ]
+}

package/pipeline/skills/shared/external/ios-design-review/evals/trigger-eval.json

@@ -0,0 +1,22 @@
+[
+  { "query": "Can you do a design review of these screenshots of our onboarding?", "should_trigger": true },
+  { "query": "Check whether the profile screen looks right in dark mode and at the largest text size on the simulator", "should_trigger": true },
+  { "query": "Visual QA pass on the checkout flow before release, against the HIG", "should_trigger": true },
+  { "query": "Is this settings screen up to Apple's design bar? Tell me what looks off", "should_trigger": true },
+  { "query": "Critique the spacing, typography and contrast of this iOS screen", "should_trigger": true },
+  { "query": "Run through the appearance matrix for the home screen: RTL, Increase Contrast, Reduce Transparency", "should_trigger": true },
+  { "query": "Does our use of Liquid Glass on the feed look right, design-wise?", "should_trigger": true },
+  { "query": "Take screenshots of the order screen in light and dark and tell me what fails the guidelines", "should_trigger": true },
+  { "query": "Our designer wants a second opinion on the new tab bar layout, here is a capture", "should_trigger": true },
+  { "query": "Review the rendered login screen for touch target sizes and text contrast", "should_trigger": true },
+  { "query": "Review this SwiftUI view's code for deprecated APIs and performance issues", "should_trigger": false },
+  { "query": "Add VoiceOver labels and accessibility traits to our custom slider", "should_trigger": false },
+  { "query": "Compare every state of the payment module against the Figma frames in mock mode and export the report", "should_trigger": false },
+  { "query": "Generate the App Store screenshot set in German", "should_trigger": false },
+  { "query": "Implement glassEffect on our floating action button", "should_trigger": false },
+  { "query": "Which SF Symbol rendering mode should I use for a battery indicator?", "should_trigger": false },
+  { "query": "Design our app icon's dark and tinted variants in Icon Composer", "should_trigger": false },
+  { "query": "Review my pull request diff for bugs", "should_trigger": false },
+  { "query": "Walk every screen of the app at accessibility-extra-large and list truncation bugs", "should_trigger": false },
+  { "query": "Make our app ready for the foldable iPhone's hinge and reserved regions", "should_trigger": false }
+]