Built-in skills silently introduced by updates conflict with existing custom skills, with no way to disable them

[Qazebulon]

Custom skills that were working under a given name (e.g. /review) break silently when a Claude Code update introduces a built-in with the same name. The built-in takes precedence, the custom skill is effectively displaced, and there is no mechanism to disable or override the built-in.

Impact:

• Existing workflows break without warning at the point of use — there is no notification that an update introduced a conflicting built-in
• Users are forced to rename their custom skills (and update all references) to avoid current and potential future collisions
• There is no way to know in advance which names are "safe" to use

Requested changes:

1. A disabledCommands (or disabledSkills) array in settings.json so users can opt out of specific built-ins
2. At minimum, a warning or notification when an auto-update introduces a built-in that conflicts with an existing custom skill
3. (Ideal) Custom skills should be able to override built-ins of the same name — the user's explicit configuration should win

Workaround currently required: Adopt a namespace prefix (e.g. eg-) across all custom skills to avoid collisions with present and future built-ins.

[laniakea001]

This is a real pain point for organizations managing custom skills at scale. We faced a similar challenge in OpenClaw.

Our approach was to implement a "skill override hierarchy":

1. System skills (built-in, cannot be overridden)
2. Organization skills (shared across team)
3. User skills (personal customization)
4. Project skills (project-specific)

Each level can optionally disable lower levels. The key is having clear precedence rules and a "skill audit" command to see which skills are active and from which level.

For the implementation, consider:

• A manifest file (.claude/skills-manifest.json) that tracks origin
• Version pinning for built-in skills
• An explicit disable flag in skill metadata

---

OpenClaw - Open source desktop AI assistant

[m13v]

this bit us hard when a claude code update introduced a built-in skill with the same name as one of ours. zero warning, our skill just stopped being invoked. the fix should be simple: custom skills should always take priority over built-in ones (user intent is clear), and there should be a warning on startup when a conflict exists. we ended up prefixing all our custom skills with a namespace to avoid future collisions but that's a hack

[m13v]

Our skill registry that catalogs and deconflicts skill names across local, global, and project scopes: https://github.com/m13v/skill-registry

It scans all skill directories, detects naming collisions, and warns before they become silent failures. Namespacing with prefixes is the pragmatic fix until Anthropic adds priority ordering.

[DarkSunRise]

+1 — hit this with a custom skill named batch. The error message is particularly misleading:

Skill batch cannot be used with Skill tool due to disable-model-invocation

The frontmatter has no disable-model-invocation field. Hex-dumped the file to rule out hidden chars. Other skills with identical structure (orient, status) work fine. Renaming to run-batch fixes it instantly.

The error should say "conflicts with built-in skill" not "disable-model-invocation." Filed #36010 (now closed as dup of this).

[m13v]

the error message is definitely the worst part of this bug. disable-model-invocation appearing when the real issue is a name collision is genuinely confusing. good find hex-dumping the file to rule out hidden chars - that would have been my first guess too. the prefix workaround works but shouldn't be necessary. hopefully the team picks up your #36010 for a proper fix.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.