By Peng Yuanhong
If you build or run AI Agents, you have probably hit scenarios like these:
• A single task calls several Skills, and every task needs a different combination. A coding task doesn't need a search engine; a data analysis task doesn't need PDF handling. Today the only option is to mount everything and let the Agent read through dozens of Skill descriptions on every turn just to pick the two or three it actually needs.
• Skills get updated, break, or get tampered with, and you have no easy way to tell which version the Agent is running right now.
• An Agent's context window is finite. Cramming every Skill into it wastes tokens and gives the Agent so many options that it picks the wrong tool.
In the end, what Skills lack is a governance layer.
An Agent needs a stable entry point for reaching Skills, and a plain folder mount isn't enough. That entry point has to answer three questions: which Skills should this task see? Is this Skill trustworthy? And if something goes wrong, is there a fallback?
That is exactly what SkillFS does.
SkillFS is one of the runtime widgets in ANOLISA. ANOLISA builds the runtime foundation for Agents across four directions — token optimization, runtime enhancement, Agent observability, and security — and SkillFS owns the Skill governance layer: how a Skill becomes visible, how it earns trust, and what catches it when things go wrong.
SkillFS is a virtual file system built on Filesystem in Userspace (FUSE). It transforms physical Skill folders into the /skills/<skill> runtime entry point, and decides what the Agent actually sees based on the view, the security policy, and the lifecycle state.
The core experience
| What you need | What SkillFS gives you |
|---|---|
| A stable Agent entry point |
/skills/<skill> doesn't change with version, scan status, or install flow |
| Skill groups trimmed per task | A view exposes only the Skills the current task needs, cutting token consumption and mis-selection |
| Bad Skills never exposed directly | Risky Skills can be hidden or backed off to a trusted snapshot |
| Developer tools keep working |
ls, cp, mv, vim, chmod, and others work normally under the mount point |
| Security adopted incrementally | A standardized security policy extension API, with no changes to SkillFS itself |
SkillFS does more than remount a folder under a new path. It trims the Skill collection down to just the ones the current task needs.
In practice, SkillFS splits Skill visibility into several layers:
• Default runtime view (/skills/<skill>): the stable entry point the Agent uses day to day, exposing only the Skills in the current view configuration. This is the only path the Agent needs to know about.
• Discover view (/skills/skill-discover): shows Skills that are active but not loaded by default; the Agent steps in to explore as needed.
• Install candidate inbox (/.skillfs-inbox/<skill>): the write channel for new Skills or fixed versions; nothing enters the runtime view before a decision passes.
• Reserved lifecycle namespaces (.staging / .certified / .quarantine / .archive): namespaces reserved for the upcoming state machine, invisible in regular views.
Views are driven by the skillfs-views.toml configuration. You organize Skills by category (code, search, media, writing, and so on) and let the configuration decide which group the current task sees. The Agent's readdir returns only the Skills in the current view; everything else sits quietly in the discover view.
Fewer irrelevant Skills = fewer tokens spent + a lower chance of picking the wrong tool.
When your Agent faces dozens of Skills but the current task needs five, view clipping keeps it from searching every description and choosing the wrong one. This isn't a nice-to-have; it's what you need once your Skill collection grows.
We designed 27 test scenarios across 38 Skills (grouped into five categories: content, analysis, devops, agent, and knowledge), covering three patterns — single-category execution, multi-Skill collaboration, and autonomous cross-view switching. Each scenario ran four rounds, and we averaged the results:
| Model | Average cost without SkillFS (tokens) | Average cost with SkillFS (tokens) | Cost savings |
|---|---|---|---|
| kimi-2.5 | 174,167 | 136,942 | 21.37% |
| minimax-m2.5 | 185,282 | 171,369 | 7.51% |
| qwen3.6-plus | 203,396 | 188,744 | 7.20% |
| qwen3.5-plus | 190,713 | 188,918 | 0.94% |
On most models, view clipping saved 7%–21% of tokens. The effect was strongest on kimi-2.5, which saved more than twenty percent. How much you gain depends on the model's own tool selection policy: the better a model is at retrieving Skills, the more it benefits.
Cost formula: cost_tokens = (prompt_tokens - cached_tokens) × 1 + cached_tokens × 0.2
View categorization settles "what you see," but a harder set of questions remains:
• What if a Skill's SKILL.md has been tampered with?
• What if the Agent invokes a newly installed Skill before the scan finishes?
• If a previously trusted Skill turns risky after an update, can it back off automatically?
• Can security actions be audited and explained?
No scan algorithm answers these. They have to be handled in the file system.
SkillFS offers a standardized extension API for security: swap in whatever scan engine, threat model, or signing scheme you like. As long as the resulting decision matches the protocol format SkillFS defines, SkillFS executes it faithfully in the file system layer.
After the baseline version, we did a focused round of security work, all of which is now open source.
Upstream security policies are complex and change often, but by the time they reach SkillFS they reduce to three outcomes, each with its own decision, behavior, and typical scenario. The API stays stable while each side iterates independently.
| Decision | Behavior | Typical scenario |
|---|---|---|
current |
Points at the live source; used normally | Scan passes |
fallback |
Points at a trusted snapshot; still active, but an older version | Scan alert; version drift |
hidden |
Disappears from the view; lookup returns ENOENT
|
Scan denies; content tampered with |
Three-state decisions land through Active Mapping, a runtime mapping table that decides where each path actually points. SkillFS detects source folder changes through Source Drift observation, consumes external security decisions through the External Decision Protocol (a scan → resolve pipeline), and supports hot reloading of activation state with no service interruption. The security side can update a decision at any time, and SkillFS applies it immediately.
One concurrency problem is worth calling out: after the Agent opens a file, what should later reads return if the background has just switched versions? The approach is to snapshot the current Target onto the file handle at open time, so every later read comes from that fixed Target. One open, one self-consistent view of the content.
The .skill-meta/ folder holds security metadata such as activation state and scan results. Write operations from regular users always return EACCES; only an authenticated Trusted Writer can write (using PID + starttime to prevent reuse attacks). At the same time, /.skillfs-inbox/<skill> provides a fencing channel for install candidates: a new Skill lands in the inbox first and enters the runtime view only once the scan decision passes.
Security actions can't be a black box. JSONL audit logs, Source Drift events, activation state change records, and Reconcile observability ensure that "why did this Skill disappear?" can always be traced and explained.
If vim can't even run on SkillFS, no amount of security work matters.
Users will route around SkillFS long before its security ever kicks in — because the editor throws an error, the install script fails, or the build tool misbehaves. So we put serious effort into POSIX compatibility:
• Full support for the main open / read / write / create / mkdir / rename / unlink paths
• Metadata operations such as chmod / chown / utimens / truncate
• Controlled symlink (relative same-skill only) and hardlink (same-skill regular file only)
• user.* xattr passthrough
• PATH_MAX fallback and open-after-unlink support
• Continuous regression testing through the external POSIX harness pjdfstest
The logic is simple: users have to be willing to take this path first, or security administration has nothing to act on.
The question SkillFS sets out to answer is:
When AI Agents start using external Skills at scale, who governs those Skills?
Our approach is to add a file system governance layer that separates a Skill's physical storage from the Agent's runtime view, so view categorization, security policy, version backoff, and auditing all sit on the path the Agent must take to reach a Skill.
View categorization, POSIX compatibility, the security skeleton, and the security enhancements — three-state decisions, activation, and hot reloading — are all open source today. SkillFS installs and runs on its own, with no need to import other ANOLISA widgets first. It's a standalone Rust project: after cargo build –release, run skillfs mount <skills-dir> <mountpoint> to bring the view up, plus subcommands such as validate / list / classify / stop. At runtime it depends only on fuse3, and it currently supports Linux. If you're also thinking about Skill management, security protection, or context optimization for Agents, come take a look.
Stars, forks, and issues are all welcome, and we'd love to talk about how Agent Skill governance should work.
Open source:
https://github.com/alibaba/anolisa/tree/main/src/skillfs
Alibaba Cloud product usage:
https://www.alibabacloud.com/help/alinux/how-to-use-skillfs
People and Agents Finally Share One CLI — Announcing ANOLISA v1.0
123 posts | 6 followers
FollowOpenAnolis - October 10, 2026
OpenAnolis - July 15, 2026
CloudSecurity - April 20, 2026
Alibaba Cloud Native Community - July 17, 2026
Alibaba Cloud Native Community - June 23, 2026
Alibaba Cloud Native Community - March 13, 2026
123 posts | 6 followers
Follow
Alibaba Cloud Linux
Alibaba Cloud Linux is a free-to-use, native operating system that provides a stable, reliable, and high-performance environment for your applications.
Learn More
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Token Plan
Build more, spend less. One plan, every modality.
Learn More
Alibaba Cloud for Generative AI
Accelerate innovation with generative AI to create new business success
Learn MoreMore Posts by OpenAnolis
