它是什么

wshobson/agents（自述为 Agentic Plugin Marketplace）是一个面向 AI 编程智能体的插件市场型资源库：它把生产可用的 agentic 工作流构建块打包成可安装的插件，原生面向 Claude Code，同时被 OpenAI Codex CLI、Cursor、OpenCode、Antigravity CLI 和 GitHub Copilot 以各自宿主的方式消费。按官方 README 的统计，仓库包含 94 个插件、202 个 agent、183 个 skill、105 条命令，采用 MIT 协议。

它要解决的核心问题是"同一套能力、多个宿主"。近两年各类编码智能体都长出了自己的扩展机制，但形态并不统一：Claude Code 有插件市场与 /plugin 安装流程，Cursor 有 .cursor-plugin/ 目录约定，Codex 有自己的 marketplace 注册表，另有一批工具支持通用的 Agent Skills 规范。若每支持一个工具就复制一份内容，维护成本会随宿主数量线性增长，而且极易出现"两份配置悄悄漂移"的问题。该仓库的做法是只保留一个事实源目录 plugins/，再通过已提交的注册表或生成流程，派生出各宿主能直接识别的产物，并明确强调产出的是"符合各宿主习惯的原生产物"，而不是取各平台交集的降级翻译。

核心功能 / 内容清单

• 单一事实源 plugins/：全部插件、agent、skill、命令的定义都集中在该目录下，按插件（如 python-development）组织。它既是 Claude Code 的安装来源，也是其他宿主注册表指向的目标，避免多份副本不同步。
• 四层内容形态：插件是分发与安装单元；agent 是承担特定角色的子代理（评审、实现、分析等）；skill 是可复用的方法论与知识包；command 是可直接触发的斜杠命令。四者粒度不同，解决了"我只要某个领域的现成打法"和"我要一整套带角色的工作流"这两类不同需求。
• 多宿主分发机制：Codex 与 Cursor 通过仓库内已提交的注册表直接安装，注册表反向指向源 plugins/；Antigravity 与 OpenCode 则通过 make generate 在本地生成转换后的目录树并用 make install-* 落地，这些生成产物被 .gitignore 排除，不进版本库。
• 能力矩阵文档 docs/harnesses.md：记录每种宿主支持哪些产物类型。这一点很关键——不同宿主对 hook、command 等的支持程度并不一致，先看矩阵再安装，能避免"装了却用不了"的预期落差。
• Skills-only 安装通道：gh skill 与 npx skills 两个 Agent Skills 安装器会直接从 GitHub 读取 plugins/*/skills/，写进你正在使用的任意 agent。该通道不需要 clone、不需要 marketplace、也没有生成步骤，代价是只包含 skill，不含 agent、command 或 hook。
• Makefile 驱动的生成与安装：make generate HARNESS=antigravity、make install-antigravity、make install-open-code 覆盖了需要本地转换的宿主，后者会自动串联生成与符号链接，把多步操作收敛成一条命令。

典型使用场景

场景一：Claude Code 用户想快速获得某个领域的成套工作流。 例如在一个 Python 项目里，先执行 /plugin marketplace add wshobson/agents 注册市场，再 /plugin install python-development 安装对应插件，即可获得该领域配套的 agent、skill 与命令，无需自己从头编写提示词与角色划分。仓库共提供 94 个插件，可按技术栈或任务类型逐个挑选，不必全量引入。

场景二：团队内工具链不统一，但希望规范一致。 当团队里有人用 Codex CLI、有人用 Cursor、有人用 Copilot 时，可以从同一个仓库各自安装：Codex 走 npx codex-marketplace add wshobson/agents 后逐个安装插件，Cursor 添加市场后用 /plugin install <name>。由于所有安装都回溯到同一份 plugins/ 源，团队约定的工作流不会因为编辑器不同而产生两份互相偏离的配置。

场景三：只想要方法论，不想引入整套代理体系。 例如你已经在用某个 agent，只是想补上测试写法或代码评审的参考框架，可以直接 gh skill install wshobson/agents python-testing-patterns --agent claude-code，或用 npx skills add wshobson/agents --skill ... 指定单个 skill。此时不会写入任何 agent、命令或钩子，对现有配置的侵入最小。

适合谁用

• 以 Claude Code 为主力工具的开发者：这是仓库的原生目标，安装路径最短，内容覆盖最完整。
• 跨多种编码智能体的团队与平台工程师：需要在不统一工具链的前提下维持一致的工程规范，单一事实源 + 多宿主分发正是为此设计。
• 想研究 agent / skill / command 组织方式的从业者：仓库的结构本身就是一份可参考的实现范例，能看出插件如何分层、角色如何拆分。
• 只需要知识包的轻量用户：通过 skills-only 通道按需取用，不必理解完整的插件体系。
• 相对不适合：希望只用一条提示词、不愿安装任何扩展机制的用户；以及不方便使用 gh、npx、make 等命令行工具链的环境。

快速上手

路径按宿主区分。Claude Code 最简：添加市场后安装任意插件，详细设置与故障排查见 docs/usage.md。Codex 与 Cursor 直接从仓库内已提交的注册表安装，Cursor 侧在添加市场后执行 /plugin install <name>。Antigravity 与 OpenCode 需要先 gh repo clone wshobson/agents ~/agents 克隆到本地，再运行 make generate 与对应的 make install-* 目标。如果只要 skill，使用 gh skill install wshobson/agents 交互式挑选，或用 --all / 指定名称与 --agent 参数直接安装。

各宿主的精确命令、参数与生成细节会随上游工具演进，具体步骤请以官方 README 及 docs/usage.md、docs/harnesses.md 为准。

注意事项

• 平台能力不对等：并非所有宿主都支持全部产物类型，安装前应查阅 docs/harnesses.md 的能力矩阵。skills-only 通道明确不含 agent、command 与 hook，不要误以为装了 skill 就等于装了整套工作流。
• 本地生成需重复执行：Antigravity 与 OpenCode 的转换产物被 gitignore，仓库更新后需重新 generate 才能同步，不能只靠一次安装长期有效。
• 依赖外部工具链：安装过程涉及 GitHub CLI、Node/npx 与 make，环境缺失会直接导致失败；命令本身也绑定在各宿主与第三方 CLI 的现有接口上，上游变更时可能失效。
• 建议按需安装：94 个插件的体量不宜全量引入，插件越多，注入到上下文与配置中的内容越多，反而不利于聚焦任务。
• 扩展不等于安全沙箱：agent、command、hook 类产物可能触发命令执行，引入第三方插件前应确认其内容与行为。
• 许可：仓库本身为 MIT 协议，可自由使用、修改与再分发；但各宿主工具自身的许可与使用条款需单独遵守，本仓库的协议不覆盖它们。