Summary
Users assume /skills lists everything the agent can do. It only lists optional skill packs, so when someone searches it for "filesystem" and finds nothing, they conclude the agent cannot touch files, even though the os.fs.* tools are built in and always available.
This has now come up with more than one user in Discord.
User quote (Discord)
"it's my first time to use tools and skills.. and already having problems. I asked it to create a folder on desktop. but it don't have the skills. I have used /skills and searched for filesystem but doesn't find anything"
That user has been running local models for a while, so this is not a beginner-only trap: the tools/skills distinction simply is not visible in the product.
Two things make this unavoidable today
- There is no
/tools command. The slash registry has /skills, /model, /memory, /mcp and others, but nothing lists the tool surface. /skills is the only place a user can look, and by design it never contains tools.
- Searching for "filesystem" cannot match anything. The twelve filesystem tools are named
os.fs.read, os.fs.write, os.fs.list, os.fs.trash and so on. The word "filesystem" appears in no tool name, so even a working tool listing would return nothing for that query.
Worth stating explicitly for anyone triaging: these tools carry the frequent tier, so they are in the prompt on every turn. The capability was never missing, only its discoverability.
Proposal
- Add a
/tools command listing the built-in tool surface, grouped by family (os.fs, os.shell, browser, memory, vision).
- In the
/skills view, show a short line such as "Built-in tools (fs, git, browser, memory, vision) are always available and are not listed here."
- Make searches in
/skills for built-in families ("filesystem", "fs", "git", "browser") say where those live instead of returning an empty result.
Summary
Users assume
/skillslists everything the agent can do. It only lists optional skill packs, so when someone searches it for "filesystem" and finds nothing, they conclude the agent cannot touch files, even though theos.fs.*tools are built in and always available.This has now come up with more than one user in Discord.
User quote (Discord)
That user has been running local models for a while, so this is not a beginner-only trap: the tools/skills distinction simply is not visible in the product.
Two things make this unavoidable today
/toolscommand. The slash registry has/skills,/model,/memory,/mcpand others, but nothing lists the tool surface./skillsis the only place a user can look, and by design it never contains tools.os.fs.read,os.fs.write,os.fs.list,os.fs.trashand so on. The word "filesystem" appears in no tool name, so even a working tool listing would return nothing for that query.Worth stating explicitly for anyone triaging: these tools carry the frequent tier, so they are in the prompt on every turn. The capability was never missing, only its discoverability.
Proposal
/toolscommand listing the built-in tool surface, grouped by family (os.fs,os.shell,browser,memory,vision)./skillsview, show a short line such as "Built-in tools (fs, git, browser, memory, vision) are always available and are not listed here."/skillsfor built-in families ("filesystem", "fs", "git", "browser") say where those live instead of returning an empty result.