library-skills

Description counts skill names over a list that has not been deduplicated, so a single skill discovered through two paths counts as two, is reported as a collision, and is skipped. No second skill is involved. In (0.0.19): is defined directly below it and dedupes by resolved , which is exactly the guard against one skill being discovered twice. It is wired into a single call site, inside interactive selection. Both and the path call on the undeduplicated list, so neither benefits from it. The user sees: and every affected skill is dropped from the install. I hit this with all discovered skills in a project refused at once, in a project using . Working around it meant copying the skill directories in by hand. Suggested fix Deduplicate before counting at both call sites, so only reports a genuine clash between two distinct skills that happen to share a name. Two notes The warning wording implies a real name clash between different packages, which made this considerably harder to diagnose than it needed to be. Something like "discovered more than once" versus "two different skills claim this name" would separate the two cases. I have the code path but not a reliable reproduction. I could not get it to fire again with across several projects, so I have not pinned down the discovery condition that yields the duplicate entry. It may be related to the editable-install attribution behaviour in #109. Happy to dig further if a repro would help. I also checked #57, which asks for namespaced install names to avoid collisions. That is about genuine clashes between distinct skills and is a different thing from this false positive. PR #164 adds two more calls, but both are in the interactive selection path, so the collision count stays undeduplicated. Operating System macOS Library Skills Version 0.0.19