@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

package/pipeline/skills/shared/external/alarmkit/evals/evals.json

@@ -3,38 +3,43 @@
   "evals": [
     {
       "id": 0,
-      "prompt": "I'm adding a wake-up alarm feature to an iOS 26 app. Sketch the AlarmKit scheduling code for a one-time 7:00 AM alarm with a Snooze button, and call out the Info.plist and authorization pieces I need.",
-      "expected_output": "A source-grounded AlarmKit implementation outline that requests authorization, includes NSAlarmKitUsageDescription, schedules with AlarmManager using AlarmAttributes/AlarmPresentation, and configures snooze with CountdownDuration.postAlert rather than the .alarm convenience alone.",
+      "prompt": "Add a one-time 6:30 wake-up alarm to our iOS 26.1 sleep app. The user should be able to hit Snooze and get another ring a few minutes later. Show the scheduling code and anything we need in the project.",
+      "expected_output": "Adds NSAlarmKitUsageDescription, requests AlarmManager authorization and handles denial, builds AlarmAttributes with an AlarmPresentation.Alert that has no custom stopButton, implements snooze with a .countdown secondary button plus CountdownDuration.postAlert through the AlarmConfiguration initializer that takes countdownDuration, and presents stop and secondary intents as optional.",
       "files": [],
       "expectations": [
-        "Mentions NSAlarmKitUsageDescription and user authorization through AlarmManager before relying on scheduling.",
-        "Uses AlarmAttributes and AlarmPresentation.Alert with the current alert initializer shape that does not require a custom stopButton.",
-        "Configures snooze by providing Alarm.CountdownDuration with postAlert and the countdown-style AlarmConfiguration initializer, not only AlarmConfiguration.alarm(...).",
-        "Treats stopIntent and secondaryIntent as optional API parameters while recommending them when button actions need app cleanup or custom behavior."
+        "Mentions NSAlarmKitUsageDescription and AlarmManager authorization",
+        "Builds AlarmAttributes with AlarmPresentation.Alert and does not pass a custom stopButton",
+        "Implements snooze with secondaryButtonBehavior .countdown and CountdownDuration.postAlert",
+        "Uses AlarmConfiguration(countdownDuration:schedule:attributes:...) rather than relying only on .alarm(...)",
+        "Describes stopIntent and secondaryIntent as optional for standard Stop and Snooze"
       ]
     },
     {
       "id": 1,
-      "prompt": "Review this AlarmKit state-management plan: cache AlarmManager.shared.alarms at launch, pause any scheduled alarm, call countdown(id:) whenever the user taps Snooze, and call stop(id:) to remove both one-shot and repeating alarms. What should I fix?",
-      "expected_output": "A review that corrects the throwing alarms getter, valid lifecycle states for pause/resume/countdown, and stop behavior for one-shot versus repeating alarms.",
+      "prompt": "Here is our plan for the alarm list screen: read AlarmManager.shared.alarms without try on launch, show Pause and Resume buttons on every row, call countdown(id:) whenever the user wants to restart a scheduled alarm, assume stop(id:) deletes every alarm, and treat any alarm that vanishes from alarmUpdates as cancelled by the user. What would you change?",
+      "expected_output": "Explains that alarms is a throwing getter, that pause is valid only in countdown and resume only in paused, that countdown(id:) only works from alerting, that stop removes one-shot alarms but reschedules repeating ones, and that an alarm missing from alarmUpdates only means it is no longer scheduled unless the app compares with IDs it persisted.",
       "files": [],
       "expectations": [
-        "States that AlarmManager.shared.alarms is a throwing getter and examples should handle it with try or do/catch.",
-        "Explains that pause(id:) applies to countdown state, resume(id:) applies to paused state, and countdown(id:) applies to alerting state.",
-        "Explains that stop(id:) removes one-shot alarms but repeating alarms are scheduled again for their next occurrence.",
-        "Avoids claiming that a missing alarm from alarmUpdates always means only cancellation or a final stop; frames it as no longer scheduled with AlarmKit unless compared with app-persisted IDs."
+        "States that AlarmManager.shared.alarms throws and needs try",
+        "Limits pause(id:) to the countdown state",
+        "Limits resume(id:) to the paused state",
+        "Limits countdown(id:) to the alerting state",
+        "Says stop(id:) removes one-shot alarms and reschedules repeating alarms",
+        "Explains that disappearance from alarmUpdates means no longer scheduled, not specifically cancelled, unless compared with persisted IDs"
       ]
     },
     {
       "id": 2,
-      "prompt": "My timer app needs a 10-minute AlarmKit countdown with custom Lock Screen and Dynamic Island UI, plus maybe normal Home Screen widgets and APNs updates later. Which parts belong in AlarmKit, and where should I hand off to sibling skills?",
-      "expected_output": "A boundary-aware answer that keeps AlarmKit responsible for system alarms/countdowns and their countdown Live Activity handoff, while routing generic widget and push-notification work to the appropriate sibling skills.",
+      "prompt": "Product wants AlarmKit to also drive our Smart Stack widget, our delivery-tracking Live Activity and our marketing push notifications, with a fully custom design for the ringing screen. Which parts belong to AlarmKit?",
+      "expected_output": "Limits AlarmKit to system alarms and countdowns and their types, explains that the alerting UI is system-managed while countdown and paused UI can be customised in a widget extension, lists Lock Screen, Dynamic Island, StandBy and paired Apple Watch without Smart Stack, and routes widgets to widgetkit, other Live Activities to live-activities and notifications to push-notifications.",
       "files": [],
       "expectations": [
-        "Keeps AlarmKit focused on system alarms/countdowns, AlarmManager, AlarmAttributes, AlarmPresentation, AlarmPresentationState, and authorization.",
-        "Clarifies that alerting UI is system-managed while countdown/paused Live Activity UI can be customized in a widget extension.",
-        "Names Apple-sourced surfaces such as Lock Screen, Dynamic Island, StandBy, and paired Apple Watch, without relying on an unsupported AlarmKit Smart Stack claim.",
-        "Routes ordinary Home Screen/timeline widget work to widgetkit or ActivityKit details to activitykit, and generic APNs setup to push-notifications instead of expanding AlarmKit scope."
+        "Keeps AlarmKit scope to system alarms and countdown timers and their AlarmKit types",
+        "States that the alerting UI is drawn by the system and only countdown and paused UI is customisable",
+        "Lists Lock Screen, Dynamic Island, StandBy and paired Apple Watch and does not claim Smart Stack",
+        "Routes Smart Stack and Home Screen widgets to widgetkit",
+        "Routes the non-alarm Live Activity to live-activities",
+        "Routes push notifications to push-notifications"
       ]
     }
   ]