open-agent-hub: Linking Skills, Agents and Commands into Eight AI Coding Assistants
A lightweight, zero-dependency CLI tool to manage and activate capabilities for AI coding assistants (such as Claude Code, Cursor, Trae, etc.).
At a glance
- What is it?
- A zero-dependency TypeScript CLI that symlinks Markdown prompt files into the config directories of Claude Code, Cursor, Gemini CLI and five other tools. It is a distribution layer, not a prompt library, and its main design bet is that a symlink is the right unit of sharing.
- Who is it for?
- Adopt it if you already keep prompt files in a repository and want the same skill set visible to Claude Code, Cursor and Gemini CLI without copying directories by hand, and if you are comfortable with symlinks as the delivery mechanism. Skip it if you only use one assistant, since Vercel's skills CLI covers that case with a single npx call and no clone.
- 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 2 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 file placement, not prompt quality
Every AI coding assistant expects its prompts in a different directory. Claude Code reads from .claude/, Cursor from .cursor/, Gemini CLI from .gemini/, Codex from .codex/, and the README lists four more targets. If you write a useful review checklist or a commit workflow, getting it in front of two assistants means maintaining two copies, and getting it in front of eight means eight. open-agent-hub treats the repository itself as the source of truth and the assistant directories as install targets. The README calls the tool a way to 'manage and activate capabilities', and the activation verb is literal: the CLI creates links rather than copying content. The audience is a developer who already has opinions about how their assistant should behave and wants those opinions to travel across editors and CLIs without a sync script.
Three component types, one directory layout
The repository separates capabilities into agents/, commands/ and skills/. Agents are described as expert workflow roles with system prompts, stored as agent-*.md files. Commands are agent-facing slash commands such as /commit, /review and /test-tdd. Skills are the largest group, with the README claiming 83 or more modular capability skills. All three follow what the README calls standardized Markdown with YAML frontmatter metadata, which is what makes a single file portable across assistants that otherwise disagree about configuration. A skills_index.json file holds scanned metadata for the skill set, and skills_sources.json configures the oah sync command that pulls from upstream sources. That split matters: the index is generated, the sources file is hand-edited, and only the second one is something you maintain.
The mechanism is a symlink into a per-tool subdirectory
According to the README, the CLI links files into subdirectories under each tool's config path: <Path>/skills/ for skills, <Path>/agents/ for agents and <Path>/commands/ for commands. So enabling the canvas-design skill for Cursor writes a link under .cursor/skills/ rather than dropping a file at .cursor/. The README notes that subdirectories are auto-created dynamically when you pass a custom --path. Because the link points back at the clone, editing a skill in ~/open-agent-hub changes behaviour in every project that has it enabled. That is the central trade-off of the design: updates are free, and so are accidental breakages. The README also mentions native plugin configurations for Claude Code (.claude-plugin/), Codex (.codex-plugin/) and Cursor (.cursor-plugin/), so directory linking is not the only integration path for those three.
Installation and the commands you actually type
There are two routes. The short one skips the clone entirely: npx skills@latest add guanyang/open-agent-hub installs all skills, and appending --skill remotion installs one. That route covers skills only, and it depends on Vercel's skills CLI rather than anything in this repository. The second route clones to a fixed location and registers the binary: git clone https://github.com/guanyang/open-agent-hub.git ~/open-agent-hub, then cd ~/open-agent-hub and npm link. That gives you the open-agent command plus the aliases open-agent-hub, oah and ahub. From there the verbs are list, status, enable and disable. oah list prints everything scanned. oah status checks the current workspace, and oah status --global checks system configs such as ~/.claude/. oah enable canvas-design turns on one component; bare oah enable turns on all three types. Target selection is a flag: --target=cursor writes to .cursor/, --target=all covers every supported tool, and --path=/path/to/my_agent_dir writes somewhere the tool does not know about. Filters --skills, --agents and --commands are mutually exclusive with a name argument, and -p/--project versus -g/--global decides whether links land in the working directory or in the home directory config.
Symlinks are the failure mode, not the feature
A linked skill is not a vendored copy. Move or delete the clone at ~/open-agent-hub and every project that enabled a component is left pointing at nothing, with no error until the assistant silently stops applying the prompt. The README recommends a fixed location for exactly this reason, but nothing in the command set enforces it. The same property cuts the other way for reproducibility: a teammate who clones the hub at a different path gets a different link target, and a CI container that never runs oah enable sees none of it. There is also a scope question the documentation does not resolve. Running oah enable --global --target=all touches eight home-directory config trees at once, and the README does not describe a dry-run flag or a rollback beyond oah disable. If you work across several machines with different assistant versions, the global path is the one to be cautious about.
Where the README stops being specific
The compatibility table marks all eight tools as full compatibility, with project and global paths listed for each. What it does not say is how the tools differ in what they accept. Antigravity, for instance, is listed with a project path of .agents/ and a global path of ~/.gemini/antigravity/, which is a different naming convention from the others, and a reader has to infer whether the same frontmatter keys work there. The README points to docs/Skill_Guidelines.md for trigger rules and the full skill catalog, docs/Agent_Guidelines.md for handoff contracts and the Evaluator-Optimizer loop, and docs/Command_Guidelines.md for slash command conventions. Those three files are where the real specification lives. Anyone evaluating the project should read them before trusting the compatibility table, because the table describes path layout, not prompt semantics.
Vercel's skills CLI is the obvious alternative, and it differs in kind
The README itself offers npx skills@latest add guanyang/open-agent-hub as option one. The difference is not speed, it is what gets installed. Vercel's CLI copies skills into the assistant's directory, so the installed content is self-contained and survives the source repository disappearing. open-agent-hub links instead, so the installed content is a pointer and updates propagate. Vercel's CLI also does not manage agents or slash commands, which is the gap open-agent-hub fills with its own manager. If you want one skill in one assistant, the npx route is less machinery. If you want a shared prompt baseline across several assistants and you intend to keep editing it, the symlink model is the one that avoids a re-install step after every change.
Maintenance, licensing and what to check first
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it also means there is no warranty. No legal advice here; read LICENSE for the actual terms. On maintenance, the release history shows v3.0.0 and v3.0.1 in June 2026 and a push in September 2026, so the project is active, but the README does not document a versioning policy for the skill files themselves. A skill that changes behaviour between hub versions will change behaviour in every linked project at once, and there is no per-project pin described in the material. The repository also carries AGENTS.md, CLAUDE.md and GEMINI.md as project-level coding guidelines, which the README says are derived from andrej-karpathy-skills; those apply to work inside the hub, not to your project. The first thing to verify is the link layout each assistant actually reads, because the README's table describes directories while the tools themselves may expect more.
Editorial conclusion
Adopt it if you already keep prompt files in a repository and want the same skill set visible to Claude Code, Cursor and Gemini CLI without copying directories by hand, and if you are comfortable with symlinks as the delivery mechanism. Skip it if you only use one assistant, since Vercel's skills CLI covers that case with a single npx call and no clone. Before committing, run oah status --global to see what is already linked, then oah enable --target=all in a scratch project and inspect the resulting .claude/, .cursor/ and .gemini/ subdirectories to confirm the layout matches what each tool actually reads.
Community notes