ZJU-REAL

plugin-creator

从零攒一个插件包,或把一个 web 链接上的插件下载下来导入。当用户说"照着这个网页做个插件"、"把我这几个技能打包成插件"、"帮我做一个插件"、"这个链接的插件帮我装上"、或需要把一组配套的技能与工具打成可安装可卸载的整体时,务必使用本技能。它教你插件包的目录结构、plugin.json 怎么写、怎么自检、怎么通过 import_plugin 工具落库。

ZJU-REAL 619 53 Updated 2mo ago

Resources

2
GitHub

Install

npx skillscat add zju-real/hugagentos/plugin-creator

Install via the SkillsCat registry.

SKILL.md

插件创建器(Plugin Creator)

插件 = 一组配套的技能 + 工具,打成一个可整体安装、整体卸载的单元。
本技能教你在沙箱里攒出一个结构合法的插件包,自检合格后通过 import_plugin 落库。

只想做单个技能?那不需要插件——用技能管理插件的 skill-creator / register_skill
更直接。插件的价值在于"成套":多个技能配一个工具服务、或者需要统一装卸的一组能力。

一、插件包长什么样

最小可用结构(原生格式):

my-plugin/
├── plugin.json          # 必需:插件清单
├── mcp.json             # 可选:要带工具服务时才有
└── skills/              # 可选:要带技能时才有
    ├── skill-a/
    │   └── SKILL.md
    └── skill-b/
        └── SKILL.md

规则:

  • plugin.json 必须在包根(也接受 .claude-plugin/plugin.json 布局)。没有它就不是插件包,
    import_plugin 会拒绝。
  • skills/ 下每个子目录一个技能,各自必须有 SKILL.md。没有 SKILL.md 的子目录会被忽略。
  • 打包时要 从插件目录内部打,别把外层目录名也裹进去:
    tar -czf /workspace/plugin.tgz -C my-plugin .

二、plugin.json 怎么写

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "一句话说清这个插件给用户带来什么能力。",
  "author": { "name": "……" },
  "extensions": {
    "org.hugagent": {
      "mcp": {
        "my_server": {
          "display_name": "界面上显示的名字",
          "description": "这个工具服务是干什么的。",
          "tools": [
            { "name": "do_something", "description": "……" }
          ]
        }
      }
    }
  }
}

要点:

  • name 就是 slug:小写字母/数字/连字符,会被用来生成安装 id,别用中文和空格。
  • 标准清单本身不放展示字段(显示名、分类、图标属于界面配置,由平台侧维护);
    平台专有字段一律放进 extensions["org.hugagent"]。
  • extensions["org.hugagent"].mcp.<服务名> 里的 display_name / description / tools
    会覆盖补全到对应的 MCP 服务上,服务名必须和 mcp.json 里的键一致,否则贴不上去。
  • 需要用户填凭据时,在扩展段里写 required_secrets(字符串数组),
    安装时平台会据此向用户索要。

字段清单与各种兼容布局详见 references/manifest-spec.md。

三、工具描述怎么写(最影响好不好用的一步)

tools[].description 不是给人看的文档,是模型判断"该不该调这个工具"的唯一依据。
写不好,插件装了也不会被用,或者被乱用。

一条好的工具描述包含四件事:

  1. 它做什么(一句话,动词开头)
  2. 用户说什么话时该调它(把真实说法列进去,"用户说'……'时调用")
  3. 参数从哪来(尤其是 id 类参数:取自哪个工具的返回)
  4. 红线(不可恢复的操作要写"必须先确认";写操作要写"未拿到成功回执前不要声称已完成")

反面例子:"description": "管理数据"——模型无从判断何时该用。

四、完整流程

  1. 在沙箱 /workspace 里按上面的结构建好目录,写好 plugin.json
    (要带技能就再写 skills/*/SKILL.md,要带工具就再写 mcp.json)。
  2. 自检(务必做,结构不对导入会失败):
    python3 scripts/validate_plugin.py /workspace/my-plugin
    退出码 0 才继续。
  3. 打包:
    tar -czf /workspace/plugin.tgz -C /workspace/my-plugin .
  4. 调框架自带的 sandbox_get_artifact("/workspace/plugin.tgz") 取得 artifact_id。
  5. 调 import_plugin(artifact_id) 落库。
  6. 拿到 ✅ 后,把"装进来了哪些技能和工具"讲给用户听。

五、从 web 链接安装

用户给一个下载链接时,同一条路:

  1. 沙箱里 curl -L -o /workspace/pkg.zip "<链接>"
  2. 解压到一个目录,先看清楚里面是什么(有没有 plugin.json)
  3. 跑一遍 validate_plugin.py 自检
  4. 重新打包 → sandbox_get_artifact → import_plugin

安全提醒:来路不明的包不要闭眼导入。至少确认 plugin.json 里的 name、
description 与用户的预期一致,mcp.json 里的 url 指向的是可信地址。
发现可疑内容就停下来问用户,不要替用户承担这个风险。

六、交付前自检

  • plugin.json 在包根,name 是合法 slug
  • 每个 skills/*/ 下都有 SKILL.md
  • mcp.json 的服务名与扩展段里的 mcp 键一一对应
  • 每个工具的 description 写清了"何时该调 + 参数从哪来 + 红线"
  • validate_plugin.py 退出码为 0
  • 是从插件目录内部打的包(tar -C <dir> .)

拿到 ✅ 之前不要声称已经导入成功。

Categories