Two Claude Code skills share the name prototype, and they do different jobs. Matt Pocock's version picks between a one-file HTML demo for testing l...
For further actions, you may consider blocking this person and/or reporting abuse
The location precedence also means the repo copy can't be relied on as the team default. Anyone with a personal skill of the same name overrides it without knowing, and nothing in the session says which file answered. Renaming the project copy to something specific to the repo removes the clash instead of relying on everyone's home folder being clean.
Agreed, renaming is the cleaner fix, and it needs both halves. In a personal or project skills folder the directory name also invokes the skill, so change the folder name and the frontmatter
namefield together, or the old command can still reach it. If the team copy must never be shadowed, the skills docs give another route: a plugin skill and a same-name skill elsewhere both load, because plugin skills are namespaced as/plugin-name:skill-name. Shipping the team version as a plugin gives it a command no personal folder can take over.Worth grepping the repo's own instructions and docs for the old bare command after the switch. Anything that still says run /skill-name now reaches whichever personal copy holds that name, which is the shadowing you set out to remove, just moved into the docs.
Fair catch, and it is the half we left out. Namespacing the command only closes the hole for people who type the namespaced form, and the docs are what tells them which form to type. So the rename is three places, not two: the directory, the frontmatter name, and every instruction that still names the old bare command.
The grep worth running covers more than CLAUDE.md, because the old name tends to be sitting in a README, a PR template, an onboarding doc and a CI comment as well. Searching the whole tree for the slash plus the old name catches all of those in one pass, and it is worth running again after the rename lands, since the first pass usually misses the ones inside code fences and example blocks.
The case no grep can reach is a saved snippet outside the repo entirely. Nothing in the tree can tell you about that, so announcing the new command is part of the change rather than a courtesy.
Agreed that announcing it is part of the change. One way to keep the tree clean afterwards is to leave that grep in CI as a check: it fails any change that reintroduces the old bare command, so a copied README section or a new onboarding doc can't bring the shadowing back months later.
One detail for that CI check: the pattern has to separate the bare command from everything that legitimately contains the name. A plain grep for /prototype also hits skills/prototype/SKILL.md, /prototype-v2, URLs ending in /prototype, and the changelog line that records the rename. What we'd run:
The leading class rejects path and URL segments like skills/prototype and x.com/prototype, the trailing class rejects longer names, and the two excludes carve out the files that are supposed to name the old command. Mind the exit code: git grep exits 0 on a match, so a bare grep passes exactly when it should fail. A leading
!only fixes that on the step's last line, becausebash -e(the GitHub Actions default) ignores a failed!command anywhere earlier. Theif ... then exit 1form works on any line.