{
  "skill_name": "swiftdata",
  "evals": [
    {
      "id": 1,
      "prompt": "Our iOS 26 habit tracker is turning on iCloud sync. The models: Habit has @Attribute(.unique) var slug: String, a non-optional relationship var owner: Profile, and var icon: Data holding PNGs. Profile has #Unique<Profile>([\\.email]) and @Relationship(deleteRule: .deny) var habits: [Habit]. The container uses ModelConfiguration(cloudKitDatabase: .private(\"iCloud.example.habits\")). Review this before we ship.",
      "expected_output": "A review that opens with a capabilities verdict and then lists schema changes needed for CloudKit, without telling the team to make every scalar optional.",
      "files": [],
      "assertions": [
        "Flags both @Attribute(.unique) and #Unique as incompatible with CloudKit sync.",
        "Says the non-optional owner relationship must become optional.",
        "Flags the .deny delete rule as unsupported with CloudKit and suggests enforcing the rule in app code.",
        "Recommends @Attribute(.externalStorage) for the image Data.",
        "Does not claim that every scalar property has to be optional for CloudKit.",
        "Mentions the iCloud/CloudKit capability, Background Modes Remote notifications, and deploying the schema to production or keeping production changes additive."
      ]
    },
    {
      "id": 2,
      "prompt": "A SwiftData list of 40,000 shipments scrolls badly. The view uses @Query(filter: #Predicate<Shipment> { $0.eta < Date.now && $0.isLate() }, sort: \\.eta). Someone proposes adding #Index on every property of Shipment and says index changes never need migration testing. What should we do?",
      "expected_output": "Advice that fixes the predicate, proposes a targeted index strategy, and keeps migration testing and profiling in the plan.",
      "files": [],
      "assertions": [
        "Moves Date.now out of the predicate into a local let that the predicate captures.",
        "Warns that calling a helper method such as isLate() inside #Predicate is unsupported and suggests stored properties or filtering after the fetch.",
        "Recommends indexing the few properties used in hot filters and sorts instead of every property.",
        "Suggests a compound index when one filter plus sort combination is used repeatedly.",
        "Does not state that adding or removing indexes needs no migration testing.",
        "Suggests profiling with Instruments, for example the Core Data template, to confirm the gain."
      ]
    },
    {
      "id": 3,
      "prompt": "We have a Core Data app with an .xcdatamodeld containing Article (title String, savedAt Date, tags Transformable) and Author entities. We want new screens in SwiftData while old screens keep Core Data, reading the same data. How do we set that up?",
      "expected_output": "Coexistence guidance that points SwiftData at the existing store and matches the schema, without turning into a general Core Data tutorial.",
      "files": [],
      "assertions": [
        "Treats Core Data and SwiftData coexistence as in scope for this skill.",
        "Configures SwiftData with the existing store URL through ModelConfiguration(url:).",
        "Requires @Model class names, property names, types and relationships to match the Core Data entities.",
        "Mentions @Attribute(originalName:) for any renamed property.",
        "States that compatible Codable structs or enums can replace the Transformable attribute, without claiming an iOS 18 minimum for storing Codable values.",
        "Does not expand into a step-by-step tutorial for building a standalone Core Data stack."
      ]
    }
  ]
}