skills-npm

Problem skips the confirmation prompt but not the agent selection prompt. To fully skip interactive prompts (e.g. in CI or scripts), you also need , but there's no way to say "all of them" without listing every agent name. Changes Support as a special value for (both CLI flag and config file), matching the upstream CLI convention Resolved in so works from too Test plan [x] passes [x] — 21 tests pass [x] clean

Problem discovers skills by scanning . This relies on package authors bundling skills inside their npm packages. In practice, most popular packages (React, Next.js, Tailwind CSS, etc.) don't ship a directory — and likely won't anytime soon. This means can't help users of these packages, which is a significant gap. Proposed Solution Add a config option that maps installed packages to external skill sources. When detects a package is installed but has no built-in skills, it fetches the corresponding skill from a community-maintained repository. How it works 1. scans as usual 2. For each entry in , check if the package is installed (exists in ) 3. If installed but has no built-in directory, fetch the skill from the specified GitHub repo 4. Cache the fetched skills locally and symlink them to agent directories, same as built-in skills Fetch format would resolve to: This follows the same directory convention as . Why not just use a separate skills-only npm package? That already works today — you can and will pick it up. But this requires: Publishing and maintaining a separate npm package Users explicitly installing it Managing version alignment manually The config approach is lighter — no extra packages to install, and the mapping is explicit and user-controlled. Open Questions 1. Should community skills be cached globally (XDG cache) or per-project? 2. How to handle version alignment — should the config support specifying a branch/tag (e.g., )? 3. Should there be a community registry/default mapping so users don't have to configure each package manually? Happy to implement this if the direction makes sense!

[ x ] <- Keep this line and put an between the brackts. Description This PR adds a caching mechanism to speed up repeated scans and adds support for Bundle lock files. Changes: 1. Added a caching system - caches scan results based on lock file hashes, avoiding rescanning the node_modules directory when dependencies haven't changed. 2. Supports npm, yarn, pnpm, and bun. 3. Added a cache status indicator - displays the "(From Cache)" message when using cached results. Performance: Rescanning the node_modules directory on every run is slow, especially in large monorepo environments. Caching can reduce subsequent run times from seconds to milliseconds. User Experience: The "(From Cache)" indicator helps users understand whether they are receiving cached or up-to-date results. Linked Issues accomplish #12 Additional context I'm not entirely sure if this implementation meets expectations (as described in #12). Any suggestions? :P