[stevenjj33]

问题

在 MiniMax Code 里用「从 Git 仓库导入」安装 workflow-console，预览能正确解析出插件名、版本、作者和描述，但计数显示「0 个技能 0 个 MCP Server」，并红字提示「未找到有效的 Skill 或 MCP 能力。」，导入按钮置灰，无法安装。

根因（宿主侧规则，不是这个插件的问题）

宿主「从 Git 仓库导入」在 GithubPluginImporter.readPreview() 里这样判定：

canImport: plugin.skills.length + plugin.mcpServers.length + (plugin.hooks?.length ?? 0) > 0

importGithubPlugin() 在 canImport 为假时直接抛 PLUGIN_NO_SUPPORTED_CAPABILITY：
"Plugin contains no valid Skill, MCP, or Hook capability"。

Mini App（apps / miniapp.json）不计入这个判定。 所以一个只带 Mini App、一个 Skill/MCP/Hook 都没有的插件，走 Git 导入必然被判失败——哪怕它本身完全合法，npm run check 也是 0 errors。

workflow-console 恰好就是这种形状：它自带一个 Mini App，此外没有任何能力声明。

修法

不是绕过校验，而是补上一个本来就该有的能力：一个真正的 Skill。

skills/workflow-console/SKILL.md 告诉 Agent 怎么用这个控制台：

• 引擎启动前必须先选定项目目录，且不要替用户猜；
• 运行在 pending_review 要等审核，审核前要核对拓扑与读写范围；
• approve / pause / cancel / resume 各自意味着什么；
• 复用模板只是新建一份待审核草稿，不是开始执行；
• demo 执行器不调模型，mcodeAvailable: true 不代表已登录或有额度；
• 用户没点头不要替他批准并开始执行。

plugin.json 的 skills 相应声明该文件，版本号提到 1.2.0，两份 README 补了 Skill 章节与文件访问说明。

验证

用宿主自己的 GithubPluginImporter.preview()（@mavis/local-runtime-v2 的 plugin-system import 模块）跑真实 GitHub URL——这就是 UI「预览」按钮调用的同一个后端流程：下载仓库归档 → 解包 → 读清单 → 判定 canImport。

URL	版本	skills	mcp	hooks	miniapp	canImport
MiniMax-AI/.../tree/main/...（修复前）	1.1.0	0	0	0	有	false ← 复现用户看到的报错
stevenjj33/.../tree/fix/workflow-console-git-import/...	1.2.0	1	0	0	有	true

同一份 reader 直接读本地目录的结果一致：修复后 canImport: true，把 skills 清空则回到 false（反向对照）。

Skill 的格式约束按宿主 readPluginSkill() 核对：frontmatter 必须有 name 与 description，且 name 必须等于目录名，路径须为可移植 ASCII。目录名与 name 不一致时宿主报 SKILL_SCHEMA_INVALID（已做反向对照验证）。

另外：

• npm run check（仓库根）：69/69，0 errors；
• 插件测试 node --test "tests/*.test.mjs"：16/16；
• 本机安装副本同步到 1.2.0 后，宿主 miniapp 仍能正常识别并拉起运行时（runtime.ready，无 error 日志）。

给维护者的两点提示

一、这条 canImport 规则对本仓库里其他只带 Mini App 的插件同样成立——它们的 skills 与 mcpServers 也是空数组（例如 plugins/1602winxp/pomodoro-sit-timer、plugins/amszuidas/mcode-token-usage-board、plugins/avatasia/mmc-trajectory 等）。它们走 Git 导入会遇到同样的提示。这是宿主行为，本 PR 只修了自己这一个插件；如果希望所有 Mini App 插件都能直接导入，需要宿主把 apps / miniapp 也算进判定。

二、宿主给整仓归档下载的预算是 60 秒（DOWNLOAD_TIMEOUT_MS = 60_000），而归档体积是整个仓库的体积——本仓库的 zip 约 106 MB，实测下载 38–58 秒。也就是说即使能力判定通过了，网络稍慢仍可能以 GITHUB_ARCHIVE_UNAVAILABLE（"GitHub archive download failed"）失败，这与插件本身无关。想彻底稳，得让宿主按子目录下载，或放宽这个超时。

[stevenjj33]

补一个提交 bd0d99e：把 README.md 也做成中文读者能直接用的版本。

之前英文 README 里没有指向 README.zh-CN.md 的入口，中文读者只能自己猜文件名；而且正文引用了
页面上的中文文案（「开始执行」、pending_review）却没有对照。

改动：

• 加上本仓库通用的语言切换行 [简体中文](README.zh-CN.md) | English（与 cq-viewer、git-tree 等一致）；
• 顶部加一段中文速览，说清它是什么、必须先选项目目录；
• 在正文里把页面上会看到的每个中文标签和英文含义对上：工作目录、待审核、开始执行、内置引擎、
  还没有选择项目目录、审核版本已更新，请刷新后再开始执行。

英文正文一字未改，契约要求的 ## Tested environment / ## Data & access 两个标题原样保留，
npm run check 69/69、插件测试 16/16。

[MyPrototypeWhat]

我核对过的内容（head bd0d99e，在上一版 ed1e1db 基础上增量核对）

• 增量范围：ed1e1db..bd0d99e 只改了 plugins/stevenjj33/workflow-console/README.md 一个文件（+20 / −9）；README.zh-CN.md、代码、Skill、测试和根目录文件都没有变化。
• 增量内容：
  • 顶部加了 [简体中文](README.zh-CN.md) | English 切换行和一段「中文速览」，内容和 README.zh-CN.md 的开头一致。
  • 原来的 “The user interface is in Chinese.” 扩写成一段话，列出页面上的中文术语及英文含义。这部分是行内列表，不是表格。
  • 「工作目录」一节和 Skill 一节的原有英文句子里，加了对应的中文标签（如 Working directory（「工作目录」）、pending_review（「待审核」）），并做了换行重排。英文原意没有变化，-9 行都是这类重排。
• 标签与界面字符串：「工作目录」「待审核」「开始执行」「内置引擎」「还没有选择项目目录」都和 miniapp/client/app.js 里的字符串一致；「审核版本已更新，请刷新后再开始执行」是 miniapp/node/server.mjs:1323 返回 409 时的错误文案，页面会直接显示，和 SKILL.md 的写法也一致。
• 上一版的其他核对结论不受影响：版本 1.2.0、Skill 路径和 frontmatter、SKILL.md 与代码逐条对应，没有涉及额外网络、其他插件数据或包目录外的文件。
• 运行结果（Node 22.23.4）：npm run check 通过，本插件 0 error（2 条 warning 来自 vendor 内 dynamic-workflows 的 stdout，与本 PR 无关），根测试 69/69 通过；插件自带测试 node --test tests/*.test.mjs 16/16 通过。

必须修改

无。

可选建议

1. README 两个语言版本的 Skill 一节里，关于 Git 导入接受条件的那句话描述的是本包以外的规则，规则一变 README 就会过时。建议删掉，或改成中性写法，例如「本包附带 Skill，供 Agent 了解如何操作控制台」。
2. 「数据与边界」里的「运行记录还在引擎数据库里」，可以顺带说明指的是本插件 context.dataDir/engine/ 下的数据，避免被理解成别的数据库。
3. 插件 package.json 没有 test 脚本，在插件目录执行 npm test 会报 Missing script。可以加上 "test": "node --test tests/*.test.mjs"，方便统一运行。