Agentfiles puts Claude Code, Cursor and Codex skill files inside an Obsidian vault
Browse, create, and edit AI agent files across Claude Code, Cursor, Codex, and 12 coding tools — from Obsidian.
At a glance
- What is it?
- Agentfiles is an MIT-licensed desktop Obsidian plugin that reads and writes the skills, commands, rules and agents directories of 17 coding agents. It is useful if your prompts are scattered across hidden dotfolders and you already live in Obsidian. It is not a portable format, and the Dashboard metrics depend on a separate tool you must run yourself.
- Who is it for?
- Adopt Agentfiles if you run two or more of the listed agents on a desktop machine and already keep notes in Obsidian, because it turns a set of hidden dotfolders into a single searchable view. Do not adopt it if you work primarily on mobile or in a remote container, since the plugin is desktop-only and its whole function is direct filesystem access outside the vault.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is seventeen hidden directories and no shared index
Every coding agent has invented its own place to keep instructions. Claude Code keeps skills in ~/.claude/skills/ and subagents in ~/.claude/agents/. Cursor splits the same idea across ~/.cursor/skills/, ~/.cursor/rules/ and ~/.cursor/agents/. Codex uses ~/.codex/skills/, ~/.codex/prompts/, ~/.codex/memories/ and ~/.codex/agents/. Windsurf writes to ~/.codeium/windsurf/skills/ and also to ~/.windsurf/rules/, which means a single tool can own two config roots. None of these paths is inside a project repository by default, and most start with a dot, so they disappear from a normal file browser. The practical result is that a person running three agents has three overlapping prompt libraries with no way to see them side by side, and no way to notice that the same instruction has drifted into three slightly different versions. Agentfiles targets that specific mess. Its audience is the developer who already maintains dotfiles deliberately and wants an editor with search, a creation wizard and a markdown preview rather than a terminal and a text editor. The README frames the plugin as an AI skills manager for Obsidian, and the tool table is the clearest statement of scope: 17 tools, with three of them (Cline, Claude Desktop, Aider) listed as detection only, meaning Agentfiles can see them but does not manage their files.
How the plugin reaches outside the vault and what it does with what it finds
Obsidian plugins normally operate on the vault they are loaded into. Agentfiles does the opposite: it reads supported agent directories on the local machine and user-configured project paths, which is why the README states plainly that the plugin is desktop only. The mechanism is a directory map rather than a sync layer. Each supported tool is associated with one or more paths, and the plugin presents skills, commands, rules, memories and agents as browsable entries. Editing happens inline with a markdown preview and Cmd+S to save, so the write goes back to the original file in its original location. There is no intermediate format and no export step. That design has a direct consequence worth stating: the files stay in the tool-specific layout each agent expects, so nothing breaks if you stop using Agentfiles, but nothing is unified either. A skill written for Claude Code is still a Claude Code skill. The README also describes a Marketplace that installs from skills.sh, resolving the selected source through the GitHub API and pinning downloads to a commit SHA. Two limits are given for installs: a maximum of 200 files and 10 MB per install, with path traversal rejected. Those are the only concrete numbers in the material, and they are constraints rather than performance claims.
Installing it, and the one optional command that matters
The primary install path is the Obsidian community plugin flow. The README gives a deep link, obsidian://show-plugin?id=agentfiles, and notes that searching Agentfiles in Settings, Community plugins works too. The manual route is three files: download main.js, manifest.json and styles.css from the latest release, create <vault>/.obsidian/plugins/agentfiles/, copy the three files into that folder, then enable the plugin in Settings, Community plugins. That is the standard layout for an Obsidian plugin and nothing here deviates from it. The optional piece is skillkit, which powers the Dashboard's usage analytics, burn rate, context tax and health metrics. The README gives the command as bunx @crafter/skillkit@latest scan, with npx -y @crafter/skillkit@latest scan as an alternative. Read the caveat carefully: skillkit uses the Bun runtime, so npx does not remove that requirement. The relationship between the two tools is narrower than it first appears. Agentfiles imports skillkit's portable API and reads a versioned snapshot at ~/.skillkit/agentfiles-snapshot.json. According to the README, Agentfiles never executes the skillkit CLI; optional skillkit actions are displayed or copied for the user to run separately. If you skip skillkit entirely, the browse, search, create, edit, Marketplace and Conversations features still stand, and the Dashboard loses its data source.
Permissions, and why the Obsidian scorecard flags the plugin
The README addresses this directly rather than burying it. Agentfiles is desktop only because its core purpose requires direct access to skill files outside the current vault. Reads cover the supported agent directories and any user-configured project paths. Writes are scoped to explicit create, edit, install, update or remove actions. On the shell question the README is unambiguous: Agentfiles does not spawn processes or execute shell commands. Network traffic is limited to the Marketplace path, using skills.sh and GitHub for search, preview and install, and the README states that no analytics or telemetry are sent. Clipboard writes happen only after an explicit button click. The README also acknowledges that the Obsidian scorecard can still identify direct filesystem access as a risk capability, and argues that this capability is required for the plugin's purpose. That is an honest framing, and it is also the correct way to read the scorecard flag: a plugin that reads files outside your vault will always trip that check, whether or not it misbehaves. The decision is not whether the capability exists but whether you accept it. The README's disclosure covers the scope; it does not substitute for reading the source if you need more than a disclosure.
Where Agentfiles stops being the right tool
The desktop restriction is the first hard boundary. If your agent configs live on a remote dev box, in a container, or on a machine you reach over SSH, the plugin cannot see them, because it reads the local filesystem of the machine running Obsidian. Mobile is out for the same reason. The second boundary is the detection-only entries. Cline, Claude Desktop and Aider appear in the tool table but the README marks them as detection only, so a user whose workflow centers on one of those three gets visibility and nothing else. Third, the Dashboard is not self-contained. It requires skillkit, which requires Bun, and the snapshot is produced by a command the user runs. A plugin that reports burn rate and context tax from a file you have to regenerate by hand will show stale numbers if you forget, and the README does not describe any automatic refresh. Fourth, the tool table is a snapshot of directory conventions. Agents that change their config layout will need the plugin to change with it, and there is no stated compatibility guarantee beyond the table itself. Finally, the Marketplace limits of 200 files and 10 MB are real ceilings. A large skill bundle that exceeds either will not install, and the README does not describe a manual override for that case.
The alternative is a dotfiles repository, and the difference is who owns the layout
The obvious alternative is the approach this project's own topic list gestures at: keep your agent configuration in a git repository of dotfiles and symlink or copy it into place. That approach treats the files as source code. You get diffs, history, code review and a single place to resolve conflicts, and it works on any machine you can clone to, including remote servers. What it does not give you is a rendered view. You read markdown in your editor and you search with grep or ripgrep, and you have to remember which agent reads which path. Agentfiles inverts the trade. It gives you browsing, content search with a deep search toggle, a stepped creation wizard that asks for tool, type and name, inline editing with preview, and a Conversations view for Claude Code session history with search, tagging and export to the vault. In exchange, the configuration lives in each agent's own directory, and the organizational layer is the plugin rather than the repository. If you already commit those dotfolders to git, the two approaches compose: Agentfiles becomes the editor, git remains the history. If you do not, adopting Agentfiles means your skills are as durable as your last backup. The README does not mention git integration, so treat that as your own arrangement.
Maintenance cost and what the MIT licence leaves to you
The release history shows 0.9.1 and 0.9.0 published on the same day, 2026-08-31, with 0.8.1 about nine days earlier. That cadence suggests active iteration on a pre-1.0 plugin, which cuts both ways: fixes arrive quickly, and interfaces can still move. The maintenance cost for a user is mostly in the tool table. Seventeen agents is a lot of surface area, and each one that changes its directory layout creates work for the maintainer and a silent gap for you until it is patched. Nothing in the material describes a migration or compatibility policy, so pinning to a release you have verified is the cautious move. On licensing, the plugin is MIT, which permits use, modification and redistribution with the licence text preserved. That covers the plugin. It does not automatically cover skills you install from skills.sh, which are third-party content with their own terms, and it does not cover skillkit, which is a separate package published on npm under its own licence. If you plan to redistribute a curated skill set, check each source rather than assuming the plugin's licence travels with the content. This is a description of what the material states, not legal advice.
Editorial conclusion
Adopt Agentfiles if you run two or more of the listed agents on a desktop machine and already keep notes in Obsidian, because it turns a set of hidden dotfolders into a single searchable view. Do not adopt it if you work primarily on mobile or in a remote container, since the plugin is desktop-only and its whole function is direct filesystem access outside the vault. Before installing, verify two things: that the tool table in the README matches the directories you actually use, and whether you want the Dashboard, which requires running bunx @crafter/skillkit@latest scan yourself to produce ~/.skillkit/agentfiles-snapshot.json.
Community notes