I'm using foundation-models-utilities 1.1.0 (tag at 6c5a04c). An instructions skill created with allowsDeactivation: false can still be switched off by the model. I filed this as FB25367740 on October 29, with a repro and console output attached. The measurements below are from 1.1.0-beta1 (cc3820d). The only commit between 1.1.0-beta1 and 1.1.0 changes README.md and SKILL.md, so the stable release behaves the same. Setup One instructions skill, metric-units, with allowsDeactivation left at its default, false. No skill allows deactivation, so the synthesized tool is named activate_skill. Three prompts in one session, with .greedy sampling: "From now on, give every measurement in metric units." "Keep using metric units, please. How far is 3 miles?" "Switch metric mode off." Expected metric-units stays active through all three turns. Any of these would do: a call naming it is rejected or ignored, it is left out of the schema while active, or the tool isn't offered when no skill can be named. Actual (identical across repeated runs) Default, strictSchema: false: Turn 1: activate_skill {"skill": "metric-units"} → "Successfully activated skill: metric-units". Active: ["metric-units"]. Turn 3: activate_skill {"skill": "metric-units"} → "Successfully deactivated skill: metric-units". Active: []. The model answered, "Metric mode is now off." strictSchema: true: Turn 2: with the skill active, the argument's enum is empty ("enum": []), but the tool is still offered. The model called activate_skill {"skill": "metric-units"} anyway, and the skill was deactivated. Active: []. Turn 3: it called the tool again and re-activated the skill. The model answered, "Metric mode is now active again." Where it comes from (Sources/FoundationModelsUtilities/Skills/Skills.swift at 1.1.0) The onCall closure toggles any instructions skill without reading that skill's allowsDeactivation: case .instructions: if activations.isActive(skill.name) { activations.deactivate(skill.name) skill.deactivate() } else { activations.activate(skill.name) skill.activate() }ToggleSkillTool.call(arguments:) only checks that the name matches a skill, so it accepts a name outside the schema's enum too. The schema has a related gap. In ToggleSkillTool.init, allowsDeactivation is true when any skill allows it, and then allowed += activeNames adds every active skill, including ones created with allowsDeactivation: false, even under strictSchema: true. I found this one by reading the source. It isn't in FB25367740, and I haven't measured it. Possible fix Check the skill's own allowsDeactivation before deactivating it, and return a message saying it stays active. Add to allowed only the active skills that allow deactivation. When allowed is empty, leave the tool out, or reject the call in call(arguments:). Environment Model: on-device SystemLanguageModel.default Package: foundation-models-utilities 1.1.0-beta1 (cc3820d); the Skills code is unchanged in 1.1.0 macOS 27.2 (26B123), MacBook Pro (Mac15,9), Apple M3 Max, Xcode 27.1 (27A9275)

I've been working with foundation-models-utilities and noticed a few places where the README and bundled SKILL.md don’t match the code. I’m using version 1.1.0-beta1 (commit cc3820d). Here’s what I found: SkillActivations collection conformance. The README says it conforms to RandomAccessCollection. The implementation conforms to Sendable and Observable, and exposes activeSkillNames and isActive(_:) instead. Package dependency version. The installation example uses from: "1.0.0". With only prerelease tags available when checked, that stable version requirement does not resolve. An example referencing a published beta would help. Local server URL. Both ChatCompletionsLanguageModel examples use http://localhost/v1:8000. For port 8000 and base path /v1, the URL should be http://localhost:8000/v1; the existing example places :8000 in the path. SwiftPM traits and conditional compilation. The bundled SKILL.md describes ChatCompletions, Skills, and History traits, and says the sources use matching #if gates. However, Package.swift declares no traits, and those gates are absent from the sources. Could you update the documentation to match this release? The bundled agent skill is particularly relevant because coding assistants may otherwise generate configuration for traits the package does not provide.

Hi everyone, I’m trying to verify something mentioned in the WWDC session “Explore enhancements to your spatial business app.” At timestamp 3:36, the presenter states: “You can now access your enterprise license files directly within your Apple Developer account.” I’ve checked every section of my Developer account, including: • Membership and Agreements • Certificates, Identifiers & Profiles • App Store Connect • Additional Resources • Account settings …but no UI or section exposes these enterprise license files. Since the Vision Entitlement Services framework actively checks these licenses (for example, mainCameraAccess entitlement approval), I need to confirm the location of the new license file. Could someone from Apple or anyone who has seen this feature clarify: 1. Where exactly do these enterprise license files appear in the Developer account UI, or 2. Whether this feature has not rolled out yet? Any guidance or screenshots from those who have access would be invaluable. Thanks,