What
Skill enable/disable overrides (skillOverrides) are now checked in local project settings (localSettings) in addition to project and user settings, with local settings taking the highest priority.
Details
- The resolution order is two-phase: (1) look up by fully-qualified
cmdNameinprojectSettings, thenuserSettings; (2) if nothing found, look up byunqualifiedNameinlocalSettings, thenprojectSettings, thenuserSettings.localSettingsis therefore checked only for the unqualified name, not for the full command name. - Valid override values and their effects:
"on"(default — fully visible to model and typeable);"name-only"(lists the skill without its description);"user-invocable-only"(hidden from model invocation, but still typeable as/name);"off"(hidden from both the model and the/nameprompt). - When a skill's
lockSourceis"author", any resolved override value other than"off"is silently capped to"user-invocable-only". This means authors can prevent a skill from being fully exposed, but individual users cannot grant it full"on"status. - The
/skillspanel writes overrides tolocalSettings(not projectSettings), so panel changes are local to the machine and do not affect teammates sharing the same project settings file. - Attempting to invoke a skill whose effective state is
"off"or"user-invocable-only"via the model produces the error:"Skill '<name>' is disabled via skillOverrides. Re-enable it in /skills or remove the override from your settings to run it."
Evidence
Updated skill override resolver (search for Mjl, "localSettings" in context of skillOverrides, "user-invocable-only", "Skill.*disabled via skillOverrides")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.