Last 12 weeks · 7 commits
5 of 6 standards met
Clear and concise description of the problem While the proposal of building the skills into the NPM package is great, it will take time when all package maintainers add this. But people want to add all skills as dependencies already now. Suggested solution For now, the service https://skills.sh/ already provides a lot of skills, and is quite popular. But its approach is to download skills once and place it into the git repo, which will go to production with all that garbage. So, would be great to extend the package to support downloading and managing skills from the https://skills.sh/ too, together with other skills, bundled in NPM packages. Alternative _No response_ Additional context _No response_ Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Clear and concise description of the problem Summary In a pnpm monorepo, only seems to discover skills from dependencies declared in the workspace root . If a package that ships skills is installed in a workspace package's , running from either the root script or the workspace package's script does not discover/install the skills. Moving the same dependency to the root makes discovery work. Reproduction Given a pnpm workspace like this: : Root : Workspace package : ships a skill under: Then run: or manually: I also tried adding a script inside and running install from there, but the skill was still not discovered. Actual behavior No skill from is discovered or symlinked when the dependency is declared only in the workspace package. If I move to the root , discovers and installs the skill successfully. Expected behavior should be able to discover skills from dependencies declared in workspace package manifests, not only from the root package manifest. Suggested solution NOP Alternative _No response_ Additional context _No response_ Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Clear and concise description of the problem The recommendation of the current approach is to add skills as files to each NPM package. But these skill files are not needed in the production build at all! So, with bundling skills to the main packages, we are just wasting resources on production servers with no benefits. Suggested solution A good solution will be installing skills as dev dependencies, so as not to bring these files to the production builds. This approach seems not easy to implement, because it will require building separate packages with skills and without skills, but if we found a simple solution for this, it will be a good improvement of the whole approach! What do you think about this idea? Alternative _No response_ Additional context _No response_ Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Bug Description On Windows, reports for all npm- skills when the agent's is itself a symlink (e.g. ). Root Cause In , junctions are created with a relative path: On Windows, with type requires an absolute path. When a relative path is passed, Node.js resolves it from , not from . So for where (a symlink pointing to ): = = Junction target resolved by Node.js = ❌ (wrong — goes up from CWD, not from linkDir) Expected = ✅ Even with (a real directory), the same issue occurs whenever the project is nested more than one level deep from the drive root, because the relative path is resolved from CWD (the project root), which goes above the project root. Fix Pass the absolute path when creating a junction on Windows: Where is already (absolute) at the call site. Reproduction 1. Windows with Developer Mode enabled (symlinks allowed for non-admin) 2. Project at with symlinking to 3. Run 4. All npm- skills report Environment OS: Windows 11 Node.js: v22 skills-npm: 1.1.1
Problem Setting up skills-npm in a project is two manual steps that are easy to forget or get wrong: add a script to , and add the pattern to . New users have to read the docs and hand-edit both files before anything works. Changes Adds a command that bootstraps a project in one step: Merges into 's script: appends to an existing with , creates it when absent, and is a no-op when already wired. The edit preserves the file's existing indentation, newline style, trailing newline, and BOM, and leaves key order untouched. Runs the first sync immediately, so skills are symlinked (and configured) without waiting for a separate install. This is the recommended onboarding path, now documented in the README: The change is purely additive: the default command is unchanged, including how it manages . is safe and idempotent to re-run. New tests cover the prepare-merge rules and the format-preserving edit (indentation, trailing newline, CRLF, BOM).
Repository: antfu/skills-npm. Description: Install agent skills from npm Stars: 479, Forks: 17. Primary language: TypeScript. Languages: TypeScript (86.8%), JavaScript (13.2%). License: MIT. Latest release: v1.2.0 (2w ago). Open PRs: 0, open issues: 9. Last activity: 2w ago. Community health: 85%. Top contributors: antfu, jinghaihan, privatenumber, EnderRomantice, antfubot, PinkChampagne17.