{
  "skill_name": "metrickit-diagnostics",
  "evals": [
    {
      "id": 0,
      "name": "production-ingestion-pipeline",
      "prompt": "We want MetricKit data from our shipping iOS app in our own backend: daily performance numbers plus crashes and hangs with symbolicated stacks. A teammate registered the subscriber in the settings screen and parses everything inside the callback. Design the pipeline properly.",
      "expected_output": "Registers one long-lived subscriber at startup (didFinishLaunchingWithOptions or App.init), implements both didReceive callbacks, writes each payload's jsonRepresentation() to disk before any parsing, symbolication or upload, moves heavy work off the callback, backfills from pastPayloads and pastDiagnosticPayloads, and does not promise that daily metric payloads show up immediately while developing.",
      "files": [],
      "expectations": [
        "Subscribes a long-lived object at app startup rather than in a screen",
        "Implements both the metric and the diagnostic callback",
        "Persists raw JSON before parsing, symbolicating or uploading",
        "Moves heavy processing out of the callback",
        "Backfills with pastPayloads and pastDiagnosticPayloads",
        "Does not claim daily metric payloads arrive immediately during development"
      ]
    },
    {
      "id": 1,
      "name": "signpost-and-launch-fix",
      "prompt": "Fix this code: it creates an ID with MXSignpostIntervalData.makeSignpostID(log:), passes it to every mxSignpost call, and extends launch with MXMetricManager.shared.extendLaunchMeasurement(forTaskID:) from a background queue after the first screen appears. Where do the signpost numbers end up?",
      "expected_output": "Says makeSignpostID(log:) is not documented MetricKit API, uses MXMetricManager.makeLogHandle(category:) with default mxSignpost arguments, and points to MXMetricPayload.signpostMetrics in the daily payload. Rewrites extended launch with the throwing type methods extendLaunchMeasurement(forTaskID:) and finishExtendedLaunchMeasurement(forTaskID:), called with try on the main thread before the first scene is active, with at most 16 overlapping tasks that must all be finished.",
      "files": [],
      "expectations": [
        "Rejects makeSignpostID(log:) as undocumented",
        "Uses makeLogHandle(category:) and default mxSignpost parameters",
        "Names MXMetricPayload.signpostMetrics as where the data appears",
        "Uses try with the static extendLaunchMeasurement and finishExtendedLaunchMeasurement methods instead of the shared instance",
        "States the main-thread, early-start, 16-task, overlapping-window and finish-every-task rules"
      ]
    },
    {
      "id": 2,
      "name": "scope-routing",
      "prompt": "Organizer shows rising hang rates and a crash spike after our SwiftUI redesign. Tell us what MetricKit can do here, and what we should take to other tools.",
      "expected_output": "Keeps MetricKit to manager setup, payload handling, reading MXHangDiagnostic and MXCrashDiagnostic, and uploading call-stack JSON with dSYMs to a backend. Sends SwiftUI body cost and invalidation fixes to swiftui-performance and local Instruments, LLDB, Memory Graph or xctrace work to debugging-instruments. Explains that MetricKit is production telemetry aggregated daily, and does not turn into a refactoring plan or an Instruments tutorial.",
      "files": [],
      "expectations": [
        "Keeps manager setup, payload handling, hang and crash diagnostics and backend upload in MetricKit",
        "Mentions call-stack JSON uploaded with dSYMs",
        "Sends SwiftUI fixes to swiftui-performance",
        "Sends Instruments, LLDB, Memory Graph and xctrace work to debugging-instruments",
        "Describes MetricKit as production data aggregated daily",
        "Does not expand into a refactor or an Instruments walkthrough"
      ]
    }
  ]
}