@mmerterden/multi-agent-pipeline 8.6.2 → 10.0.6

package/pipeline/skills/shared/external/metrickit-diagnostics/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: metrickit-diagnostics
-description: "Collect and analyze on-device performance metrics and crash diagnostics using MetricKit. Use when setting up MXMetricManager, handling MXMetricPayload or MXDiagnosticPayload, processing crash/hang/disk-write diagnostics via MXCallStackTree, adding custom signpost metrics, or uploading telemetry to an analytics backend."
+description: "Collect and analyze on-device performance metrics and crash diagnostics using MetricKit. Use when setting up MXMetricManager, handling MXMetricPayload or MXDiagnosticPayload, processing crash/hang/disk-write diagnostics via MXCallStackTree, adding custom signpost metrics, correcting mxSignpost or extended launch measurement code, or uploading telemetry to an analytics backend."
 ---
 
-# MetricKit Diagnostics
+# MetricKit
 
 Collect aggregated performance metrics and crash diagnostics from production
 devices using MetricKit. The framework delivers daily metric payloads (CPU,
 memory, launch time, hang rate, animation hitches, network usage) and
-immediate diagnostic payloads (crashes, hangs, disk-write exceptions) with
-full call-stack trees for triage.
+diagnostic payloads (crashes, hangs, disk-write exceptions) with call-stack
+trees for triage.
 
 ## Contents
 
@@ -22,15 +22,19 @@ full call-stack trees for triage.
 - [Exporting and Uploading Payloads](#exporting-and-uploading-payloads)
 - [Extended Launch Measurement](#extended-launch-measurement)
 - [Xcode Organizer Integration](#xcode-organizer-integration)
+- [Scope Boundaries](#scope-boundaries)
 - [Common Mistakes](#common-mistakes)
 - [Review Checklist](#review-checklist)
 - [References](#references)
 
 ## Subscriber Setup
 
-Register a subscriber as early as possible — ideally in
+Register a subscriber as early as possible  -  ideally in
 `application(_:didFinishLaunchingWithOptions:)` or `App.init`. MetricKit
 starts accumulating reports after the first access to `MXMetricManager.shared`.
+When backfilling, state precisely that `pastPayloads` and
+`pastDiagnosticPayloads` return reports generated since the last allocation of
+the shared manager instance.
 
 ```swift
 import MetricKit
@@ -39,7 +43,12 @@ final class MetricsSubscriber: NSObject, MXMetricManagerSubscriber {
     static let shared = MetricsSubscriber()
 
     func subscribe() {
-        MXMetricManager.shared.add(self)
+        let manager = MXMetricManager.shared
+        manager.add(self)
+
+        // Reports generated since the last allocation of the shared manager.
+        processMetricPayloads(manager.pastPayloads)
+        processDiagnosticPayloads(manager.pastDiagnosticPayloads)
     }
 
     func unsubscribe() {
@@ -47,11 +56,11 @@ final class MetricsSubscriber: NSObject, MXMetricManagerSubscriber {
     }
 
     func didReceive(_ payloads: [MXMetricPayload]) {
-        // Handle daily metrics
+        processMetricPayloads(payloads)
     }
 
     func didReceive(_ payloads: [MXDiagnosticPayload]) {
-        // Handle diagnostics (crashes, hangs, disk writes)
+        processDiagnosticPayloads(payloads)
     }
 }
 ```
@@ -99,59 +108,74 @@ func didReceive(_ payloads: [MXMetricPayload]) {
         let jsonData = payload.jsonRepresentation()
         persistPayload(jsonData, from: begin, to: end)
 
-        processMetrics(payload)
+        enqueueMetricProcessing(jsonData)
     }
 }
 ```
 
-**Availability**: `MXMetricPayload` — iOS 13.0+, macOS 10.15+, visionOS 1.0+
+**Availability**: `MXMetricPayload`  -  iOS 13.0+, iPadOS 13.0+,
+Mac Catalyst 13.1+, macOS 10.15+, visionOS 1.0+
 
 ## Receiving Diagnostic Payloads
 
 `MXDiagnosticPayload` delivers crash, hang, CPU exception, disk-write, and
-app-launch diagnostics. On iOS 15+ and macOS 12+, diagnostics arrive
-immediately rather than bundled with the daily report.
+app-launch diagnostics where supported. On iOS 15+ and macOS 12+, supported
+diagnostics can arrive as soon as available rather than bundled with the daily
+report.
 
 ```swift
 func didReceive(_ payloads: [MXDiagnosticPayload]) {
     for payload in payloads {
         let jsonData = payload.jsonRepresentation()
         persistPayload(jsonData)
+        enqueueDiagnosticProcessing(jsonData)
+    }
+}
+```
+
+In the background processor, inspect the typed diagnostic arrays after the raw
+payload is durable:
 
-        if let crashes = payload.crashDiagnostics {
-            for crash in crashes {
-                handleCrash(crash)
-            }
+```swift
+func processDiagnosticPayload(_ payload: MXDiagnosticPayload) {
+    if let crashes = payload.crashDiagnostics {
+        for crash in crashes {
+            handleCrash(crash)
         }
-        if let hangs = payload.hangDiagnostics {
-            for hang in hangs {
-                handleHang(hang)
-            }
+    }
+    if let hangs = payload.hangDiagnostics {
+        for hang in hangs {
+            handleHang(hang)
         }
-        if let diskWrites = payload.diskWriteExceptionDiagnostics {
-            for diskWrite in diskWrites {
-                handleDiskWrite(diskWrite)
-            }
+    }
+    if let diskWrites = payload.diskWriteExceptionDiagnostics {
+        for diskWrite in diskWrites {
+            handleDiskWrite(diskWrite)
         }
-        if let cpuExceptions = payload.cpuExceptionDiagnostics {
-            for cpuException in cpuExceptions {
-                handleCPUException(cpuException)
-            }
+    }
+    if let cpuExceptions = payload.cpuExceptionDiagnostics {
+        for cpuException in cpuExceptions {
+            handleCPUException(cpuException)
         }
-        if let launchDiags = payload.appLaunchDiagnostics {
-            for launchDiag in launchDiags {
-                handleSlowLaunch(launchDiag)
-            }
+    }
+    #if os(iOS) || targetEnvironment(macCatalyst) || os(visionOS)
+    if #available(iOS 16.0, macCatalyst 16.0, visionOS 1.0, *),
+       let launchDiagnostics = payload.appLaunchDiagnostics {
+        for launchDiagnostic in launchDiagnostics {
+            handleSlowLaunch(launchDiagnostic)
         }
     }
+    #endif
 }
 ```
 
-**Availability**: `MXDiagnosticPayload` — iOS 14.0+, macOS 12.0+, visionOS 1.0+
+**Availability**: `MXDiagnosticPayload`  -  iOS 14.0+, iPadOS 14.0+,
+Mac Catalyst 14.0+, macOS 12.0+, visionOS 1.0+. `appLaunchDiagnostics`
+requires iOS 16.0+, iPadOS 16.0+, Mac Catalyst 16.0+, or visionOS 1.0+.
 
 ## Key Metrics
 
-### Launch Time — MXAppLaunchMetric
+### Launch Time  -  MXAppLaunchMetric
 
 ```swift
 if let launch = payload.applicationLaunchMetrics {
@@ -162,7 +186,7 @@ if let launch = payload.applicationLaunchMetrics {
 }
 ```
 
-### Run Time — MXAppRunTimeMetric
+### Run Time  -  MXAppRunTimeMetric
 
 ```swift
 if let runTime = payload.applicationTimeMetrics {
@@ -213,165 +237,95 @@ if let exits = payload.applicationExitMetrics {
 
 ## Call Stack Trees
 
-`MXCallStackTree` is attached to each diagnostic (crash, hang, CPU exception,
-disk write, app launch). Use `jsonRepresentation()` to extract and symbolicate.
+`MXCallStackTree` is attached to each diagnostic. Use `jsonRepresentation()` to extract frame data, then symbolicate with `atos` or by uploading dSYMs to your analytics service.
 
-```swift
-func handleCrash(_ crash: MXCrashDiagnostic) {
-    let tree = crash.callStackTree
-    let treeJSON = tree.jsonRepresentation()
-
-    let exceptionType = crash.exceptionType
-    let signal = crash.signal
-    let reason = crash.terminationReason
-
-    uploadDiagnostic(
-        type: "crash",
-        exceptionType: exceptionType,
-        signal: signal,
-        reason: reason,
-        callStack: treeJSON
-    )
-}
+See [references/metrickit-patterns.md](references/metrickit-patterns.md) for crash/hang handling code and JSON structure details.
 
-func handleHang(_ hang: MXHangDiagnostic) {
-    let tree = hang.callStackTree
-    let duration = hang.hangDuration  // Measurement<UnitDuration>
-    uploadDiagnostic(type: "hang", duration: duration, callStack: tree.jsonRepresentation())
-}
-```
-
-The JSON structure contains an array of call stack frames with binary name,
-offset, and address. Symbolicate using `atos` or upload dSYMs to your
-analytics service.
-
-**Availability**: `MXCallStackTree` — iOS 14.0+, macOS 12.0+, visionOS 1.0+
+**Availability**: `MXCallStackTree`  -  iOS 14.0+, iPadOS 14.0+,
+Mac Catalyst 14.0+, macOS 12.0+, visionOS 1.0+
 
 ## Custom Signpost Metrics
 
 Use `mxSignpost` with a MetricKit log handle to capture custom performance
-intervals. These appear in the daily `MXMetricPayload` under `signpostMetrics`.
-
-### Creating a Log Handle
+intervals. Leave the advanced `dso`, `signpostID`, and `format` parameters at
+their documented defaults. Custom metrics appear in the daily `MXMetricPayload`
+under `signpostMetrics`; call that out when reviewing custom MetricKit
+instrumentation. When correcting custom signpost code, explicitly name
+`MXMetricPayload.signpostMetrics` so the caller knows where the data lands.
+Do not allocate or pass an `OSSignpostID` for the basic MetricKit pattern; use
+the defaulted `mxSignpost(.begin/.end, log:name:)` calls unless there is a
+specific overlapping-interval reason to do otherwise.
 
 ```swift
 let metricLog = MXMetricManager.makeLogHandle(category: "Networking")
-```
-
-### Emitting Signposts
-
-```swift
-import os
-
-func fetchData() async throws -> Data {
-    let signpostID = MXSignpostIntervalData.makeSignpostID(log: metricLog)
-
-    mxSignpost(.begin, log: metricLog, name: "DataFetch", signpostID: signpostID)
-    let data = try await URLSession.shared.data(from: url).0
-    mxSignpost(.end, log: metricLog, name: "DataFetch", signpostID: signpostID)
+mxSignpost(.begin, log: metricLog, name: "DataFetch")
+defer { mxSignpost(.end, log: metricLog, name: "DataFetch") }
 
-    return data
-}
-```
-
-### Reading Custom Metrics from Payload
-
-```swift
-if let signposts = payload.signpostMetrics {
-    for metric in signposts {
-        let name = metric.signpostName       // "DataFetch"
-        let category = metric.signpostCategory // "Networking"
-        let count = metric.totalCount
-        if let intervalData = metric.signpostIntervalData {
-            let avgMemory = intervalData.averageMemory
-            let cumulativeCPUTime = intervalData.cumulativeCPUTime
-        }
-    }
-}
+let data = try await fetchData()
 ```
 
-> The system limits the number of custom signpost metrics per log to reduce
-> on-device overhead. Reserve custom metrics for critical code paths.
+See [references/metrickit-patterns.md](references/metrickit-patterns.md) for signpost emission patterns and reading custom metrics from payloads.
 
 ## Exporting and Uploading Payloads
 
-Both payload types conform to `NSSecureCoding` and provide
-`jsonRepresentation()` for easy serialization.
+Both payload types provide `jsonRepresentation()` for serialization. Always
+persist raw JSON to disk before processing. Use `pastPayloads` and
+`pastDiagnosticPayloads` on launch to retrieve reports generated since the last
+allocation of the shared manager instance.
 
-```swift
-func persistPayload(_ jsonData: Data, from: Date? = nil, to: Date? = nil) {
-    let fileName = "metrics_\(ISO8601DateFormatter().string(from: Date())).json"
-    let url = FileManager.default.temporaryDirectory.appending(path: fileName)
-    try? jsonData.write(to: url)
-}
-
-func uploadPayloads(_ jsonData: Data) {
-    Task.detached(priority: .utility) {
-        var request = URLRequest(url: URL(string: "https://api.example.com/metrics")!)
-        request.httpMethod = "POST"
-        request.setValue("application/json", forHTTPHeaderField: "Content-Type")
-        request.httpBody = jsonData
-        _ = try? await URLSession.shared.data(for: request)
-    }
-}
-```
-
-### Retrieving Past Payloads
-
-If the subscriber was not registered when payloads arrived, retrieve them
-using `pastPayloads` and `pastDiagnosticPayloads`. These return reports
-generated since the last allocation of the shared manager.
-
-```swift
-let pastMetrics = MXMetricManager.shared.pastPayloads
-let pastDiags = MXMetricManager.shared.pastDiagnosticPayloads
-```
+See [references/metrickit-patterns.md](references/metrickit-patterns.md) for export code and past payload retrieval.
 
 ## Extended Launch Measurement
 
-Track post-first-draw setup work (loading databases, restoring state) as
-part of the launch metric using extended launch measurement.
+Track post-first-draw setup work as part of the launch metric on iOS 16+,
+iPadOS 16+, Mac Catalyst 16+, macOS 13+, and visionOS 1+:
 
 ```swift
 let taskID = MXLaunchTaskID("com.example.app.loadDatabase")
-
-MXMetricManager.shared.extendLaunchMeasurement(forTaskID: taskID)
-// Perform extended launch work...
-await database.load()
-MXMetricManager.shared.finishExtendedLaunchMeasurement(forTaskID: taskID)
+try MXMetricManager.extendLaunchMeasurement(forTaskID: taskID)
+defer { try? MXMetricManager.finishExtendedLaunchMeasurement(forTaskID: taskID) }
+restoreCachedState()
 ```
 
-Extended launch times appear under `histogrammedExtendedLaunch` in
-`MXAppLaunchMetric`.
+When correcting extended launch code, include the whole operational contract:
+availability is iOS/iPadOS/Mac Catalyst 16+, macOS 13+, and visionOS 1+; call
+the throwing `MXMetricManager` type methods on the main thread; start the first
+task before the first scene becomes active; keep task windows overlapping;
+finish every task; and stay within the 16-task limit. Extended launch times
+appear under `histogrammedExtendedLaunch` in `MXAppLaunchMetric`.
 
 ## Xcode Organizer Integration
 
-Xcode Organizer shows the same MetricKit data aggregated across all users
-who have opted in to share diagnostics. Use Organizer for trend analysis:
+Xcode Organizer shows aggregated MetricKit data across opted-in users. Use it for trend analysis alongside on-device collection routed to your own backend.
+
+See [references/metrickit-patterns.md](references/metrickit-patterns.md) for Organizer tab details.
 
-- **Metrics tab**: Battery, performance, and disk-write metrics over time
-- **Regressions tab**: Automatic detection of metric regressions per version
-- **Crashes tab**: Crash logs with symbolicated stack traces
+## Scope Boundaries
 
-MetricKit on-device collection complements Organizer by letting you route
-raw data to your own backend for custom dashboards, alerting, and filtering
-by user cohort.
+Use this skill for production MetricKit ingestion, payload export, custom
+MetricKit signposts, and diagnostic upload/symbolication. Route SwiftUI runtime
+stutters, body-update cost, identity churn, and view invalidation fixes to
+`swiftui-performance`. Route local Instruments, LLDB, Memory Graph, and
+`xctrace` workflows to `debugging-instruments`. When explaining production
+telemetry, distinguish daily metric payloads from supported diagnostics that
+can arrive as soon as available.
 
 ## Common Mistakes
 
 ### DON'T: Subscribe to MXMetricManager too late
 
-The system may deliver pending payloads shortly after launch. Subscribing
-late (e.g., in a view controller) risks missing them entirely.
+Allocate `MXMetricManager.shared` and register the subscriber during app startup
+so the manager can accumulate reports and deliver any previously undelivered
+daily reports. Registering from a later view lifecycle hook is too easy to miss.
 
 ```swift
-// WRONG — subscribing in a view controller
+// WRONG  -  subscribing in a view controller
 override func viewDidLoad() {
     super.viewDidLoad()
     MXMetricManager.shared.add(self)
 }
 
-// CORRECT — subscribe in application(_:didFinishLaunchingWithOptions:)
+// CORRECT  -  subscribe in application(_:didFinishLaunchingWithOptions:)
 func application(
     _ application: UIApplication,
     didFinishLaunchingWithOptions opts: [UIApplication.LaunchOptionsKey: Any]?
@@ -384,31 +338,31 @@ func application(
 ### DON'T: Ignore MXDiagnosticPayload
 
 Only handling `MXMetricPayload` means you miss crash, hang, and disk-write
-diagnostics — the most actionable data MetricKit provides.
+diagnostics  -  the most actionable data MetricKit provides.
 
 ```swift
-// WRONG — only implementing metric callback
+// WRONG  -  only implementing metric callback
 func didReceive(_ payloads: [MXMetricPayload]) { /* ... */ }
 
-// CORRECT — implement both callbacks
+// CORRECT  -  implement both callbacks
 func didReceive(_ payloads: [MXMetricPayload]) { /* ... */ }
 func didReceive(_ payloads: [MXDiagnosticPayload]) { /* ... */ }
 ```
 
 ### DON'T: Process payloads without persisting first
 
-The system delivers each payload once. If your subscriber crashes during
-processing, the data is lost permanently.
+Do not assume callback delivery will repeat if your own processing fails. Save
+the raw JSON before parsing, symbolication, or upload work.
 
 ```swift
-// WRONG — process inline, crash loses data
+// WRONG  -  process inline, crash loses data
 func didReceive(_ payloads: [MXDiagnosticPayload]) {
     for p in payloads {
         riskyProcessing(p)  // If this crashes, payload is gone
     }
 }
 
-// CORRECT — persist raw JSON first, then process
+// CORRECT  -  persist raw JSON first, then process
 func didReceive(_ payloads: [MXDiagnosticPayload]) {
     for p in payloads {
         let json = p.jsonRepresentation()
@@ -420,11 +374,12 @@ func didReceive(_ payloads: [MXDiagnosticPayload]) {
 
 ### DON'T: Do heavy work synchronously in didReceive
 
-The callback runs on an arbitrary thread. Blocking it with heavy processing
-or synchronous network calls delays delivery of subsequent payloads.
+Apple documents that it is safe to process payloads on a separate thread. Keep
+the subscriber callback small: persist the JSON, then move expensive parsing
+or uploading out of the callback.
 
 ```swift
-// WRONG — synchronous upload in callback
+// WRONG  -  synchronous upload in callback
 func didReceive(_ payloads: [MXMetricPayload]) {
     for p in payloads {
         let data = p.jsonRepresentation()
@@ -432,7 +387,7 @@ func didReceive(_ payloads: [MXMetricPayload]) {
     }
 }
 
-// CORRECT — persist and dispatch async
+// CORRECT  -  persist and dispatch async
 func didReceive(_ payloads: [MXMetricPayload]) {
     for p in payloads {
         let json = p.jsonRepresentation()
@@ -450,30 +405,32 @@ MetricKit aggregates data over 24-hour windows. Payloads do not arrive
 immediately after instrumenting. Use Xcode Organizer or simulated payloads
 for faster iteration during development.
 
+### DON'T: Invent MetricKit signpost IDs
+
+`MXSignpostIntervalData.makeSignpostID(log:)` is not documented MetricKit API.
+For basic MetricKit custom metrics, create an `MXMetricManager` log handle and
+call `mxSignpost(.begin/.end, log:name:)` without `OSSignpostID` allocation or
+custom `dso`, `signpostID`, or `format` arguments.
+
 ## Review Checklist
 
 - [ ] `MXMetricManager.shared.add(subscriber)` called in `application(_:didFinishLaunchingWithOptions:)` or `App.init`
 - [ ] Subscriber conforms to `MXMetricManagerSubscriber` and inherits `NSObject`
 - [ ] Both `didReceive(_: [MXMetricPayload])` and `didReceive(_: [MXDiagnosticPayload])` implemented
 - [ ] Raw `jsonRepresentation()` persisted to disk before processing
-- [ ] Heavy processing dispatched asynchronously off the callback thread
+- [ ] Heavy processing dispatched asynchronously after raw payload persistence
 - [ ] `MXCallStackTree` JSON uploaded with dSYMs for symbolication
 - [ ] Custom signpost metrics limited to critical code paths
 - [ ] `pastPayloads` and `pastDiagnosticPayloads` checked on launch for missed deliveries
-- [ ] Extended launch tasks call both `extendLaunchMeasurement` and `finishExtendedLaunchMeasurement`
+- [ ] Extended launch tasks call the throwing `MXMetricManager` type methods on the main thread and finish every started task
 - [ ] Analytics backend accepts and stores MetricKit JSON format
 - [ ] Xcode Organizer reviewed for regression trends alongside on-device data
 
 ## References
 
+- Extended patterns: [references/metrickit-patterns.md](references/metrickit-patterns.md)
 - [MetricKit framework](https://sosumi.ai/documentation/metrickit)
 - [MXMetricManager](https://sosumi.ai/documentation/metrickit/mxmetricmanager)
 - [MXMetricManagerSubscriber](https://sosumi.ai/documentation/metrickit/mxmetricmanagersubscriber)
 - [MXMetricPayload](https://sosumi.ai/documentation/metrickit/mxmetricpayload)
 - [MXDiagnosticPayload](https://sosumi.ai/documentation/metrickit/mxdiagnosticpayload)
-- [MXCallStackTree](https://sosumi.ai/documentation/metrickit/mxcallstacktree)
-- [MXSignpostMetric](https://sosumi.ai/documentation/metrickit/mxsignpostmetric)
-- [MXAppLaunchMetric](https://sosumi.ai/documentation/metrickit/mxapplaunchmetric)
-- [MXAppRunTimeMetric](https://sosumi.ai/documentation/metrickit/mxappruntimemetric)
-- [MXCrashDiagnostic](https://sosumi.ai/documentation/metrickit/mxcrashdiagnostic)
-- [Analyzing the performance of your shipping app](https://sosumi.ai/documentation/xcode/analyzing-the-performance-of-your-shipping-app)

package/pipeline/skills/shared/external/metrickit-diagnostics/evals/evals.json

@@ -0,0 +1,46 @@
+{
+  "skill_name": "metrickit",
+  "evals": [
+    {
+      "id": 0,
+      "prompt": "Review this MetricKit telemetry plan for an iOS app: the subscriber is created in a dashboard view, only didReceive([MXMetricPayload]) is implemented, payloads are parsed and uploaded before saving, and missed reports are ignored. Give corrected guidance with concise Swift where useful.",
+      "expected_output": "A source-grounded MetricKit setup review that registers early, handles both metric and diagnostic payloads, persists raw JSON before processing, offloads heavier work, and retrieves past reports precisely.",
+      "files": [],
+      "expectations": [
+        "Recommends registering a long-lived MXMetricManagerSubscriber during app startup, such as UIApplication launch or App.init.",
+        "Implements or explicitly requires both didReceive(_: [MXMetricPayload]) and didReceive(_: [MXDiagnosticPayload]).",
+        "Persists jsonRepresentation() before parsing, symbolication, or upload work.",
+        "Moves expensive parsing or uploads out of the subscriber callback after persistence.",
+        "Uses pastPayloads and pastDiagnosticPayloads, or otherwise addresses missed reports during startup backfill.",
+        "Does not claim that MetricKit callbacks are a normal immediate development-time signal for daily metric payloads."
+      ]
+    },
+    {
+      "id": 1,
+      "prompt": "Fix this MetricKit code review comment: the team uses MXSignpostIntervalData.makeSignpostID(log:), passes a custom signpostID into mxSignpost, and calls MXMetricManager.shared.extendLaunchMeasurement without try from a background task. What should the corrected guidance say?",
+      "expected_output": "A correction-focused answer that removes the fake signpost helper, preserves MetricKit mxSignpost defaults, and uses the current extended launch type methods with availability and main-thread constraints.",
+      "files": [],
+      "expectations": [
+        "States that MXSignpostIntervalData.makeSignpostID(log:) is not the documented MetricKit API.",
+        "Uses MXMetricManager.makeLogHandle(category:) and mxSignpost(.begin/.end, log:name:) without custom dso, signpostID, or format parameters for the basic MetricKit pattern.",
+        "States that MetricKit custom signpost metrics appear under MXMetricPayload.signpostMetrics.",
+        "Uses try MXMetricManager.extendLaunchMeasurement(forTaskID:) and try or try? MXMetricManager.finishExtendedLaunchMeasurement(forTaskID:) as type methods, not shared instance methods.",
+        "Mentions Apple's operational constraints for extended launch measurement: main thread, early scene activation or state restoration timing, max 16 tasks, overlapping task windows, or finishing every started task."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "My SwiftUI feed stutters in development, Instruments shows a hot body update, and product wants production hang/crash telemetry in our analytics backend. What should the MetricKit skill handle directly, and what should be routed to adjacent skills?",
+      "expected_output": "A boundary-aware answer that keeps production MetricKit ingestion in scope while routing SwiftUI code remediation and local Instruments profiling details to sibling skills.",
+      "files": [],
+      "expectations": [
+        "Keeps MXMetricManager setup, MXMetricPayload/MXDiagnosticPayload handling, MXHangDiagnostic or MXCrashDiagnostic processing, and backend upload guidance in the MetricKit scope.",
+        "Routes SwiftUI view invalidation, body-cost, identity, and remediation patterns to the swiftui-performance skill.",
+        "Routes local Instruments capture, LLDB, Memory Graph, and xctrace workflow details to the debugging-instruments skill.",
+        "Mentions using MXCallStackTree JSON plus dSYMs or an analytics symbolication pipeline for crash and hang triage.",
+        "Mentions MetricKit as production telemetry rather than immediate local debugging, including daily aggregation or non-realtime behavior.",
+        "Does not expand into a full SwiftUI refactor or full Instruments tutorial."
+      ]
+    }
+  ]
+}