Agent Tooling & Ecosystem · Blog Post
wshobson/agents: one plugin marketplace for Claude Code, Cursor, Codex, and Gemini CLI
Most cross-tool skill packs pick a lowest common denominator and translate everything down to it. wshobson/agents does the opposite: one Markdown source of truth generates harness-native artifacts for six different agentic platforms, so a Cursor rule looks like a Cursor rule and a Gemini CLI extension looks like one, instead of both looking like an awkward compromise.
By Mehadi Hasan 8 min read
What problem it solves
A team rarely standardizes on one AI coding assistant anymore — one engineer runs Claude Code, another lives in Cursor, someone else is trying Gemini CLI on a side project. Building a shared library of subagents, skills, and commands usually means either picking one tool and leaving everyone else out, or maintaining near-duplicate configs by hand across each one. wshobson/agents is built specifically against that problem: 94 plugins bundling 203 subagents, 175 skills, and 109 commands, authored once and shipped natively to six harnesses.
Scale of the marketplace
Subagents cover architecture, languages, infrastructure, security, data/ML, documentation, business, and SEO — enough breadth that most projects install a handful of relevant plugins rather than one monolithic bundle. The 16 orchestrator plugins are the more interesting layer: instead of one specialist, they coordinate several subagents on a single task — running a security auditor and a performance profiler in parallel and merging their findings, for example.
One source, six native targets
Every plugin follows the same layout, with agents, commands, and skills auto-discovered from their respective folders:
Plugin folder structure
plugins/python-development/ ├── .claude-plugin/plugin.json ├── agents/ # 3 Python agents ├── commands/ # 1 scaffolding command └── skills/ # 16 specialized skills
A generator reads that source of truth and emits harness-native artifacts rather than one shared export format — .cursor-plugin/ and .cursor/rules/ for Cursor, TOML-based skills/agents/commands for Gemini CLI, .copilot/ Markdown profiles for Copilot, an .opencode/ directory structure for OpenCode. Claude Code and Codex CLI read directly from committed registries; Gemini CLI and OpenCode require a local build step first.
Installation per harness
Claude Code
/plugin marketplace add wshobson/agents /plugin install python-development
Codex CLI
npx codex-marketplace add wshobson/agents
Cursor
Add the marketplace, then /plugin install <name>
Gemini CLI
gh repo clone wshobson/agents ~/agents && cd ~/agents make generate HARNESS=gemini && gemini extensions install .
OpenCode
gh repo clone wshobson/agents ~/agents && cd ~/agents make install-opencode
GitHub Copilot
Installs from the committed .copilot/ directory in the repo root or ~/.copilot/
License is MIT across the repo, so pulling a plugin apart and vendoring just the pieces your team needs is explicitly allowed, not just tolerated.
Using it on a mixed-tool team
The practical pattern is picking plugins by domain, not by tool: install python-development once, and every teammate gets the equivalent subagents and skills whether they're driving Claude Code, Cursor, or Gemini CLI. That's the actual pitch — a shared "how we build Python here" artifact that doesn't fork into four maintenance burdens the moment someone switches editors.
Because Gemini CLI and OpenCode need a local make generate step, those two are a slightly heavier lift than the others — worth a one-time setup script if more than one or two teammates are on those harnesses.
My take
This is the repo I'd point to as proof that cross-IDE agent tooling doesn't have to mean the weakest shared subset. The generator-per-harness approach is more engineering than a flat file copy, and it shows in artifacts that actually look native to each tool instead of an obvious port.
The tradeoff is surface area: 94 plugins is a lot to audit, and not every team needs six-harness support. If you're single-tool on Claude Code and want a bigger, simpler catalog with a monitoring layer on top, Claude Code Templates is the better first stop; come here specifically when "works the same for the Cursor person on the team" is the actual requirement.
Frequently asked questions
How does one repo target six different tools without breaking?
The plugins/ directory is the single source of truth. A Makefile-driven generator reads each plugin's agents, commands, and skills and emits harness-native artifacts — .cursor-plugin/ and .cursor/rules/ for Cursor, TOML for Gemini CLI, .copilot/ profiles for Copilot — rather than translating everything into the weakest shared format.
Do I have to install all 94 plugins?
No — plugins are granular and independent. You install by name, for example python-development or agent-orchestration, and only that plugin's agents, commands, and skills land in your project.
What is an "orchestrator" plugin?
The 16 orchestrator plugins coordinate multiple subagents on a single task — for example, running a security auditor and a performance profiler in parallel and merging their findings — rather than defining a single specialist.
Which harnesses install natively vs. require a build step?
Claude Code and (per the README) Codex CLI and Cursor read committed registries directly. Gemini CLI and OpenCode require cloning the repo and running make generate / make install-opencode locally before use.