open-agent-hub declares version 1.0.0, ships npm test as a placeholder, and symlinks files into eight assistant configs

The published version is 1.0.0 while the tags are at v3.0.1

The release history and the package manifest describe different things. Three releases are published: v3.0.0 and v2.4.1 both dated 2026-06-08, and v3.0.1 dated 2026-06-24. The manifest at the repository root says version 1.0.0, with a description of a unified capability management center for Skills, Agents, and Commands. Since the documented install path for the CLI is a global link from a clone rather than a registry install, the manifest version is what any version check on the command itself would report, and it reports 1.0.0 on a repository whose tags are three majors ahead. The last push to the default branch is dated 2026-10-02, which is nearly four months after the newest tag, so the branch is where current work lives. Two further manifest details are worth knowing. There is no dependencies key and no devDependencies key, which is the literal basis for the zero-dependency claim. There is also no engines key, so no Node version floor is declared even though the tool is linked into a global bin directory.

npm test is the placeholder npm ships with, and it exits successfully

The scripts section of the manifest has exactly one entry, and it is the string npm generates when you run npm init and never replace:

"test": "echo \"Error: no test specified\" && exit 0"

The exit code on that command is 0, so npm test passes on a repository with no tests in it. There is no tests directory in the tree either. That matters more here than it would in most projects, because this tool's entire job is creating and removing symbolic links inside the configuration directories of other people's applications, in either the current working directory or the user's home. A mistake in path resolution does not throw a visible error; it puts a link in the wrong place, and eight assistants then read from it. Nothing in the repository exercises path resolution, target validation, the mutually exclusive filters, or the sync behaviour. The bin block shows the shape of the program: one entry point, four names for it. main points at scripts/hub.js, and open-agent, open-agent-hub, oah, and ahub all resolve to the same file, so whichever alias you type, the code that runs is identical.

One command can write into eight assistants' home directories

Activation has two scopes and a target list, and the defaults are worth reading closely. The scope flag defaults to project level, which links configuration directories inside the current working directory, and the global flag links into the user home configuration folder instead. The target option accepts claude, antigravity, gemini, codex, cursor, trae, opencode, and kiro, plus all to configure every one of them, and it defaults to claude. With no name argument, the command enables all skills, agents, and commands. So the shortest global invocation combines project-wide scope with every assistant, and the documentation does not describe a preview, a dry run, or a confirmation step. The target list also has two asymmetries worth knowing about. Most assistants use a dot directory named after themselves in both scopes, but OpenCode's global path is ~/.config/opencode/ rather than ~/.opencode/, and Antigravity's project path is .agents/ while its global path is ~/.gemini/antigravity/. Neither follows the pattern, so a target list written for the majority case gets two of the eight wrong. Status is reported separately per scope, with the project workspace as the default view and a global flag for the home configuration.

The documented directory tree omits files that exist at the root

The file layout section of the documentation shows a ten-line tree: agents/ for system prompts named agent-*.md, commands/ for slash commands as *.md, docs/, scripts/ holding the CLI manager hub.js, skills/ described as 83+ modular capabilities, spec/, template/, AGENTS.md, and CLAUDE.md. The actual root carries more than that. Three plugin directories exist as real directories, .claude-plugin/, .codex-plugin/, and .cursor-plugin/. GEMINI.md is present alongside AGENTS.md and CLAUDE.md and is named in the note about behavioural guidelines, though not drawn in the tree. Three JSON files at the root are absent from the tree as well: .mcp.json, skills_index.json, and skills_sources.json. The first configures tooling for the repository itself, the second is an index of the skill collection, and the third records where skills are synced from. assets/ and CHANGELOG.md, CONTRIBUTING.md, and SECURITY.md are also unlisted. Two of the omissions matter functionally rather than cosmetically: without skills_sources.json in the tree, the sync command looks like it has no configuration, and the three plugin directories are the mechanism behind the native plugin support that the compatibility table describes.

Syncing replaces files in the same directory it symlinks into your assistants

Many of the skills in the skills directory are said to originate from active open-source communities, and keeping them current is a documented command rather than a manual chore:

# Sync all configured sources
oah sync

# Sync only a specific source (e.g., anthropics-skills)
oah sync anthropics-skills

Configured sources live in skills_sources.json, and the same operation is available as a shell script, ./scripts/sync_skills.sh, for anyone who would rather not go through the CLI. What that means in practice is that the directory being synchronised is the same directory the link command points eight assistants at. A sync is a write into files that are, at that moment, the live content behind symlinks in other applications' configuration folders, so an upstream change lands in your assistants without a prompt and without a per-skill review step. Whether a sync overwrites local edits or merges is not stated. Two details give partial comfort. The sync command names a source, so you can sync one upstream at a time rather than everything. And skills_index.json sits at the root as a separate index file, which is at least a place where the collection can be inspected before running anything. Neither of those is a substitute for reading what sync does to a directory you have already linked.

Symlinks are one of two mechanisms, and three tools also get a native plugin directory

The compatibility model is worth separating into two layers, because they behave differently. The first layer is the one the compatibility table describes: standardised markdown prompts with YAML frontmatter metadata, dynamically linked into subdirectories under each assistant's project or global path, with skills going to a skills/ subdirectory, agents to agents/, and commands to commands/. All eight tools are marked as fully compatible on that basis. The second layer is native plugin configuration, provided for three of them: .claude-plugin/ for Claude Code, .codex-plugin/ for Codex, and .cursor-plugin/ for Cursor. Those three directories exist at the repository root, which means the hub carries plugin manifests for a subset of the tools it supports. What is not documented is how the two layers interact, whether enabling a component also refreshes a plugin manifest, or whether the plugin directories are regenerated on sync. The agents themselves are a small named set rather than a large one, with the agent guidelines specifying Orchestrator, Evaluator, and Optimizer roles and describing handoff contracts between them plus an Evaluator-Optimizer loop. The commands are likewise named examples, with slash commands such as /commit, /review, and /test-tdd.

The npx path installs skills only, and the clone is the artifact you keep

There are two ways in and they cover different amounts of the collection. The first uses Vercel's skills CLI to add skills straight from the repository without cloning anything:

# Add all skills from this repository
npx skills@latest add guanyang/open-agent-hub

# Add a specific skill (e.g., remotion)
npx skills@latest add guanyang/open-agent-hub --skill remotion

That route is described as the easiest option and it is explicitly scoped to the modular skills. If you want agents and slash commands, or you want dynamic management through symlinks, or you want to sync from upstream, this route does not do it. The second route is a clone followed by a global link, and the installation is two commands:

git clone https://github.com/guanyang/open-agent-hub.git ~/open-agent-hub

cd ~/open-agent-hub
npm link

npm link puts four command names on the path, and the guidance is to place the clone in a fixed location for global reference, which in the example is the home directory. So on this route the cloned repository is not a working copy you edit and discard, it is the installed program, and oah resolves paths relative to wherever that clone lives. After linking, management works from anywhere:

# List all dynamically scanned Skills, Agents, and Commands
oah list

# Check link status in your current project workspace (default behavior)
oah status

The choice between the two routes is therefore also a choice between a copy that lives in each assistant's directory and one shared checkout that everything points into.

Everything the tool manages is markdown with YAML frontmatter

Underneath the link management sits a convention rather than a format, and it is the part that makes the tool portable between eight assistants. Components are markdown files with YAML frontmatter metadata, and the file naming is fixed by kind: agent files under agents/ carry the agent- prefix, command files under commands/ are plain markdown, and skills live under skills/. The skills collection is described as 83 or more entries, with a catalog kept in the skill guidelines document rather than in the tree, and the index at skills_index.json is the machine-readable counterpart. A spec/ directory holds the technical specification definitions for capabilities, and template/ holds development templates for all three kinds, so the intended workflow is that a new capability is written against a template, described against the spec, then registered. The guidelines documents are three: one for skills with design standards and trigger rules, one for agents with the role specifications and handoff contracts, and one for commands aimed at agents rather than users. Those documents also hold the definitions that were moved out of the main file, which is why the main documentation is short enough to read in full but does not tell you how to write a skill.

Editorial conclusion

open-agent-hub does one thing with very little code, and that is its argument: no runtime dependencies, one hub.js behind four command aliases, and a directory of markdown that any assistant can read. It also does that thing with no test coverage at all, so treat it as a file management utility rather than as a component of a build. Before you run it, check four things. Read package.json, because the version field says 1.0.0 while the published tags are at v3.0.1, so nothing you install can tell you which generation you have. Decide between project and global activation deliberately, since oah enable with no arguments writes to the current workspace but oah enable with the global flag writes into eight home directories. Read the syncing documentation before you use oah sync, because it replaces files in the same skills directory that is symlinked into those assistants. And check which of your assistants uses .agents/ for project scope while keeping its global scope under ~/.gemini/, since that asymmetry is in the tool rather than in your configuration.

Frequently asked questions

Official sources

1. guanyang/open-agent-hub on GitHub
2. Issues
3. License: MIT
4. README
5. Releases