wshobson/agents: A Multi-Harness Plugin Marketplace With a Single Markdown Source

The problem: one agentic workflow, five different harnesses

AI coding tools each have their own plugin formats, skill layouts, and command systems. A plugin written for Claude Code does not run in Codex CLI or Cursor without translation. wshobson/agents addresses this by maintaining a single source tree under plugins/ and generating harness-native artifacts for Claude Code, Codex CLI, Cursor, OpenCode, Antigravity CLI, and GitHub Copilot. The intended user is an engineering team that wants to reuse domain expertise, such as Python development or security scanning, across multiple CLIs without maintaining separate copies. The README claims 93 plugins, 202 agents, 181 skills, and 105 commands, but note that these are counts from the repository catalog, not verified runtime results. The value is in the translation layer, not in the raw number of items.

How it works: a source tree and per-harness adapters

The core design is a plugins/ directory where each plugin is self-contained. A plugin like python-development contains a .claude-plugin/plugin.json, an agents/ folder, a commands/ folder, and a skills/ folder. The README states that installing a plugin loads only its components into context, not the whole marketplace. This is a deliberate isolation mechanism to keep context usage low. For other harnesses, the repository generates artifacts. For Codex CLI, it emits .agents/plugins/marketplace.json and per-plugin .codex-plugin/plugin.json, plus .codex/skills/ and .codex/agents/ which are gitignored. Cursor gets a thin marketplace and .cursor/rules/. OpenCode and Antigravity install via clone and a make command that generates the transformed trees. The key detail is that each adapter produces harness-native output, not a lowest-common-denominator translation. That means a skill for Codex respects the 8 KB skill cap, while OpenCode gets a permission block derived from a tools allowlist. This is a real architectural choice, and it adds complexity because each harness has its own quirks.

Getting it running: commands for each harness

For Claude Code, the quick start is two slash commands: `/plugin marketplace add wshobson/agents` and then `/plugin install python-development` (or any of the 93). For Codex and Cursor, you add the marketplace via a registry command, such as `npx codex-marketplace add wshobson/agents`, then install individual plugins. Antigravity and OpenCode require a clone and a make step: `gh repo clone wshobson/agents ~/agents && cd ~/agents`, then `make generate HARNESS=antigravity` and `make install-antigravity`, or `make install-opencode` which runs generate and symlinks. There is also a `make generate-all` to produce all five harnesses. The README points to docs/harnesses.md for per-harness gotchas, which is where you should look before relying on any generated artifact. The presence of gitignored generated trees for Codex, OpenCode, and Antigravity means you must regenerate after pulling updates, which is a maintenance consideration.

The tiered model strategy: a cost control mechanism

The repository includes a model tier system that assigns different Claude models to different task types. Tier 0 uses Fable 5 for long-horizon autonomous work like large migrations, and it is opt-in because of premium cost. Tier 1 uses Opus for architecture and security. Tier 2 inherits the user's chosen model. Tier 3 uses Sonnet for docs and testing. Tier 4 uses Haiku for fast operational tasks. This is a practical way to keep costs down when running agentic workflows, because not every step needs the most expensive model. The README says details are in docs/agents.md under model configuration. This is not a feature you get for free: it requires that agents and skills declare their tier usage, and you must verify that your harness actually honors these tiers. The Antigravity adapter maps tiers to aliases like inherit, flash, and pro, which suggests the mapping is not identical across harnesses.

Quality evaluation: a built-in scoring framework

One notable component is plugin-eval, a three-layer evaluation framework. It performs static structural analysis in under two seconds, an LLM judge that evaluates semantics across four dimensions in about 30 seconds using Haiku and Sonnet, and a Monte Carlo layer that runs 50 to 100 simulated runs to measure reliability, taking two to five minutes. You can score a skill with `uv run plugin-eval score path/to/skill --depth quick` or certify it with `uv run plugin-eval certify path/to/skill`. This is a serious attempt to quantify plugin quality, which is rare in this space. However, the README does not show any sample results or thresholds for what counts as certified. The framework exists, but you have to run it yourself to get numbers. The Monte Carlo layer is the most interesting because it tests statistical reliability, but it is also the slowest and may not be practical for every change.

Limitations and failure modes

The biggest limitation is that the multi-harness support is not symmetric. Claude Code is the source of truth, and the other harnesses are generated. The README notes that Codex and Cursor install from committed registries, while Antigravity and OpenCode install via clone and make. That means the generated trees for Codex, OpenCode, and Antigravity are gitignored, so they are not versioned. If you clone the repository and run make, you might get different artifacts depending on the state of the source. The README also mentions a round-trip results document (docs/round-trip-results.md) that contains real-CLI verification recipes, which implies that not everything works out of the box. Another failure mode is the external memory integration: Pensyve is included as a git-subdir entry for Claude Code, but it has no Antigravity integration yet. If you rely on Pensyve, you cannot use it in Antigravity. The 8 KB skill cap for Codex is a hard constraint, and commands are converted to skills, which may change their behavior. The README does not specify what happens when a command cannot be represented as a skill, so you should test that path.

Alternatives: what else is out there

The obvious alternative is to write plugins natively for each harness without a shared source. For example, you could maintain separate plugin repositories for Claude Code and Codex CLI, each with its own format. That approach avoids the generation step and the drift risk, but it multiplies maintenance effort. Another alternative is to use a tool like MCP (Model Context Protocol) servers, which provide a standard interface for tools across many clients. MCP does not translate plugin structures; it standardizes tool invocation. wshobson/agents is different because it generates harness-specific artifacts, not a runtime bridge. The trade-off is clear: the repository gives you a single source of truth but requires you to trust the generation logic. A third alternative is to use a single harness, like Claude Code, and ignore the others. If your team is all-in on one CLI, the marketplace's multi-harness feature is irrelevant, and you only need the plugin catalog.

Maintenance and license considerations

The project is licensed under MIT, which is permissive and allows commercial use, modification, and redistribution, with no copyleft obligations. That is a low-risk license for most engineering teams. The repository is not archived and has a default branch of main, but the last push date is unknown, and there are no recent releases. That means you should check the commit history before adopting. The maintenance cost is real: you must run `make generate-all` after each source change to update the generated harnesses, and you must run `make validate` and `make garden` to catch drift, dead links, and cap violations. The gitignored generated trees mean you cannot rely on the repository's version control to track what was generated. The documentation includes an authoring guide (docs/authoring.md) that describes a portable-content style guide, which suggests that writing new plugins requires following specific conventions to ensure they generate correctly. If you plan to contribute, you need to read that guide. The external memory integration with Pensyve adds a dependency on another project, and its availability varies by harness.

Editorial conclusion

Adopt wshobson/agents if you standardize on Claude Code and want to extend the same plugin catalog to other harnesses without rewriting content. It is a good fit for teams that already use Claude Code's plugin system and need Codex, Cursor, or Copilot variants. Do not adopt it if you need a single binary or a fully supported commercial product; the multi-harness generation depends on make targets and committed registries that may drift. Before adopting, verify the generated artifacts for your harness using `make validate` and `make garden`, and check the round-trip results in docs/round-trip-results.md to see which commands actually work in your CLI.

Official sources

1. Official documentation
2. Official README
3. Project repository