agr: a Git-backed package manager for agent skills, and what it leaves unresolved
Educational package-manager project for AI agent skills. Not actively maintained.
At a glance
- What is it?
- agr treats agent skills as declared, version-pinned dependencies and installs them into Claude Code, Cursor, Codex and other tools from any public Git repo. The repository labels itself educational and unmaintained, which changes who should actually use it.
- Who is it for?
- agr is worth adopting by teams that already keep .claude/skills and .cursor/skills out of version control and want a manifest plus a lock file instead of hand-copied directories. It is the wrong tool for anyone who needs a maintained dependency with a security response process, and for single-tool users who never share skills across machines.
- 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 35 days ago.
- What is it written in?
- Mainly Python, 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 agr targets: skills that drift between machines
Agent skills are usually directories. A skill for PDF handling or frontend design lives in .claude/skills/ or .cursor/skills/, gets copied between laptops, and slowly diverges. The README states the case directly: skills are "copied around by hand, drift between machines, and live in tool-specific folders." agr's answer is to move the unit of management from the directory to a declared dependency.
The audience is narrow and explicit. This is for teams who want their agent skills "managed as seriously as they manage their code," and the README frames the payoff as onboarding: a new teammate clones the repo, runs one command, and gets the same skills as everyone else. A solo developer with one tool and one machine gets very little from agr, because there is no second machine to drift away from. The value appears at the point where more than one person, or more than one tool, has to see the same skill set.
How agr works: a manifest, a lock file, and tool directories as build output
The architecture has three layers. agr.toml is the declaration. It holds a tools array and a dependencies array, where each entry is either a remote handle with a type field or a local path. agr.lock is the resolution: the README says it "records the exact version of every skill." The tool-specific directories are treated as generated output, and the README makes the analogy explicit by calling .claude/skills/ and .cursor/skills/ "build artifacts, like .venv/ or node_modules/." You gitignore them and commit the two agr files instead.
Handles are paths into GitHub, formatted owner/repo/skill. The README's example, anthropics/skills/pdf, resolves to the pdf/ directory inside github.com/anthropics/skills. There is no registry and no publish step; pushing to a Git repo is the distribution mechanism. Local skills use a path instead, so ./skills/my-internal-skill syncs into every detected tool the same way a remote handle does. The README lists per-tool invocation syntax, which is where the abstraction leaks: the same skill is /pdf in Claude Code, Cursor, Copilot and Pi, $pdf in Codex, and bare pdf in OpenCode.
What the material does not describe is the resolution algorithm itself. The README says agr.lock records an exact version and that agr upgrade "re-fetches skills at their latest upstream version," but it never states whether the lock stores a commit SHA, a tag, or a ref, nor how agr resolves a handle that points at a directory rather than a tagged release. For a tool whose central claim is reproducibility, that is the most important undocumented detail.
Getting it running: install, add, sync, and the -g flag
Installation is a single uv command:
uv tool install agr
The first install is also the manifest creation step. Running agr add anthropics/skills/pdf "auto-creates agr.toml, detects which AI tools you use, and installs the skill into each," according to the README. From there the workflow is five commands: agr add, agr remove, agr sync, agr upgrade, and agr list, plus agrx for one-off execution.
agrx is the interesting one. It "downloads and runs a skill once, then throws it away," leaving agr.toml untouched. That is a genuine trial path, and it avoids the usual problem of evaluating a skill by permanently editing your manifest. agr upgrade takes an optional handle, so agr upgrade pdf re-fetches one skill while bare agr upgrade moves everything.
The -g flag extends add, remove, sync, and list to global scope, meaning skills available across all projects rather than per-repo. Note that upgrade is not in that list. If global skills exist, the README does not say how they are upgraded, which is a gap worth checking before you put anything important in global scope.
The maintenance problem is stated in the repository itself
The repository's own topics include "unmaintained" and "educational." The description says the same thing. The last release in the supplied material is v0.8.4 from April 2026, following a beta and a patch release within the same week, and the last push to the default branch is dated August 2026. The version number sits below 1.0.
This matters more for agr than it would for a formatting tool. agr resolves handles against GitHub at install time, so its useful lifetime is bounded by the stability of the APIs and repository layouts it reads. A package manager that stops receiving updates does not fail all at once; it fails when an upstream assumption changes. The README also points readers to a GitHub issues page for sharing community skills, which is the same place bug reports would go, and there is no stated security policy or disclosure process in the material.
The "educational" label is not incidental. It tells you the project's intent was to demonstrate the pattern, which is a reasonable thing to read as a signal that production dependency status was never the goal.
Where agr is the wrong tool
If you use exactly one agent tool and work alone, agr adds a manifest, a lock file, and a sync step to solve a problem you do not have. Copying a skill directory once is cheaper than maintaining two config files.
If your team needs pinned, audited dependencies with a response process when something upstream changes, agr is the wrong layer. The README's own framing is that publishing is "just pushing to a Git repo," which means there is no review gate, no signing, and no revocation. A skill is code that runs inside your agent's context, and agr installs it from any public repo the handle names. The convenience and the trust model are the same design decision.
The third failure mode is environmental. Because tool directories are treated as disposable build output, anything you hand-edit inside .claude/skills/ will be overwritten or orphaned on the next sync. Teams that have already accumulated local tweaks in those directories face a migration, not an install.
The alternative: committing skill directories directly
The obvious alternative is to skip the tool and commit .claude/skills/ and .cursor/skills/ to Git as ordinary files. That approach has no manifest, no lock file, and no sync command, but it also has no resolution step that can fail. Git already gives you exact versions, review in pull requests, and reproducible checkouts. What it does not give you is cross-tool installation: if your team uses Claude Code and Cursor side by side, you either duplicate the skill into both directories by hand or write your own copy script.
That is the real dividing line. agr's contribution is not versioning, which Git already does well. It is the multi-tool fan-out plus a lock file that pins remote skills you do not control. If your skills all live in your own repo and your team uses one tool, plain Git is simpler and has no unmaintained dependency. If you pull skills from third-party repos into several tools, agr is doing work you would otherwise script yourself, and the question becomes whether you want to own that script or depend on this one.
Licence and what adoption actually costs
agr is MIT licensed. That is permissive: you can use, modify, and redistribute it, including in commercial settings, provided the copyright notice and licence text are preserved. MIT says nothing about the skills you install through agr. Those come from third-party repositories under their own licences, and agr does not appear to surface licence metadata for dependencies in the material provided. If you vendor a skill into a commercial product, the licence question belongs to that skill's repository, not to agr. This is a description of the licence text, not legal advice.
The maintenance cost is the more concrete number. With the project marked unmaintained and sitting at 0.8.x, the realistic upgrade path is that you fork it or vendor it. That is cheap in MIT terms and expensive in attention terms: a Python CLI that resolves Git handles needs periodic attention as GitHub's APIs and the target tools' skill directory conventions change. Budget for owning it, not for receiving it.
Editorial conclusion
agr is worth adopting by teams that already keep .claude/skills and .cursor/skills out of version control and want a manifest plus a lock file instead of hand-copied directories. It is the wrong tool for anyone who needs a maintained dependency with a security response process, and for single-tool users who never share skills across machines. Before committing, verify three things: that agr sync reproduces an identical skill set on a second machine, that the lock file actually pins a commit rather than a moving branch, and that the handle resolution you depend on still works against the current GitHub API.
Community notes