Antigravity Workflows 技能编排指南：在 agentic-awesome-skills 中用多技能工作流交付 SaaS、安全审计与 AI Agent
【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills
antigravity-workflows 是 AAS（agentic-awesome-skills）仓库中的一个编排型技能，它把"我要交付一个 SaaS MVP""审计 Web 应用安全""构建 AI Agent 系统""跑浏览器 E2E 测试""设计 DDD 核心领域"这类复杂目标，转译成一条条带校验检查点（verified checkpoints）的引导式技能调用序列。读完本文，你将掌握该技能的触发场景、事实来源读取顺序、五步执行方法与失败处理策略、默认工作流路由表，以及如何用--dry-run安全预览技能安装，并能在自己的项目里复现完整的"选择—审查—安装—执行"闭环。
一、这个技能解决什么问题
在拥有 2,000+ 个技能的大型技能库中，最大的痛点不是"没有技能可用"，而是"不知道该按什么顺序、在哪个阶段调用哪些技能"。Bundles（技能包）解决的是"按角色选什么"的问题，Workflows（工作流）解决的是"按顺序怎么执行"的问题——antigravity-workflows 正是后者：一个本地优先的编排器（orchestrator），把多个专精技能组合成一条可重复执行的路径，并在每步之间强制校验完成标准，通过后才放行到下一步。
从源码结构看，该技能本体位于 SKILL.md，配套的独立工作流卡片在 references/workflow-cards.md，同名的另一份副本位于plugins/agentic-awesome-skills/skills/antigravity-workflows/下，二者结构一致。
二、何时使用该技能（触发条件）
根据 SKILL.md 的 frontmatter 描述，当用户请求"使用多个技能并带校验检查点完成某个目标"时应触发本技能。具体而言，满足以下任一条件即可激活：
- 用户想把几个技能组合起来使用，而不想手动逐个挑选；
- 目标是多阶段的（例如：规划 → 构建 → 测试 → 发布）；
- 用户要求对常见场景做最佳实践执行，典型场景包括：
- 交付一个 SaaS MVP（Ship a SaaS MVP）
- 执行 Web 应用安全审计（Security Audit for a Web App）
- 构建 AI Agent 系统（Build an AI Agent System）
- 实现浏览器自动化与 E2E QA（QA and Browser Automation）
- 设计 DDD 核心领域（Design a DDD Core Domain）
三、工作流的事实来源（Source of Truth）
SKILL.md 明确规定：执行时必须按以下顺序读取工作流事实来源，防止凭空编造步骤：
- docs/users/workflows.md —— 人类可读的 playbook 与已记录的真实案例（recorded cases）；
- data/workflows.json —— 机器可读的工作流元数据，供工具与自动化使用。
注意：这两个路径属于 AAS 仓库本身，不一定存在于用户的独立安装中。当独立安装缺少这些文件时，应使用随技能打包的 工作流卡片（standalone workflow cards）作为降级方案。
该技能的纪律约束很明确：
- 不要凭空发明缺失的文件；
- 不要静默地用一个变动中的替代物顶替；
- 不要在用户项目中创建 AAS 文档。
workflows.json 的结构
从 data/workflows.json 可以看到机器可读元数据的标准结构：每个工作流包含id、name、description、category、relatedBundles（关联技能包）以及steps数组，每个步骤包含title、goal、recommendedSkills和notes。这份 JSON 是自动化工具（如 CLI、MCP）消费的契约，而 workflows.md 是给人看的详细 playbook。
已记录的真实案例
docs/users/workflows.md 记录了三个已验证的真实案例，用于说明"可观察检查"与"未经测试的生产声明"之间的严格区分：
- Workbench 导入 QA：真实 MCP 选择、23 个组件/解析器检查、一致的 CLI plan，浏览器覆盖限制被显式说明；
- Bundle 阅读型安全审查：界定信任边界、执行 7 项包含/完整性检查；
- MCP 搜索契约审查：真实 Codex MCP 选择、7 技能不可变 plan、36 次记录调用与 5 项可复现源码检查。
其中 Workbench 案例给出了一个可复现的验证命令（在仓库外目录执行，避免 npm 解析到本地包）：
npm exec --yes --ignore-scripts --package=agentic-awesome-skills@16.7.0 -- aas stack audit \ --manifest /absolute/path/to/workbench-qa/aas-stack.json \ --evidence /absolute/path/to/workbench-qa/aas-selection-evidence.json \ --plan /absolute/path/to/workbench-qa/plan.json该案例实测结果为：Node 24.19.0 + Vitest 4.1.9 下两个文件共23 个测试全部通过，并记录了一个有价值的教训——从仓库根目录运行测试会因缺失 DOM 环境而失败，必须从应用目录运行。
四、如何运行该技能（五步执行法）
SKILL.md 给出了一套完整执行流程，这是本文的核心实操内容：
第 1 步：识别用户的具体目标
先弄清用户要达成的具体产出（concrete outcome），而不是泛泛的任务描述。
第 2 步：提议 1-2 个最匹配的工作流
基于默认路由规则（见第五节）提出候选，不要一次抛出过多选项。
第 3 步：遵循已明确的工作流
如果用户已经指定了某个工作流，直接跟随执行；只有当选择会实质性改变范围时才提问。这避免了无意义的反复确认。
第 4 步：分步执行，逐步校验
这是整个技能的核心机制：
- 宣布当前步骤与预期产物（announce current step and expected artifact）；
- 调用该步骤推荐的技能；
- 进入下一步前校验完成标准（verify completion criteria）；
- 失败处理策略：若检查失败，保留失败记录，修复相关输入或实现，重新运行该检查，通过后才继续；若前置条件不可用，明确报告被阻塞的确切步骤，然后继续其他独立工作；
- 安装前的审查纪律：安装技能前必须审查确切的技能 ID 及其支持文件。使用受支持的直接安装器的
--dry-run（携带所选 ID 与目标目录）进行预览；仅在用户授权范围内安装。核心组合与不可变 plan 只是审查产物，不会自动安装技能。如果预览失败，修正 ID、版本（release）、前置条件或目标目录后再预览；失败的预览永远不授权安装（"A failed preview never authorizes installation"）。
第 5 步：交付收尾产物
执行结束后必须提供三样东西：
- 已完成的产物（Completed artifacts）
- 验证证据（Validation evidence）
- 剩余风险与后续行动（Remaining risks and next actions）
五、默认工作流路由表
SKILL.md 内置了请求类型到工作流 ID 的默认映射：
| 用户请求类型 | 对应工作流 ID |
|---|---|
| 产品交付请求 | ship-saas-mvp |
| 安全审查请求 | security-audit-web-app |
| Agent/LLM 产品请求 | build-ai-agent-system |
| E2E/浏览器测试请求 | qa-browser-automation |
| 领域驱动设计请求 | design-ddd-core-domain |
具体的技能选择与安装器命令，见 reviewed-selection handoff。
六、五大内置工作流详解
以下内容完整继承自 data/workflows.json 的机器可读元数据与 docs/users/workflows.md 的 playbook，可直接对照使用。
6.1 ship-saas-mvp：交付 SaaS MVP
端到端地完成一个 SaaS MVP 的范围界定、构建、测试与发布。
| 步骤 | 目标 | 推荐技能 |
|---|---|---|
| 规划范围（Plan the scope） | 把想法转成清晰的实施计划与里程碑 | brainstorming、concise-planning、writing-plans |
| 构建后端与 API（Build backend and API） | 实现核心数据模型、API 契约与认证基线 | backend-dev-guidelines、api-patterns、database-design、auth-implementation-patterns |
| 构建前端（Build frontend） | 交付带生产级 UX 模式的主要用户流程 | frontend-developer、react-patterns、frontend-design |
| 测试与验证（Test and validate） | 发布前捕获回归并确保关键流程可用 | test-driven-development、systematic-debugging、browser-automation、go-playwright |
| 安全发布（Ship safely） | 带基础可观测性与回滚就绪状态发布 | deployment-procedures、observability-engineer、postmortem-writing |
关联技能包：core-dev、ops-core（即 Essentials、Full-Stack Developer、QA & Testing、DevOps & Cloud）。
实操要点：写代码前先定义问题、用户画像、MVP 边界与验收标准；后端优先做小垂直切片（vertical slices），保持 API 契约显式可测；前端优先做引导流程、空状态和一条完整 happy path；Go 技术栈的 QA 工具链优先选用go-playwright；发布清单需包含最小遥测与回滚触发条件。
6.2 security-audit-web-app：Web 应用安全审计
从范围界定到修复验证的结构化 AppSec 审查流程。
| 步骤 | 目标 | 推荐技能 |
|---|---|---|
| 定义范围与威胁模型 | 识别关键资产、信任边界与威胁场景 | ethical-hacking-methodology、threat-modeling-expert、attack-tree-construction |
| 审查认证与授权 | 发现破损认证模式与访问控制弱点 | broken-authentication、auth-implementation-patterns、idor-testing |
| 评估 API 与输入安全 | 检测高影响 API 与注入风险 | api-security-best-practices、api-fuzzing-bug-bounty、top-web-vulnerabilities |
| 加固与验证 | 把发现转成具体修复并复测 | security-auditor、sast-configuration、verification-before-completion |
关联技能包：security-core、ops-core（即 Security Engineer、Security Developer、Observability & Monitoring）。
实操要点：前置条件包括显式的测试授权、文档化的在范围目标、可用的日志与环境信息；按严重程度与可利用性（exploitability）映射发现，而不只是 CVSS 分数；优先处理账户接管与提权路径；跟踪修复负责人与目标日期，每个修复都必须用证据验证。
6.3 build-ai-agent-system：构建 AI Agent 系统
设计、实现并评估一个生产级 AI Agent。
| 步骤 | 目标 | 推荐技能 |
|---|---|---|
| 定义用例与可靠性目标 | 选择狭窄用例并设定可度量的质量目标 | ai-agents-architect、agent-evaluation、product-manager-toolkit |
| 设计架构与检索 | 设计工具、记忆与检索策略 | llm-app-patterns、rag-implementation、vector-database-engineer、embedding-strategies |
| 实现编排 | 实现编排循环与生产防护措施 | langgraph、mcp-builder、workflow-automation |
| 评估与迭代 | 运行基准场景并系统化改进弱点 | agent-evaluation、langfuse、kaizen |
关联技能包：core-dev、data-core（即 Agent Architect、LLM Application Developer、Data Engineering）。
实操要点：实现前先设定延迟、质量与失败率阈值；保持检索质量可度量，并为 prompt/工具契约做版本管理；从受限的工具权限与显式回退行为开始；用测试数据集与失败分类桶（failure buckets）驱动每轮迭代。
6.4 qa-browser-automation：QA 与浏览器自动化
跨技术栈构建稳健的 E2E 与浏览器驱动验证。
| 步骤 | 目标 | 推荐技能 |
|---|---|---|
| 准备测试策略 | 定义关键用户旅程、环境与测试数据 | e2e-testing-patterns、test-driven-development、code-review-checklist |
| 实现浏览器测试 | 用弹性定位器与稳定等待自动化关键流程 | browser-automation、go-playwright |
| 分诊失败并加固 | 稳定 flaky 测试并建立可重复的 CI 执行 | systematic-debugging、test-fixing、verification-before-completion |
关联技能包：core-dev、ops-core（即 QA & Testing、Full-Stack Developer）。
实操要点：聚焦业务关键流程并保持环境确定性；Go 原生项目用go-playwright，JS/TS 栈用 Playwright；按根因分类失败：选择器漂移（selector drift）、时序、环境、数据。
6.5 design-ddd-core-domain：设计 DDD 核心领域
建模复杂领域，只在有充分理由时实施战术模式与事件驱动模式。
| 步骤 | 目标 | 推荐技能 |
|---|---|---|
| 评估 DDD 适配度与范围 | 判断是否需要完整 DDD 并定义建模范围 | domain-driven-design、architecture-decision-records |
| 创建战略模型 | 定义子域、限界上下文与统一语言 | ddd-strategic-design |
| 映射上下文关系 | 定义上下文集成模式、所有权与转换边界 | ddd-context-mapping |
| 实现战术模型 | 用聚合、值对象、仓储与领域事件编码不变量 | ddd-tactical-patterns、test-driven-development |
| 选择性采纳事件驱动模式 | 仅在需要处应用 CQRS、事件存储、投影与 Saga | cqrs-implementation、event-store-design、projection-patterns、saga-orchestration |
关联技能包：core-dev、ops-core（即 Architecture & Design、DDD & Evented Architecture）。
实操要点：记录为什么需要 DDD、哪里保持轻量、成功长什么样；从不变量与事务边界出发，而不是从表或端点出发；优先显式契约与防腐层；事件驱动模式只在一致性/扩展性权衡显式且被接受时使用。
七、工作流卡片：独立安装的降级执行指南
当 AAS 仓库的 playbook 不存在时，references/workflow-cards.md 提供可直接使用的流程卡片。它的核心纪律是：从用户的实际项目与其指令出发；每个技能 ID 只是候选待审查项，不是强制技术栈，也不是基于元数据的背书；保留用户已选择的工作流，使用项目现有命令与约定。
每个卡片都规定了严格的输入—技能—退出标准：
- Ship a SaaS MVP：输入为目标用户、一条主旅程、当前代码、约束与部署目标。用
brainstorming收敛主产出，用concise-planning定义可观察验收；用api-design-principles与frontend-design对照实际技术栈；用e2e-testing-patterns覆盖核心旅程，仅在授权后使用deployment-procedures。退出标准是：实现的旅程、可观察的测试、明确的部署状态——本地构建不等于已部署产品。 - Security audit：输入为自有代码或显式授权目标与允许的测试方法。用
threat-modeling-expert映射资产与信任边界；只在存在认证时才审查认证，不得发明端点或在授权范围外运行利用命令；用verification-before-completion把每个发现连接到复现与修复后检查。退出时给出受影响路径、实际证据、残余风险与未解决阻塞项；不得从扫描结果推断出安全认证。 - Build an AI agent system：输入为任务、工具权限、数据边界与可度量输出。执行工具前定义其允许的效果与错误行为；用
agent-evaluation选择可观察任务检查。退出时给出真实工具交互及其校验结果，或精确指出哪些真实交互仍未测试；不得用进程内夹具（fixture）冒充真实客户端会话。 - QA and browser automation：输入为现有路由或旅程、支持的视口与实际测试运行器。用
vitest-skill、javascript-testing-patterns做组件/单元检查，用browser-automation、e2e-testing-patterns做浏览器交互，用fixing-accessibility处理命名、键盘访问与错误关联。记录初始、加载、成功与失败四种状态；运行仓库测试命令、修复复现的失败并重跑。屏幕阅读器或设备覆盖不可用时显式标注"未测试"。 - Design a DDD core domain：输入为业务词汇、代表性场景与现有边界。用
domain-driven-design识别核心领域，用ddd-context-mapping描述上下游关系，仅在聚合与不变量确实解决问题时使用ddd-tactical-patterns；用代表性场景对照不变量验证。不得仅为凑 DDD 术语而引入服务或抽象。
这些卡片是程序卡片（procedure cards）而非已完成的案例结果，必须把实际输出与限制和预期退出条件分开记录。
八、审核选择交接（Reviewed-Selection Handoff）：dry-run 安全安装
工作流卡片中给出了关键的安全安装范式。例如，在一个 Codex 项目中实际选择了brainstorming与systematic-debugging后，用受支持的直接安装器预览：
npm exec --yes --ignore-scripts --package=agentic-awesome-skills@16.7.0 -- \ agentic-awesome-skills --release 16.7.0 --path .agents/skills \ --skills brainstorming,systematic-debugging --dry-run操作要点（把示例 ID 替换为你审查后的技能集合）：
- 确认该确切版本确实包含这些技能，并检查其前置条件；
- 如果预览报错，修正原因后重跑预览；
- 只有预览成功且处于现有用户授权范围内，才去掉
--dry-run重复完全相同命令； - 验证生成的技能文件，然后在真实任务上调用所选技能。
该直接安装器拥有这个预览过程的所有权，它不会应用 Core 的 plan——Core plan 始终只是审查产物，安装与否由直接安装器的预览结果决定。相关命令的完整说明可参考 docs/users/workflows.md 中"从选择到使用"（selection-to-use）一节，它串联了本地 MCP 发现、审查后的精确 ID、可选 Core 产物与受支持的直接安装器预览。
九、开箱即用的复制粘贴提示词
SKILL.md 提供了可直接复制的触发语句：
Use @antigravity-workflows to run the "Ship a SaaS MVP" workflow for my project idea.Use @antigravity-workflows and execute a full "Security Audit for a Web App" workflow.Use @antigravity-workflows to guide me through "Build an AI Agent System" with checkpoints.Use @antigravity-workflows to execute the "QA and Browser Automation" workflow and stabilize flaky tests.Use @antigravity-workflows to execute the "Design a DDD Core Domain" workflow for my new service.在 docs/users/getting-started.md 中也有同样风格的快速上手示例：Use @antigravity-workflows and run ship-saas-mvp for my project idea.
十、限制与边界
根据 SKILL.md 的 Limitations 章节，使用该技能时需明确其边界：
- 该技能是编排器，不会替代专精技能本身——它依赖本地已安装的对应技能；
- 没有环境访问、凭据或所需基础设施时，它不能保证成功；
- 对于 Go 技术栈的浏览器自动化，
go-playwright可能要求对应技能已存在于本地技能库中，否则该步骤不可执行。
十一、相关技能
SKILL.md 列出以下关联技能，它们与 antigravity-workflows 协同工作：
concise-planning：定义可观察的验收标准brainstorming：收敛目标与主产出workflow-automation：编排循环与自动化verification-before-completion：完成前验证，连接发现与复现证据
这些技能在仓库 skills/ 目录下均有对应实现，安装后即可与工作流配合使用。
十二、仓库内参考路径速查
- 技能本体：plugins/agentic-awesome-skills-claude/skills/antigravity-workflows/SKILL.md
- 独立工作流卡片：plugins/agentic-awesome-skills-claude/skills/antigravity-workflows/references/workflow-cards.md
- 人类可读 playbook：docs/users/workflows.md
- 机器可读元数据：data/workflows.json
- 真实记录案例：docs/examples/workflows/workbench-qa/README.md、bundle-security、mcp-contract
- 快速上手与 Bundles 对比：docs/users/getting-started.md
整体而言，antigravity-workflows 的价值在于把"技能众多"转化为"路径清晰"：它以明确的顺序读取事实来源，以五步执行法保持每步可验证，以默认路由表快速命中目标工作流，以--dry-run预览守住安装安全边界，最终把复杂目标拆解为带检查点、可交付、有证据的多技能执行序列。
【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
