Agentfiles reads 17 coding tools' skill directories from inside an Obsidian vault, and three of them are detection only

Install is three files in a plugins folder, and it needs a desktop

This is an Obsidian community plugin, so there are three ways in. The first is a deep link:

obsidian://show-plugin?id=agentfiles

The second is searching for Agentfiles under Settings and then Community plugins inside Obsidian. The third is manual, and it is three files: download `main.js`, `manifest.json`, and `styles.css` from the latest release, create `<vault>/.obsidian/plugins/agentfiles/`, copy the three into it, and enable the plugin in the same settings panel.

That file list is the whole deployment, and it is why the repository root holds `main.js` next to `manifest.json` and `styles.css`: the artefact a user downloads is the same artefact the build produces, with `main.js` declared as the package entry point.

Desktop only is not a platform preference. The page gives the reason directly: the core purpose requires direct access to skill files outside the current vault, and a mobile vault has no such access.

The support table names 17 tools and fills in paths for 14

The table is four columns wide: skills, commands, rules or memories, and agents. Reading it across, most rows have exactly one entry.

Four tools have more than that. Claude Code has all four, with skills, commands, and agents directories and no rules column. Cursor has skills, rules, and agents. Windsurf has skills plus two rule locations, one under its Codeium directory and one under a separate `~/.windsurf/rules` path. Codex is the only tool with all four filled, using `prompts` where the others use `commands`.

Three rows have no paths at all and are marked detection only: Cline, Claude Desktop, and Aider. So the seventeen tools the page counts resolve to fourteen readable directories, two rule paths for Windsurf, and three tools the plugin can see but not open.

The count also disagrees with the one-line summary attached to the repository, which says Claude Code, Cursor, Codex, and 12 coding tools. Three named plus twelve is fifteen, while the table names seventeen.

Three tools live under XDG_CONFIG and one hides inside a Gemini path

The paths are not uniform, which matters if you script anything against them. Most tools are read under the home directory with a dot directory of their own: Copilot at `~/.copilot/skills/`, Roo Code at `~/.roo/skills/`, Kilo Code at `~/.kilocode/skills/`, Continue at `~/.continue/skills/`, OpenHands at `~/.openhands/skills/`, and Pi at `~/.pi/agent/skills/`.

Three do not. Amp, OpenCode, and Goose are resolved through `$XDG_CONFIG` instead, so their locations follow the XDG convention rather than the home directory convention, and on a system where that variable points somewhere unusual the plugin follows it.

One is worth a second look. Antigravity is read from `~/.gemini/antigravity/skills/`, so a Google tool is found under a Gemini directory, and Pi uses `agent/skills` rather than a bare `skills`.

There is also a shared target rather than a tool: a global `~/.agents/skills/` directory, which is the one place where skills from several tools can meet. Windsurf's split is the odd one out, with memories under `~/.codeium/windsurf/` and rules under a second directory outside it.

Marketplace installs are pinned to a commit and capped at 200 files

The marketplace is the one part of the plugin that reaches the network, and the constraints on it are specific enough to check against a listing before you install.

Search runs on skills.sh. The selected source is then resolved through the GitHub API, and the download is pinned to a commit SHA rather than to a branch or a tag. Path traversal is rejected. Each install is limited to 200 files and 10 MB.

Those four rules do different jobs. The SHA pin means the bytes you reviewed are the bytes you get, even if the source repository moves afterwards. The traversal rejection is what stops a package from writing outside its install directory. The two caps bound what a single listing can do to your machine.

The same section states the outbound surface in one sentence: marketplace search, preview, and install use skills.sh and GitHub, and nothing else is contacted.

It claims it spawns nothing, and the analytics path still needs Bun

The security section is written as a list of what does not happen, and the shell entry is the strongest claim on the page: Agentfiles does not spawn processes or execute shell commands, and the optional Skillkit actions are shown or copied for the user to run separately. The clipboard entry matches that register, with commands copied only after an explicit button click.

The optional analytics command is where the two claims meet:

bunx @crafter/skillkit@latest scan

An alternative is offered with `npx -y @crafter/skillkit@latest scan`, followed immediately by the note that Skillkit uses the Bun runtime, so `npx` does not remove the Bun requirement. That is an honest correction of its own convenience, and it also means the analytics feature depends on a runtime the plugin itself does not need.

The dependency graph behind this is small and worth naming. The package has exactly one runtime dependency, `@crafter/skillkit` at 0.14, and the scanner you run by hand is the same package at a different version range. The plugin domain is crafter.run and the repository owner is Railly, so the vendor relationship runs through the package rather than the account.

No telemetry is sent, and the dashboard reads a file another tool writes

The analytics story is split in a way that is easy to misread. Agentfiles sends no analytics and no telemetry, and the only network use is the marketplace. The Dashboard, on the other hand, shows usage analytics, burn rate, context tax, and health metrics, and it requires Skillkit.

The bridge between them is a file. The plugin reads `~/.skillkit/agentfiles-snapshot.json` through Skillkit's versioned programmatic API, and the page states that the snapshot remains local. So the numbers on the dashboard arrive because you ran a scanner, not because the plugin phoned anywhere.

That design has a consequence worth stating plainly: the dashboard is as fresh as your last scan, and its contents are whatever the installed scanner version wrote into a snapshot the plugin reads through a versioned interface. Both halves move independently, and the page does not say what happens when they disagree.

The Obsidian scorecard point is handled in the same section: direct filesystem access is flagged as a risk capability by the community review process, and the page discloses it deliberately so a reviewer can judge the exact scope.

Two lockfiles, a committed bundle, and an Obsidian API pinned to latest

The manifest is small and the details are telling. The build is an esbuild script with a production flag, the tests run under Bun, and the aggregate check runs audit, lint, test, and build in that order. Release tagging has its own script. The editor inside the plugin is CodeMirror, with eight separate packages for autocomplete, commands, markdown language support, language, lint, search, state, and view, plus a Lezer highlighter, which is what backs the inline editing with markdown preview.

Two of those entries are worth a second look. The Obsidian API is requested as `latest`, so a development install floats with the host application, and eslint is pinned to major version 9 while everything else carries a caret range.

The repository root holds both `bun.lock` and `package-lock.json` for a project whose test command is `bun test`. It also holds the built `main.js` alongside the source, a `versions.json`, and two directories with no obvious place in an Obsidian plugin: `web/` and `vscode/`.

Two FAQ answers point back up the same page

The page has an FAQ section, and two of its entries resolve to text that is already above them. What can Agentfiles do is answered with a link to the What it does section. How to install it is answered with a link to the Install section. The tools question does at least add something, listing the seventeen names and the global directory in one sentence rather than making you read the table.

The rest of the FAQ is where the useful specifics live, in particular the answer on what Skillkit analytics is, which explains that the plugin imports a portable API and reads a versioned snapshot rather than executing the command line tool.

Full documentation sits on a separate site at agentfiles.crafter.run/docs, and help is offered through the Obsidian community page, that same documentation site, and GitHub issues. The license is stated twice, once in the FAQ answer that it is free and MIT with a link to the LICENSE file, and once as a closing section.

Editorial conclusion

Agentfiles fits someone who keeps skills scattered across a dozen tool directories and wants one place to see them, and who is willing to grant a desktop app filesystem access outside the vault to get it. Four things to check first. That the tool you care about is more than detection only, since Cline, Claude Desktop, and Aider are listed with no paths and only fourteen of the seventeen have a skills directory. That the dashboard is not free, because usage metrics, burn rate, context tax, and health all require you to run a separate scanner and the plugin only reads the snapshot it leaves. That you are comfortable with a single runtime dependency from the same vendor as that scanner, arriving with an unpinned peer of `latest` for the Obsidian API in development. And that your marketplaces deserve the limits this one imposes, a commit SHA pin, path traversal rejection, 200 files, and 10 MB, because those are the numbers standing between a listing and an arbitrary install.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. Railly/agentfiles on GitHub
4. README
5. Releases