I'm the author. I built this for npm package authors to bundle AI agent documentation directly with their packages.
The problem is that AI coding assistants (OpenCode, Claude Code, Cursor and Copilot) don't recognise your library's API unless you provide documentation manually.
Solution: Add an 'agentskills' field to your package.json file that points to your Markdown documentation. When users install your package and run 'npx agentskills export --target opencode', their AI will load your documentation automatically.
This uses the agentskills.io open format. Skills are exported to .opencode/skill/, .claude/skills/, .cursor/skills/, .github/skills/ (Copilot), and so on. All are project-local.
It works with any framework/runtime where npm works. There is a built-in Nuxt module for convenience, but the core is framework-agnostic.
I would love to receive feedback, especially from package maintainers, on whether this would be useful for their libraries.
verdverm•3w ago
The main issue I see here is that most people are only paying token service, pun intended, to their package instructions. You really need multiple and you need to put effort into them.
Most of the ones I've seen in the wild are long ass doc dumps, which are great for polluting your context with a ton of unnecessary tokens. I don't use the ones they give me and write my own for the parts of a project I use.
onmax•3w ago
The problem is that AI coding assistants (OpenCode, Claude Code, Cursor and Copilot) don't recognise your library's API unless you provide documentation manually.
Solution: Add an 'agentskills' field to your package.json file that points to your Markdown documentation. When users install your package and run 'npx agentskills export --target opencode', their AI will load your documentation automatically.
This uses the agentskills.io open format. Skills are exported to .opencode/skill/, .claude/skills/, .cursor/skills/, .github/skills/ (Copilot), and so on. All are project-local.
It works with any framework/runtime where npm works. There is a built-in Nuxt module for convenience, but the core is framework-agnostic.
I would love to receive feedback, especially from package maintainers, on whether this would be useful for their libraries.