# wshobson/agents: a multi-harness plugin marketplace for Claude Code, Codex CLI, Cursor and Copilot

> The wshobson/agents repository packages 93 plugins, 202 agents, 181 skills and 105 commands behind a single Markdown source that five agentic harnesses consume. The design is genuinely portable; the install story is not uniform, and that is the part to weigh before adopting it.

**wshobson/agents** — Marketplace of 94 agentic plugins, 203 agents, 175 skills, and 109 commands kept in one Markdown source and consumed natively by Claude Code, Codex CLI, and Cursor.

- Repository: https://github.com/wshobson/agents
- Website: https://sethhobson.com
- Stars: 40,086 · Forks: 4,277
- Language: Python
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/wshobson-agents

## The problem wshobson/agents solves: one prompt library, five incompatible harnesses

Agent tooling has fragmented along harness lines. A skill written for Claude Code does not load in Codex CLI. A slash command in Cursor is not a slash command in GitHub Copilot. Teams that want the same review checklist, the same scaffolding command and the same domain agent available in every editor end up maintaining parallel copies that drift apart within a release cycle.

This repository attacks that directly. The README describes it as a marketplace of "production-ready agentic workflow building blocks" with 93 plugins, 202 agents, 181 skills and 105 commands, and states the intent plainly: "One source-of-truth (plugins/), five harnesses." The audience is engineers who already use at least one of Claude Code, Codex CLI, Cursor, OpenCode, the Antigravity CLI or GitHub Copilot, and who want a curated catalog instead of assembling their own directory of Markdown files.

The unit of distribution is the plugin, not the marketplace. That distinction matters more than the headline counts. According to the README, "Installing a plugin loads only its components into context, not the whole marketplace." A plugin is a directory with a manifest, an agents folder, a commands folder and a skills folder. The python-development plugin, for example, carries three agents (python-pro, django-pro, fastapi-pro), one scaffolding command and sixteen skills. You install the slice you want, and the context cost scales with that slice.

## How the multi-harness generation actually works

The mechanism is a generator, not a runtime shim. Everything lives under plugins/ in Claude Code's native layout, and tools/generate.py emits harness-native artifacts from it. The README is explicit that these are not "lowest-common-denominator translations": each adapter produces the idiomatic form for its target.

For Codex CLI the generator writes .agents/plugins/marketplace.json plus a .codex-plugin/plugin.json inside each plugin, and those are committed to the repository. The .codex/skills/ and .codex/agents/ trees are generated but gitignored. The README notes that the Codex adapter respects an 8 KB skill cap and converts commands into skills, because Codex has no separate command concept. Cursor gets a thin .cursor-plugin/ marketplace and curated .cursor/rules/, and reuses the .claude/ tree rather than duplicating it. OpenCode gets .opencode/agents/, .opencode/commands/ and .opencode/skills/, with a permission: block derived from the tools: allowlist and skill names rewritten to be OpenCode-safe. Antigravity CLI gets a self-contained plugin per source plugin under .antigravity/plugins/<p>/, with model tiers aliased to inherit, flash or pro. Copilot gets Markdown agent profiles, SKILL.md skills and commands-as-skills under .copilot/.

That is a real transformation pipeline, and it explains the asymmetry in the install instructions. Codex and Cursor read committed registries, so they can install straight from the repository. Antigravity and OpenCode cannot, because their transformed trees are gitignored and only exist after you generate them locally.

The Makefile confirms the tooling assumptions. All Python runs through uv, with two managed projects: plugins/plugin-eval/ for the adapter framework and evaluation suite, and tools/yt-design-extractor/ for a standalone YouTube extractor described as heavy and optional. There is no pip and no requirements.txt. Three maintenance targets stand out: make generate-all for all five harnesses, make validate for structural checks, and make garden for "drift / dead-link / cap detection". The garden target is the interesting one, because drift between a source plugin and five generated trees is the failure mode this architecture invites.

## Installing wshobson/agents in Claude Code and running a first plugin

Claude Code is the source-of-truth harness, so it has the shortest path. The README gives two commands. The first registers the marketplace, the second installs one plugin by name.

```bash
/plugin marketplace add wshobson/agents
/plugin install python-development
```

After the first command the marketplace should appear in your plugin list; after the second, the python-development plugin's agents, commands and skills become available. The README points at docs/usage.md for the full catalog and troubleshooting, and docs/plugins.md for the list of all 93 plugins, so pick your plugin name from there rather than guessing.

If you are on Codex CLI, the install reads from the committed registry instead:

```bash
npx codex-marketplace add wshobson/agents
```

The README notes you then install individual plugins. Cursor follows a similar pattern: add the marketplace, then run /plugin install <name>, which reads .cursor-plugin/ alongside the source tree.

Antigravity and OpenCode require the clone-and-generate route. The README shows a clone into ~/agents followed by a harness-specific generate and install:

```bash
gh repo clone wshobson/agents ~/agents && cd ~/agents
make generate HARNESS=antigravity && make install-antigravity
make install-opencode
```

The OpenCode target "runs generate + symlinks", so you do not call make generate separately for it. Antigravity uses the agy plugin format. Expect the generated directories to be untracked in git, which matters if you script the setup in CI.

There is also a quality evaluation tool if you want to score a skill before trusting it. The README shows two invocations through uv:

```bash
uv run plugin-eval score path/to/skill --depth quick
uv run plugin-eval certify path/to/skill
```

The score command runs a static structural pass in under two seconds according to the README, while certify goes further. Treat those timings as documentation claims, not measured results.

## Where the five-harness promise breaks down

The capability matrix lives in docs/harnesses.md, and the README itself concedes that the harnesses are not equivalent. Two of the six targets install from committed files. Two require a local build. That is a genuine operational difference, not a cosmetic one: a team that wants the same plugin set in Claude Code and OpenCode has two different provisioning procedures and two different failure modes.

The generated trees are gitignored for Codex, Antigravity and OpenCode. Anyone who clones the repository and expects the harness artifacts to be present will not find them. This also means the repository's own CI cannot validate those trees unless it regenerates them first, which is presumably why make garden exists. If your workflow depends on reproducible checkouts, you are depending on the generator producing identical output on a machine that has uv, the right Python version and the adapter dependencies installed.

The model tier table is another place to look carefully. It maps five tiers onto named models, including a tier 0 described as "opt-in, premium cost" for long-horizon autonomous work. If you are not on a plan that includes those models, the tier assignments in the agents you install may not resolve to what the documentation describes. The README does not document what happens when a tier is unavailable in your harness.

Finally, the scale is a double-edged property. 202 agents and 181 skills is a catalog, not a curated default. Nothing in the README suggests a recommended starting set. Choosing badly means loading agents whose instructions overlap or conflict, and the isolation guarantee only covers what you install, not whether what you installed is coherent together.

## How wshobson/agents differs from a single-harness prompt repository

The obvious alternative is a Claude Code-only plugin marketplace, or simply a personal .claude/ directory of agents and skills that you copy between machines. That approach is simpler: one directory layout, one install command, no generator, no Makefile, no uv-managed Python projects. The trade-off is that it stops working the moment a teammate uses Cursor or Copilot, and the copies diverge.

A second alternative is per-harness community collections, where each harness has its own ecosystem of agent packs. Those tend to be closer to native conventions for their target and may be better tested against it, but you take on the job of keeping four or five of them conceptually aligned yourself.

The distinguishing choice here is that the source of truth is Claude Code's format and everything else is derived. That keeps authoring cheap: you write one Markdown file and the adapters handle the rest, as described in docs/authoring.md. It also means the non-Claude artifacts are only as good as the adapters. The README's claim that each harness gets "idiomatic, harness-native artifacts" is an assertion about adapter quality that a reader should check in docs/harnesses.md and, if it matters, against the generated output itself.

A third reference point is the external memory integration. Pensyve is included as a git-subdir entry for Claude Code and, per the README, maintains its own upstream integrations for Codex CLI, Cursor, OpenCode and Copilot, with Antigravity CLI not yet covered. That is a concrete example of the boundary: cross-harness coverage in this repository is a generator problem, but third-party integrations are a separate problem that the marketplace does not solve for you.

## Licence, maintenance and what an upgrade costs you

The repository is MIT licensed. That is permissive, and it means you can vendor plugins into a private repository, modify them and redistribute them, provided you keep the copyright notice and licence text. It does not tell you anything about the licences of the external entries. The README mentions two external plugins delivered via git-subdir, one of which is Pensyve, hosted in a different GitHub organization. Those carry their own terms, and the README does not state them. If you plan to redistribute a bundle that includes external entries, check each upstream licence rather than assuming MIT covers the whole catalog. This is a factual observation about the repository layout, not legal advice.

The maintenance picture is harder to pin down. The repository is not archived. No last-push date and no releases are documented in the README, so there is no basis for describing it as actively maintained or regularly updated. If that matters to your decision, check the commit history and release list on GitHub directly before committing to it.

Upgrade cost is driven by the generator. When you pull a new revision, the committed Codex and Cursor registries update with it, but your Antigravity and OpenCode trees do not; you rerun the make targets. The Makefile provides make validate for structural checks and make garden for drift, dead links and cap detection, which is the intended way to catch a broken generation. There is no documented rollback path if a regenerated tree turns out worse than the previous one, and the README does not describe version pinning for the adapters. The practical mitigation is to commit your generated trees to your own repository rather than relying on the gitignored defaults.

## Conclusion

Adopt it if you already work in Claude Code or Codex CLI and want granular, auto-discovered agent and skill bundles rather than one monolithic prompt pack. Do not adopt it if you need a single documented install path across all five harnesses, or if a gitignored generated tree is unacceptable in your build. Verify first that the plugin you want exists in docs/plugins.md, then run make validate and make garden after generation to see whether the tree you produced is internally consistent.

## FAQ

### How do I install agents in Claude Code from wshobson/agents?

Run /plugin marketplace add wshobson/agents to register the marketplace, then /plugin install <name> for the plugin you want, for example python-development. The README points at docs/usage.md for full setup and troubleshooting.

### How do I use agents in GitHub Copilot with wshobson/agents?

The Copilot adapter generates Markdown agent profiles, SKILL.md skills and commands-as-skills under .copilot/. The README lists make install-copilot among the Makefile targets, and model assignments map to native Claude models.

### How do I use agents in Codex with wshobson/agents?

Codex installs from committed registries: run npx codex-marketplace add wshobson/agents, then install individual plugins. The generated .codex/skills/ and .codex/agents/ trees are gitignored, and the adapter respects an 8 KB skill cap while converting commands into skills.

## Sources

- [Official documentation](https://sethhobson.com)
- [Official README](https://github.com/wshobson/agents#readme)
- [Project repository](https://github.com/wshobson/agents)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wshobson-agents