Antigravity旧工作流迁移到技能指南

Antigravity 的旧 workflows 要迁到 skills，但迁移后仍能用 /name 调用，不必重新记一套操作。作者给出了自动迁移命令，也补充了目录结构、规则失效的常见原因，以及 Gemini CLI 用户需要调整的位置。

这篇值得看的地方，是把「始终遵守的约束」和「按需执行的任务」分开了。先分清两者，再搬文件，才能避免迁完以后指令还在，行为却不符合预期。

旧 workflow 怎么迁，原来的命令还能用吗

按作者转述，Antigravity 文档写明：现有 workflows 将于 2026 年 10 月 19 日停止工作，新 workflows 系统的说明会「很快」提供。作者在 10 月 30 日检查时，说明仍未上线，文档暂时引导用户使用 skills。

这里的日期和产品状态来自原文，不能当作本文独立核验过的官方公告。

迁移步骤很短：打开 Antigravity 应用，新建聊天，运行 /migrate-workflows。它会将项目目录 .agents/workflows/ 和全局目录 ~/.gemini/config/workflows/ 中的 workflow 转成 skill，并把旧文件改名为 .bak，保留备份。

迁完仍可输入 /deploy-check、/release，也就是继续用 /name 的形式调用。

作者说整个过程大约两分钟，但没有给出不同项目、复杂 workflow 或失败情况的测试记录。这个时间适合理解为操作很短，不是迁移耗时保证。

Skill 放执行步骤，Rule 放长期约束

Skill 是一个包含 SKILL.md 的文件夹。按原文描述，系统先加载名称和描述，真正需要执行任务时，再加载正文。因此，一份很长的操作说明不必一直占着完整上下文。

下面这份文件放在 .agents/skills/deploy-check/SKILL.md，解决的是部署前按顺序检查并汇报结果：

---
name: deploy-check
description: "Runs the pre-deploy checks for this project (lint, tests, production build) and reports pass or fail for each. Use before deploying or when asked if the app is ready to ship."
---

## Deploy check

Run these one at a time and report pass or fail for each:
1. npm run lint
2. npm test
3. npm run build
If something fails, explain why in plain English. Don't fix anything until I say so.

留意 description：它既说明任务，也写出触发场景。作者建议使用你平时请求任务时会输入的词，因为 agent 要靠描述判断何时加载它。最后一行则限定了权限：检查失败后解释原因，未经要求先别修复。

全局 skill 放在 ~/.gemini/config/skills/<name>/；Antigravity CLI 使用 ~/.gemini/antigravity-cli/skills/<name>/。

始终成立的约束写成 Rule，按需执行的多步任务写成 Skill。

例如「校验始终使用 zod」属于 Rule，放进 AGENTS.md 或 .agents/rules/；「如何执行数据库迁移」属于 Skill，放进 .agents/skills/<name>/SKILL.md。旧 workflow 如果只有一句「永远做某件事」，迁移时应该重新归类。

文件放对了，为什么规则还是没生效

作者列出的三个问题，都可能让人误以为 agent 在忽略指令。

第一是触发类型拼错。.agents/rules/ 中的规则文件需要 --- 包围的头部，trigger: 的值必须准确写成 always_on、model_decision、glob 或 manual。alwaysOn 不在支持列表里，不能按预期加载。

第二是目录层级。Antigravity 只扫描 .agents/rules/ 直属文件。像 .agents/rules/frontend/react.md 这样的嵌套文件，除非列进 .agents/rules.json，否则会被忽略。

第三是长度。单个规则文件超过 24,000 bytes 会被截断；所有全局规则和始终启用的规则共享 20,000-token 预算。把所有规范都塞成常驻规则，并不能保证它们全部有效。

原文还单独提醒 Gemini CLI 用户：对免费用户和 Google One 用户，Gemini CLI 已于 2026 年 6 月 18 日被 Antigravity CLI 替代。GEMINI.md 和 AGENTS.md 可继续使用，但工作区 skills 要从 .gemini/skills/ 移到 .agents/skills/。这个替代范围同样是原文的说法，不宜扩大到所有用户。

我的判断

我认同按「约束」和「任务」拆分指令。前端项目的代码规范适合持续生效，部署检查则有明确的开始、步骤和结束条件，按需加载更容易维护。

但这篇提供的是迁移指南，没有自动迁移前后的行为对照，也没有上下文节省量或触发准确率的数据。它解释了机制，尚不足以证明迁移后一定更快、更可靠。

与手工迁移相比，/migrate-workflows 的优势是省操作并留下 .bak；手工整理则方便顺带检查分类和描述。两者都需要验收：文件转换成功，不等于每个旧任务都按原样执行。原文也没有交代名称冲突和已有 skill 的处理方式。

能拿来做什么

• 如果项目仍在用 workflows，可以先运行 /migrate-workflows，再挑一个熟悉的 /deploy-check 或 /release，核对执行步骤与汇报结果。
• 把部署前的 lint、测试和构建整理成一个 skill，并明确失败后是只汇报，还是允许修复，避免检查任务自行扩大范围。
• 排查规则失效时，先检查 trigger: 拼写、文件层级和长度限制，再考虑修改指令措辞。
• 从 Gemini CLI 转过来的项目，可以保留 GEMINI.md 和 AGENTS.md，重点检查工作区 skills 是否已迁到 .agents/skills/。