@mmerterden/multi-agent-pipeline 20.17.1 → 20.18.0

package/pipeline/skills/shared/external/ios-design-review/references/appearance-matrix.md

@@ -0,0 +1,135 @@
+# Appearance matrix and simulator procedure
+
+How to put a simulator into each appearance, what to look for in it, and a
+toolkit procedure that sweeps the matrix for one screen. Tool names are from
+the multi-agent-toolkit MCP server (3.19.0 or later).
+
+## Contents
+
+1. Setting each appearance
+2. What breaks in each appearance
+3. Sweep procedure
+4. Example batch
+5. Limits of a simulator review
+
+## 1. Setting each appearance
+
+| Appearance | Toolkit call | Notes |
+|---|---|---|
+| Light | `ios_set_appearance` `mode: "light"` | |
+| Dark | `ios_set_appearance` `mode: "dark"` | |
+| Dynamic Type | `ios_set_content_size` `size: ...` | standard steps `extra-small` to `extra-extra-extra-large`; accessibility steps `accessibility-medium` to `accessibility-extra-extra-extra-large` (AX1 to AX5) |
+| Increase Contrast | `ios_set_increase_contrast` `enabled: true` | |
+| Right-to-left | `ios_set_locale` `language: "ar"` or `"he"`, `bundle_id` | relaunches the app; copy must exist in that language or the screen shows the development language left-to-right |
+| Reduce Transparency | none | Settings > Accessibility > Display & Text Size, set by hand |
+| Reduce Motion | none | Settings > Accessibility > Motion, set by hand |
+| Liquid Glass look | none | Settings > Display & Brightness > Liquid Glass, Clear or Tinted; check the current Settings wording, set by hand where the OS offers it |
+| Clean status bar | `ios_status_bar` `preset: "clean"` | revert with `preset: "clear"` |
+
+Apple notes that the Liquid Glass look cannot be changed while Reduce
+Transparency or Increase Contrast is on, because those settings already take
+precedence. Review the look setting with both of them off, and review each
+accessibility setting on its own.
+
+A cell set by hand goes into the report as "set by hand", so a reader knows it
+was not scripted and may not be reproduced by the next run.
+
+## 2. What breaks in each appearance
+
+**Dark.** Fixed colours (a grey that vanishes on near-black), separators and
+borders that disappear, shadows that read as dirt, images and illustrations
+with no dark variant, white logo boxes. Check elevated surfaces: sheets and
+popovers use slightly lighter backgrounds in dark mode.
+
+**Dynamic Type.** Check at least the default (`large`), the largest standard
+step and AX5. Look for clipped labels in fixed-height rows and buttons,
+truncation that hides meaning, overlapping text, horizontal stacks that never
+switch to vertical, icons that stay tiny next to huge text, and controls pushed
+off screen with no scroll.
+
+**Right-to-left.** Back chevrons and disclosure indicators must point the
+other way; progress bars and sliders run right to left; text aligns to the
+trailing edge. Photos, artwork, media playback controls and numerals are not
+mirrored. Hard-coded left and right paddings show up as lopsided insets.
+
+**Increase Contrast.** Custom colours need a high-contrast variant; system
+colours already have one. Thin borders and subtle fills that carried meaning
+should become more visible, not stay the same.
+
+**Reduce Transparency.** Blur and glass should resolve to opaque or nearly
+opaque surfaces. Custom translucent overlays that keep their transparency are
+the usual finding.
+
+**Reduce Motion.** Parallax, zooming transitions, spinning and bouncing
+decorations and auto-playing repeating symbol effects should be replaced by
+fades or stop. Motion that conveys essential state may stay, toned down.
+
+**Liquid Glass look.** On Clear, check legibility of text and symbols on
+glass over the busiest content behind it. On Tinted, custom glass should gain
+opacity like system glass does.
+
+## 3. Sweep procedure
+
+1. Confirm a booted simulator and the app's bundle id. Note device model and
+   iOS version for the report.
+2. `ios_status_bar` `preset: "clean"`.
+3. Navigate to the screen. Build each locator with `ui_locate` until it
+   resolves to exactly one element (`code: OK`), then act with
+   `ios_tap_element`. Prefer an accessibility identifier (`id`) over a label,
+   because labels change with locale.
+4. Baseline: `ios_screenshot` with a `path` (full-resolution PNG on disk),
+   `ios_get_ui_tree` with a `path`, `design_ui_geometry` `platform: "ios"`.
+5. For each chosen cell: set it, wait for the screen to settle, assert you are
+   still on the right screen (`expect_element` on a stable identifier), then
+   capture as in step 4 with the cell in the file name.
+6. Measure:
+   - Targets and gaps from `design_ui_geometry` boxes (points).
+   - Contrast by sampling text and background colours in the PNG.
+   - Against a design render, when one exists on disk:
+     `design_visual_compare` with `figma_png`, `live_png`, `out_dir`, plus
+     `figma_frame`, `live_screen` and `live_geometry` for inset and gap
+     findings in points.
+7. Reset: `ios_set_appearance` light, `ios_set_content_size` `large`,
+   `ios_set_increase_contrast` false, the original locale, `ios_status_bar`
+   `preset: "clear"`, and any setting changed by hand.
+
+## 4. Example batch
+
+`agent_run_steps` runs a sweep as one call and stops on the first failed
+assertion, so a missed tap cannot produce a set of captures of the wrong
+screen. Paths and identifiers below are placeholders.
+
+```json
+{
+  "steps": [
+    { "tool": "ios_status_bar", "args": { "preset": "clean" } },
+    { "tool": "ios_tap_element", "args": { "locator": { "id": "tab.profile" } } },
+    { "tool": "expect_element", "args": { "platform": "ios", "locator": { "id": "profile.header" } } },
+    { "tool": "ios_screenshot", "args": { "path": "/abs/captures/profile-light-large.png" } },
+    { "tool": "ios_set_appearance", "args": { "mode": "dark" }, "wait_ms": 800 },
+    { "tool": "ios_screenshot", "args": { "path": "/abs/captures/profile-dark-large.png" } },
+    { "tool": "ios_set_content_size", "args": { "size": "accessibility-extra-extra-extra-large" }, "wait_ms": 800 },
+    { "tool": "expect_element", "args": { "platform": "ios", "locator": { "id": "profile.header" } } },
+    { "tool": "ios_screenshot", "args": { "path": "/abs/captures/profile-dark-ax5.png" } },
+    { "tool": "design_ui_geometry", "args": { "platform": "ios" } },
+    { "tool": "ios_set_increase_contrast", "args": { "enabled": true }, "wait_ms": 800 },
+    { "tool": "ios_screenshot", "args": { "path": "/abs/captures/profile-dark-ax5-contrast.png" } },
+    { "tool": "ios_set_increase_contrast", "args": { "enabled": false } },
+    { "tool": "ios_set_content_size", "args": { "size": "large" } },
+    { "tool": "ios_set_appearance", "args": { "mode": "light" } },
+    { "tool": "ios_status_bar", "args": { "preset": "clear" } }
+  ]
+}
+```
+
+## 5. Limits of a simulator review
+
+Record these under Not proven rather than skipping them silently:
+
+- Haptics do not play on a simulator.
+- Display brightness, outdoor legibility and true colour rendering need a
+  device.
+- Touch comfort and reach (one-handed use) need a device in the hand.
+- The accessibility tree reports frames, not always the real hit area of a
+  custom control.
+- States the review could not reach without seed data or a forced failure.

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

@@ -0,0 +1,193 @@
+# Design review checklist
+
+Questions per layer, with the threshold or HIG page behind each. Ask them of
+the rendered screen; when a question can only be answered from code or a
+device, note that under Not proven instead of guessing.
+
+## Contents
+
+1. Layout and safe areas
+2. Typography
+3. Colour and contrast
+4. Materials and Liquid Glass
+5. Iconography
+6. Navigation and bars
+7. Controls and touch targets
+8. Feedback and motion
+9. States
+10. Content, copy and localization
+11. Report template
+
+## 1. Layout and safe areas
+
+- Is interactive and legible content inside the safe area, while backgrounds
+  and artwork are allowed to run past it? Content under the status bar, home
+  indicator or a bar is a defect; a background that stops short of the edge
+  usually is too.
+- Are margins consistent across the screen and with neighbouring screens? Two
+  different leading insets on one screen read as a bug.
+- Do related items group visually (proximity, shared container) and unrelated
+  ones separate?
+- Does anything align to an invisible line it nearly hits? Near misses of a
+  few points look worse than an obvious offset.
+- Does the layout adapt to the available width rather than a device size: no
+  clipped trailing content on a narrow phone, no stretched single column on a
+  wide one?
+- Are safe area insets treated per edge? On devices with controls on one side
+  the insets are asymmetric; see `ios-iphone-duo`.
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/layout
+
+## 2. Typography
+
+- Is text set with text styles (Large Title through Caption) so it scales with
+  Dynamic Type? Text that does not grow at larger settings is the most common
+  finding of the whole review.
+- Body text: iOS default 17 pt, minimum 11 pt. Thin custom weights need larger
+  sizes to stay legible.
+- Is hierarchy carried by size and weight rather than by colour alone?
+- At the largest accessibility size, is as much useful text visible as at the
+  largest standard size? Truncation in a scrolling region hides content; wrap
+  instead.
+- Do horizontal rows switch to a vertical arrangement when text gets large,
+  instead of squeezing labels into ellipses?
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/typography
+
+## 3. Colour and contrast
+
+- Minimum contrast: 4.5:1 for text up to 17 pt, 3:1 for 18 pt and larger,
+  3:1 for bold text at any size. Check in light, dark and Increase Contrast.
+- Are colours semantic (label, secondary label, system background, tint) so
+  they adapt to dark mode and Increase Contrast? A colour that looks right in
+  light mode and disappears in dark mode is almost always a fixed value.
+- Is meaning ever carried by colour alone (red for error, green for success)?
+  Add a symbol, text or shape so it survives colour blindness and grayscale.
+- Is the tint used consistently for interactive elements and not for static
+  text?
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/color,
+https://developer.apple.com/design/human-interface-guidelines/dark-mode,
+https://developer.apple.com/design/human-interface-guidelines/accessibility
+
+## 4. Materials and Liquid Glass
+
+- Is Liquid Glass limited to the functional layer (bars, tab bars, sidebars,
+  floating controls)? Glass used for content cards or app backgrounds muddles
+  the hierarchy; the content layer uses standard materials.
+- Is the clear variant used only over visually rich media, and is there a
+  dimming layer (about 35% dark) when that media is bright?
+- Does text on glass stay legible over the busiest content that can scroll
+  beneath it?
+- With Reduce Transparency, and with the Liquid Glass look set to Tinted, do
+  custom glass surfaces become more opaque the way system ones do?
+- Are nested rounded shapes concentric with their container? Mismatched corner
+  radii stand out next to system glass.
+
+Implementation fixes belong to `swiftui-liquid-glass`.
+HIG: https://developer.apple.com/design/human-interface-guidelines/materials
+
+## 5. Iconography
+
+- Are interface icons SF Symbols or custom symbols built from the SF Symbols
+  template, at a weight that matches adjacent text?
+- Are variants consistent: outline in toolbars and lists, fill where the
+  container prefers it (tab bars), one variant per meaning?
+- Does every icon-only control have a text label for VoiceOver and for the
+  overflow menu?
+- Do directional symbols flip in right-to-left?
+
+Details: `ios-sf-symbols`. HIG:
+https://developer.apple.com/design/human-interface-guidelines/sf-symbols
+
+## 6. Navigation and bars
+
+- Are system navigation bars, toolbars and tab bars used, so they adopt
+  platform behaviour (glass, minimization, vertical placement on foldable
+  hardware)? A hand-built bar misses all of that.
+- Is Back or Close where people look first, and the primary action (Done,
+  Save) in its standard position?
+- Do tabs name destinations, not actions? Is the selected tab obvious in every
+  appearance?
+- Does the title fit at large text sizes, or collapse gracefully?
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/toolbars,
+https://developer.apple.com/design/human-interface-guidelines/tab-bars
+
+## 7. Controls and touch targets
+
+- iOS control size: 44x44 pt by default, 28x28 pt at minimum. Measure from
+  `design_ui_geometry`; the visible glyph may be smaller than the hit area,
+  which only the code or the tree can confirm.
+- Is there enough space between adjacent targets that a miss does not trigger
+  a neighbour?
+- Are standard controls used where they exist (toggle, stepper, picker,
+  segmented control) instead of look-alikes that miss system behaviour?
+- Are disabled controls visibly disabled, and is it clear why?
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/accessibility
+
+## 8. Feedback and motion
+
+- Does every action get a visible response within a moment: highlight,
+  progress, result?
+- Does motion explain a change (where something came from, where it went), or
+  only decorate?
+- Under Reduce Motion, are large movements, parallax, zooms and repeating
+  effects replaced by fades or removed?
+- Are haptics used for meaning rather than on every tap? Haptics need a real
+  device to judge; mark them Not proven on a simulator. Details: `ios-haptics`.
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/motion
+
+## 9. States
+
+For each screen, ask whether these states exist and look intentional:
+
+- Empty (first run and after deleting everything), with a next step.
+- Loading, without layout jumps when content arrives.
+- Error, in plain language, with a way to recover.
+- Offline or partial data.
+- Permission denied, with a path to Settings.
+- Long content: long names, long translations, many items.
+
+A state the review could not reach (no seed data, no way to force an error) is
+listed under Not proven, not assumed fine.
+
+## 10. Content, copy and localization
+
+- Is copy short, specific and consistent in terminology across screens?
+- Are buttons labelled with verbs that say what happens?
+- Is all user-facing text localized, including accessibility labels?
+- In right-to-left: text aligned to the trailing edge, back and progress
+  flipped, numerals not mirrored, photos and artwork not mirrored.
+- Do longer languages (German, Finnish) fit without truncation?
+
+HIG: https://developer.apple.com/design/human-interface-guidelines/writing,
+https://developer.apple.com/design/human-interface-guidelines/right-to-left
+
+## 11. Report template
+
+```markdown
+## Design review: <screen or flow>
+
+Inputs: <screenshots | simulator <device, iOS version> | source | design render>
+Matrix covered: <cells>; skipped: <cells and reason>; set by hand: <cells>
+
+### Findings
+
+1. [blocking] Colour and contrast, Settings > Profile, dark mode
+   Where: ProfileHeader.swift:42 (or: Profile screen, subtitle label, dark)
+   Evidence: captures/profile-dark.png, subtitle #6E6E73 on #1C1C1E, 3.1:1,
+   needs 4.5:1 at 15 pt
+   Why: secondary text is unreadable for many people in dark mode
+   Fix: use the secondary label colour instead of a fixed grey
+
+### Not proven
+
+- Hit area of the avatar button: glyph is 30 pt, hit area unknown without the
+  tree or source
+- Haptic on save: simulator does not play haptics
+```
+
+The angle-bracket placeholders in the template are filled in by the reviewer.

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

@@ -0,0 +1,191 @@
+---
+name: ios-haptics
+description: "Haptic feedback on iPhone: when a haptic adds meaning, sensoryFeedback, the UIFeedbackGenerator family, Core Haptics and AHAP, settings and on-device testing. Use when adding, choosing, reviewing or debugging haptics."
+metadata:
+  source: multi-agent-pipeline
+  date_added: "2026-10-08"
+---
+
+# Haptics
+
+A haptic is a physical confirmation of something the person did or something
+that happened. Used with restraint it makes an interface feel solid; used on
+every tap it becomes noise people turn off. This skill owns haptics across
+SwiftUI, UIKit and Core Haptics.
+
+## When a haptic earns its place
+
+Apple's guidance reduces to four questions. Ask them before adding one.
+
+1. **Does it confirm a cause?** The person should be able to say what made the
+   phone tap: a toggle flipped, a value snapped, a payment succeeded.
+2. **Does it keep its meaning?** Use system patterns for their documented
+   purpose (success means success). Reusing the error pattern for "level
+   complete" teaches people the wrong thing.
+3. **Does it match what they see and hear?** Intensity and sharpness should
+   match the animation; a heavy thud under a tiny fade feels broken.
+4. **Would they miss it if it were gone, without noticing it while it is on?**
+   That is the target. Frequent haptics become tiring.
+
+Do not add haptics:
+
+- to standard controls that already play them (toggles, sliders, pickers),
+  because the feedback doubles;
+- on scroll, on every keystroke, or on passive updates nobody triggered;
+- as the only signal of an outcome; pair it with a visual (and VoiceOver
+  announcement where relevant), because some people cannot feel it and some
+  devices cannot play it;
+- while the camera, microphone or gyroscope is capturing, because the
+  vibration can disturb the capture.
+
+Prefer short haptics for discrete events. Long continuous patterns suit games
+and rarely help in apps.
+
+## Choosing the API
+
+| Situation | Use |
+|---|---|
+| SwiftUI view reacting to a state change | `sensoryFeedback` |
+| UIKit, or feedback tied to a gesture's progress | `UIFeedbackGenerator` subclasses |
+| A shaped pattern, audio sync, or parameters changing while it plays | Core Haptics |
+
+Start at the top of the table and move down only when the simpler API cannot
+express the feeling.
+
+## SwiftUI: sensoryFeedback (iOS 17)
+
+The modifier plays feedback when a trigger value changes, so the haptic stays
+attached to the state that causes it.
+
+```swift
+@State private var savedCount = 0
+
+Button("Save") {
+    save()
+    savedCount += 1
+}
+.sensoryFeedback(.success, trigger: savedCount)
+```
+
+Three forms:
+
+- `sensoryFeedback(_:trigger:)`: play on every change.
+- `sensoryFeedback(_:trigger:condition:)`: play when the closure, given old
+  and new values, returns true.
+- `sensoryFeedback(trigger:_:)`: return the feedback to play, or nil, from
+  old and new values. This is how one trigger maps to success or error.
+
+```swift
+.sensoryFeedback(trigger: uploadState) { _, new in
+    switch new {
+    case .finished: .success
+    case .failed: .error
+    default: nil
+    }
+}
+```
+
+| Feedback | Meaning |
+|---|---|
+| `.success`, `.warning`, `.error` | Outcome of a task |
+| `.selection` | A value is changing during selection |
+| `.increase`, `.decrease` | A value went up or down a step |
+| `.start`, `.stop` | Something began or ended |
+| `.alignment` | A dragged item lined up with a guide |
+| `.levelChange` | Moving between discrete pressure levels |
+| `.impact`, `.impact(weight:intensity:)`, `.impact(flexibility:intensity:)` | A physical collision or snap |
+| `.pathComplete` (17.5) | A drawn path finished or was recognised |
+| `.press(_:)`, `.release(_:)`, `.selection(_:)` (26) | Touch down, touch up or value change on a kind of control (`.button`, `.buttonIconOnly`, `.slider`, `.tab`, `.toggle` for press) |
+
+## UIKit: feedback generators
+
+Generators are `@MainActor` and come in four kinds: `UIImpactFeedbackGenerator`,
+`UISelectionFeedbackGenerator`, `UINotificationFeedbackGenerator` and, from
+iOS 17.5, `UICanvasFeedbackGenerator` for drawing events (`alignmentOccurred(at:)`,
+`pathCompleted(at:)`).
+
+- Call `prepare()` shortly before a predictable haptic (a drag begins) to cut
+  latency. Preparing has no effect when the haptic follows immediately, and
+  the engine returns to idle after a few seconds, after feedback plays, or
+  when the generator is released.
+- Keep the generator alive for the interaction instead of creating one per
+  event.
+- From iOS 17.5, create generators attached to a view (`init(view:)`,
+  `init(style:view:)`) and pass the touch location (`impactOccurred(intensity:at:)`)
+  so the system can place the feedback for the interaction.
+
+```swift
+@MainActor
+final class SnapFeedback {
+    private let impact: UIImpactFeedbackGenerator
+
+    init(view: UIView) {
+        impact = UIImpactFeedbackGenerator(style: .medium, view: view)
+    }
+
+    func dragBegan() { impact.prepare() }
+
+    func snapped(at point: CGPoint) {
+        impact.impactOccurred(intensity: 0.8, at: point)
+    }
+}
+```
+
+Fire generators from the UI layer where the action happens, never from the
+data layer: a background sync should not make the phone tap.
+
+## Core Haptics
+
+Core Haptics (iOS 13) builds patterns from transient events (taps) and
+continuous events (sustained vibration), each with intensity and sharpness,
+optional audio, parameter curves over time, and dynamic parameters changed
+during playback. Patterns can live in code or in AHAP files, which are JSON
+and can be tuned without recompiling.
+
+Essentials:
+
+- Check `CHHapticEngine.capabilitiesForHardware().supportsHaptics` first;
+  iPad, iPod touch and Apple Vision Pro do not support haptics.
+- Create the engine, set `stoppedHandler` and `resetHandler` before starting
+  it, `start()` it, make a player, play. After a reset, restart the engine and
+  recreate players.
+- Stop the engine when the screen no longer plays patterns, or set
+  `isAutoShutdownEnabled`, to save power.
+- `playsHapticsOnly` ignores audio events when the pattern should be silent.
+- Load AHAP with `playPattern(from:)` or `CHHapticPattern(contentsOf:)` (16).
+
+Full engine lifecycle, event and parameter tables, curves, dynamic parameters,
+advanced players and AHAP structure are in `references/core-haptics.md`.
+
+## Settings, accessibility, power
+
+- Offer an in-app switch for non-essential haptics and read it before playing.
+  The app must work fully with haptics off.
+- The system plays haptics only where the hardware and the person's settings
+  allow; a missing haptic is not an error to surface.
+- Haptics complement, never replace, visible and spoken feedback.
+- Every haptic costs power. Avoid long continuous patterns, do not prepare
+  generators early, and stop Core Haptics engines when idle.
+
+## Testing
+
+Haptics have to be felt. The simulator plays none, so:
+
+- Test on a physical iPhone, in a quiet hand and on a table.
+- Check each haptic fires once per cause (no doubles from a control that
+  already plays one plus your own call).
+- Turn the in-app switch off and confirm silence; check behaviour with the
+  system haptics setting off.
+- Run through a whole flow and count haptics. If people would notice the
+  count, there are too many.
+- In unit tests, inject a feedback protocol and assert the calls; the engine
+  cannot be observed from a test.
+
+## References
+
+- `references/core-haptics.md`: engine lifecycle, events, parameters, curves, AHAP, pitfalls.
+- HIG Playing haptics: https://developer.apple.com/design/human-interface-guidelines/playing-haptics
+- sensoryFeedback: https://developer.apple.com/documentation/swiftui/view/sensoryfeedback(_:trigger:)
+- SensoryFeedback: https://developer.apple.com/documentation/swiftui/sensoryfeedback
+- UIFeedbackGenerator: https://developer.apple.com/documentation/uikit/uifeedbackgenerator
+- Core Haptics: https://developer.apple.com/documentation/corehaptics

package/pipeline/skills/shared/external/ios-haptics/evals/evals.json

@@ -0,0 +1,49 @@
+{
+  "skill_name": "ios-haptics",
+  "evals": [
+    {
+      "id": 0,
+      "name": "too-many-haptics-review",
+      "prompt": "Our SwiftUI app fires UIImpactFeedbackGenerator(style: .heavy).impactOccurred() on every button tap, on every toggle change, on every scroll page, and when background sync finishes. Users complain it feels buzzy. Review this and rewrite the approach.",
+      "expected_output": "Cuts haptics to meaningful causes: removes them from scrolling, background sync and toggles (toggles already play system haptics), keeps a few outcome haptics. Moves SwiftUI usage to sensoryFeedback tied to a trigger value (success, error, selection), avoids creating a generator per tap, keeps feedback in the UI layer, offers an in-app switch, pairs haptics with visual feedback, and recommends testing on a device because the simulator plays no haptics.",
+      "files": [],
+      "expectations": [
+        "Removes haptics from scrolling and background sync",
+        "Notes standard toggles already play haptics, avoiding doubles",
+        "Uses sensoryFeedback with a trigger value in SwiftUI",
+        "Uses notification-style feedback (success or error) for outcomes",
+        "Mentions a user setting to turn haptics off or pairing with visual feedback",
+        "Says haptics must be tested on a physical device"
+      ]
+    },
+    {
+      "id": 1,
+      "name": "drag-snap-uikit",
+      "prompt": "In a UIKit canvas editor, objects snap to guides while dragging. We want a crisp tick at each snap with minimal latency, iOS 17.5+. What should we use?",
+      "expected_output": "Uses a feedback generator kept alive for the drag: UICanvasFeedbackGenerator alignmentOccurred(at:) for snapping to guides, or UIImpactFeedbackGenerator created with init(style:view:) and impactOccurred(intensity:at:) with the touch location. Calls prepare() when the drag begins, not right before firing, and fires once per snap from the UI layer.",
+      "files": [],
+      "expectations": [
+        "Names UICanvasFeedbackGenerator or a view-attached UIImpactFeedbackGenerator",
+        "Passes the touch location (alignmentOccurred(at:) or impactOccurred(intensity:at:))",
+        "Calls prepare() at drag start to reduce latency",
+        "Keeps one generator for the interaction instead of creating one per snap",
+        "Fires once per snap rather than continuously"
+      ]
+    },
+    {
+      "id": 2,
+      "name": "custom-pattern-core-haptics",
+      "prompt": "Design wants a checkout success haptic: a sharp tap followed by a short soft swell, tunable by designers without app releases. How do we build this properly?",
+      "expected_output": "Uses Core Haptics: checks supportsHaptics, creates an engine, sets stopped and reset handlers before start, restarts and recreates players after reset, stops the engine or enables auto shutdown for power. Builds a transient event plus a continuous event with a parameter curve, and stores the pattern in a bundled AHAP file loaded with playPattern(from:) or CHHapticPattern(contentsOf:). Pairs the haptic with visual confirmation and notes devices without haptics.",
+      "files": [],
+      "expectations": [
+        "Checks hardware support with capabilitiesForHardware",
+        "Sets stoppedHandler and resetHandler and restarts after reset",
+        "Combines a transient event with a continuous event or curve",
+        "Uses an AHAP file for designer tuning",
+        "Stops the engine when idle or uses isAutoShutdownEnabled",
+        "Keeps a visual confirmation alongside the haptic"
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,22 @@
+[
+  { "query": "Add a success haptic when the user completes a purchase in SwiftUI", "should_trigger": true },
+  { "query": "sensoryFeedback vs UIImpactFeedbackGenerator, which should I use?", "should_trigger": true },
+  { "query": "Our haptics feel laggy, should I call prepare()?", "should_trigger": true },
+  { "query": "Create a custom haptic pattern with Core Haptics and an AHAP file", "should_trigger": true },
+  { "query": "Too many vibrations in our app, review where haptics should go", "should_trigger": true },
+  { "query": "CHHapticEngine stops after a phone call and never plays again", "should_trigger": true },
+  { "query": "Play a selection tick while the picker value changes", "should_trigger": true },
+  { "query": "Should haptics respect a user setting and how do we test them?", "should_trigger": true },
+  { "query": "Haptic feedback when a dragged item snaps to a grid in UIKit", "should_trigger": true },
+  { "query": "Use the new press and release sensory feedback for buttons on iOS 26", "should_trigger": true },
+  { "query": "Play a notification sound when a message arrives", "should_trigger": false },
+  { "query": "Add a spring animation when the card snaps into place", "should_trigger": false },
+  { "query": "Schedule a local push notification for tomorrow", "should_trigger": false },
+  { "query": "Detect shake gesture to undo", "should_trigger": false },
+  { "query": "Read accelerometer data with Core Motion", "should_trigger": false },
+  { "query": "Make the bell SF Symbol bounce when a notification arrives", "should_trigger": false },
+  { "query": "Rumble a game controller during gameplay on Apple TV", "should_trigger": false },
+  { "query": "Add VoiceOver announcements for upload completion", "should_trigger": false },
+  { "query": "Play background audio while the app is locked", "should_trigger": false },
+  { "query": "Design review of the checkout screen", "should_trigger": false }
+]