- What
- agentlink, open source
- Stack
- Rust, Apache-2.0
- Downloads
- 43 + 326, updated daily
Six agents reading one file
If two things have the same format and differ only in where they live, copying is the wrong primitive.
The duplication
Anyone writing rules and skills for coding agents ends up maintaining the same file in several places, one per tool. Claude Code, Cursor, Copilot, Codex, and whatever ships next quarter.
The tools that solve this generate copies from a source directory. That works, and it brings the problems copies always bring: a step you have to remember to run, a copy someone edits by mistake, and an orphan left behind when a file is renamed.
What made a different answer available
By 2026 the ecosystem had converged. For the two things that matter, the format is identical and only the location differs:
-
AGENTS.md, an open specification donated to the Linux Foundation in December 2025, read by more than twenty tools. -
SKILL.md, read by more than thirty.
Once that is true, generating a copy is doing work to produce a file that is byte for byte the file you already had. The alternative is to give the same file more than one name, which is what a filesystem hard link is for.
What that buys
| Generating copies | Sharing an inode |
|---|---|
| Needs a generate step, and you have to remember it | There is no step |
| Edit the wrong copy and the others drift | There is no wrong copy |
| Renaming leaves an orphan behind | Nothing is orphaned |
| Supporting a seventh tool means another copy | It means another path |
Written in Rust, with CI and an Apache-2.0 licence, and published to crates.io so installing it is one command rather than a clone.
Why Rust for a tool that moves files
Distribution. A single binary with no runtime to install, and crates.io as the channel. For a tool whose entire value is removing a setup step, being awkward to install would have undone the point.
369 downloads, 43 on crates.io and 326 on npm, refreshed daily from both registries by a scheduled job rather than by me remembering.
274 of them arrived on the day it was published. That is not interest, it is mirrors, caches and CI discovering that a new package exists, and it is what the first day looks like for anything published to a public registry. Roughly thirty downloads have happened since, across both registries.
I publish it anyway, because the alternative is a phrase like "used by developers" doing work no number here supports. A download counter measures downloads. It does not measure whether one person kept the tool after trying it, which is the thing I would want to know, and there is no telemetry here that could tell me.
What I can point at is that both packages are public, the source is readable, and the design argument above is checkable by anyone who wants to disagree with it. Treat this as evidence about how I make a decision, not about whether anyone bought it.
What carries over
The interesting question was not how to sync files well. It was whether syncing needed to happen at all, and the answer came from noticing that the formats had already converged. Most duplication problems are like that: the expensive fix maintains the duplication carefully, and the cheap one removes the reason it existed.