Chip Fetcher (cf)

The 8 vendor-site sub-skills are undiscoverable

chip-fetcher ships a source-site skill pack: a dispatcher plus one sub-skill per vendor website (manufacturer, snapeda, ti, digikey, mouser, ultralibrarian, nxp, st). On this container none of the 8 subs are registered as skills — only the chip-fetcher-sites dispatcher is. An AI fetching from DigiKey can't have the digikey skill fire on its own triggers; it only gets the dispatcher.

Why (verified on this container, adom-wiki-cli 1.6.4 / Claude Code)

The tarball nests the subs two levels deep:

skills/SKILL.md                       (dispatcher, name: chip-fetcher-sites)
skills/sites/<site>/SKILL.md          x8  (the vendor sub-skills)

install.sh copies them verbatim to:

~/.claude/skills/chip-fetcher-sites/SKILL.md            <- registered (dispatcher)
~/.claude/skills/chip-fetcher-sites/sites/<site>/SKILL.md  <- NOT registered (2 levels deep)

Claude Code registers a skill from exactly one directory level (~/.claude/skills/<name>/SKILL.md), so anything at .../sites/<site>/SKILL.md never registers. Confirmed: ls ~/.claude/skills/ shows chip-fetcher-sites but no snapeda/mouser/digikey/etc. (the adom-digikey/adom-mouser dirs are the separate adom-digikey/adom-mouser packages, unrelated to these subs).

The wiki flags exactly this at publish now, as NESTED_SKILLS_UNDISCOVERABLE: "N SKILL.md file(s) sit deeper than skills// … Claude Code registers skills from exactly one directory level, so these can never fire on their own triggers." There is no .claude-plugin/plugin.json in the package, which is the manifest that would let the nested subs register.

Fixes (owner's call — three valid shapes)

A. Dual-mode (recommended if the subs should fire independently). Add a .claude-plugin/plugin.json at the package root and deliver the pack as one unit; modern Claude Code then registers each nested sub as <pack>:<sub> beside the root skill. adom/adom-cli is the working example in the fleet (root SKILL.md + .claude-plugin/plugin.json + skills/adom-cli/<sub>/SKILL.md). Two things to settle when you do it:

• .claude-plugin/plugin.json = { "name": "adom-chip-fetcher", "description": "...", "version": "<pkg version>" } (mirror adom-cli's), added to package.json files.
• Verify the nesting shape registers: adom-cli uses skills/<packname>/<sub>/, chip-fetcher uses skills/sites/<site>/. Confirm Claude Code registers skills/sites/<site>/ under the plugin (or move the subs to match adom-cli's shape) before relying on it. Since adom-wiki-cli 1.0.81+ auto-delivers a dual-mode pack as one ~/.claude/skills/adom-chip-fetcher/ unit, you can also drop the custom skill-copying from install.sh once this lands.

B. Flatten. Make each sub skills/chip-fetcher-<site>/SKILL.md (one level, slug-prefixed so it doesn't squat a generic name like snapeda). Each becomes an ordinary top-level skill with its own triggers. Simplest, but loses the dispatcher/sub grouping.

C. They're reference docs, not skills. If the subs are meant to be read only through the dispatcher (not triggered independently), rename each SKILL.md to <site>.md. They stop being skills, the dispatcher references them as docs, and the lint goes quiet.

Given each vendor sub has distinct per-site value (an AI driving DigiKey wants the DigiKey flow directly), A is the likely intent, but that's a design decision for whoever owns chip-fetcher's skill taxonomy.

Context / not-in-scope note

This surfaced from the adom/adom-wiki-cli#22 skill-delivery audit. The CLI side is already done: adom-wiki-cli 1.0.81+ delivers bundled skills for every package type and supports the dual-mode layout natively (it detects root SKILL.md + .claude-plugin/plugin.json and delivers the whole tree as one unit). So no CLI change is needed — this is purely a package-layout choice for chip-fetcher. Filing it here so it's tracked against the package, not the CLI.