{"version":"2.1.277","anchor":"reserved-skilltool-name-category-added-reserved-name","canonical_anchor":"skillcommand-permission-lock-now-recognizes-reserved-settin","heading":"New reserved-name lock for skills, commands and tools","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/reserved-skilltool-name-category-added-reserved-name","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### New reserved-name lock for skills, commands and tools\n\nSkills, commands and tools whose name collides with a reserved settings key now get a distinct 'reserved-name' lock\n\n**Unclear.** The finding doesn't say what triggers the 'reserved-name' origin or which skill\/tool names are reserved.\n\n**What**\n\n- Skills whose name fails a new reserved-name check are locked to on\/user-invocable-only, ignoring any user override.\n\n- The permissions UI now shows a distinct \"reserved-name\" state when a skill's or command's configured name can't be stored in settings because it collides with a reserved key, with guidance to rename the skill's folder or the command file.\n\n- Tools or commands named exactly `__proto__` are always treated as reserved-name and forced to stay callable (on or user-invocable-only), regardless of user or policy settings for slash-command visibility.\n\n- The permission-mode cycling control now treats \"reserved-name\" the same as \"policy\" or \"flag\" sources: it leaves the mode unchanged instead of letting it be cycled.\n\n**Why**\n\nNames like `__proto__` can collide with reserved keys used internally by settings storage, which previously could cause confusing or unsafe override behavior. The new reserved-name category makes this collision visible in the UI and stops such names from being silently disabled, hidden, or mis-cycled.\n\n- Area: Permissions\n- Names: `reserved-name`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}