Metrickit

{
  "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 b