• AI 技能
• AI 插件
• 人工智能

本指南围绕 agentic-awesome-skills 仓库的 docs/users/workflows.md 展开，系统讲解 Antigravity Workflows 的定义、使用方法与五个可复用的实战工作流（SaaS MVP、Web 安全审计、AI Agent 系统、QA 与浏览器自动化、DDD 核心领域建模），并结合 data/workflows.json 的机器可读元数据与 docs/examples/workflows 下的三个真实工作案例给出可验证的源码级证据。读完本文，你将掌握"选工作流 → 精确安装技能 → 按序执行 → 保留产物"的完整闭环，并学会用aas stack audit复核工作流的每一步证据。

什么是 Antigravity Workflow

Antigravity Workflow（工作流）是一条"有引导、按步骤执行"的路径，它把多个技能组合起来，指向一个具体可交付的结果。它与 Bundle（技能包）的分工非常清晰：

• Bundles告诉你"哪些技能与某个角色相关"；
• Workflows告诉你"如何按顺序使用这些技能去完成一个真实目标"。

原文用一句话概括了两者的关系：If bundles are your toolbox, workflows are your execution playbook.——如果把技能包比作工具箱，那么工作流就是你的执行作战手册。

从数据层看，这一模型在仓库中有直接的机器可读实现。data/workflows.json 是工作流元数据的单一事实来源，顶层声明了generatedAt（2026-02-10T00:00:00.000Z）与version: 1，其下每个工作流对象包含五个字段：

该 JSON 正是 docs/users/workflows.md 中五个工作流的结构化等价物：relatedBundles对应文中"Related bundles"小节，steps[].recommendedSkills对应文中每步的 Skills 清单，notes对应各步骤的执行要点。也就是说，人类阅读 Markdown 获取执行逻辑，工具与自动化则直接消费data/workflows.json。

如何使用工作流

官方给出的使用路径共四步：

1. 挑选工作流：匹配你当前目标的工作流，通读其中列出的技能及其 setup 说明。
2. 只安装你选中的技能：例如先用 dry-run 预览一次 Codex 安装——

   npx agentic-awesome-skills --codex --skills concise-planning,verification-before-completion --dry-run

   检查输出中的目标目录与文件清单，确认无误后去掉--dry-run再执行真正的安装。裸安装（bare install）必须显式给出技能选择，这与 docs/users/getting-started.md 中"裸命令与--antigravity现在必须携带--skills、元数据过滤器或显式--all授权"的安全约束一致——设计上杜绝无选择的全量静默安装。

3. 按顺序执行步骤，并在每步调用该步列出的技能。
4. 保留每步的产出物：计划（plan）、决策记录、测试、验证证据（validation evidence）等，作为后续可审计的痕迹。

与 Bundle 组合使用

工作流可以与 bundles.md（即 docs/users/bundles.md）中的技能包组合：当你需要更广的覆盖面时，先选 Bundle 确定角色级技能集，再用工作流决定执行顺序。例如"Ship a SaaS MVP"工作流明确关联Essentials、Full-Stack Developer、QA & Testing、DevOps & Cloud四个包；对应到 JSON 中的relatedBundles: ["core-dev", "ops-core"]，二者是同一编排的不同表达。

从选择到使用的完整闭环

原文强调了一条"selection-to-use"示例路径（见仓库根 README.md）：通过本地 MCP 发现技能 → 核对出精确的技能 ID → 可选生成 Core 计划产物 → 用受支持的直接安装器预览。需要明确两个边界：

• Core 计划只是评审产物（review artifact），它本身不执行任何安装；
• 直接安装器会先预览自身将产生的变更，只有在用户授权后才会真正安装。

这一"预览先行、授权后装"的原则贯穿整个仓库的安装安全设计，docs/users/faq.md 中同样要求"先审阅--dry-run输出，授权后再去掉该标志重复执行"。

工作流一：交付一个 SaaS MVP（Ship a SaaS MVP）

从零构建并交付一个"最小但具备生产意识"的 SaaS 产品。该工作流的id为ship-saas-mvp，分类为web。

前置条件

• 本地仓库与运行时已配置妥当；
• 有清晰的用户问题与 MVP 范围界定；
• 已选定基本部署目标。

执行步骤

Prompt 示例（直接可复制到你的 AI 助手中）：

• Use @concise-planning to define milestones and acceptance criteria for my SaaS MVP.
• Use @backend-dev-guidelines to create APIs and services for the billing domain.
• Use @frontend-developer to implement onboarding, the empty state, and the initial dashboard.
• Use @browser-automation to create E2E tests for the signup and checkout flows.
• Use @deployment-procedures for a release checklist with rollback steps.

Go 栈注意：若 QA 项目与工具链使用 Go，优先选用@go-playwright；这与 JSON 元数据中该步骤的notes完全一致："Use go-playwright when the product stack or QA tooling is Go-based."

数据层补充：JSON 中该工作流的步骤 2 额外推荐了auth-implementation-patterns（"prefer small vertical slices; keep API contracts explicit and testable"），步骤 5 额外推荐了postmortem-writing（"define release checklist, minimum telemetry, and rollback triggers"）。这些notes正是 Markdown 正文没有展开的实现细节，构成编排时的补充指导。

工作流二：Web 应用安全审计（Security Audit for a Web App）

从范围界定到修复验证，执行一次聚焦的安全评审。id为security-audit-web-app，分类为security，关联Security Engineer、Security Developer、Observability & Monitoring三个包（JSON 中对应security-core+ops-core）。

前置条件

• 已获得明确的测试授权（explicit authorization）；
• 范围内的目标已文档化；
• 可获取日志与环境细节。

执行步骤

Prompt 示例：Use @threat-modeling-expert to map critical assets and trust boundaries for my web app.、Use @idor-testing to verify unauthorized access on multitenant endpoints.、Use @api-security-best-practices to audit auth, billing, and admin endpoints.、Use @verification-before-completion to prove that the mitigations are effective.

数据层补充：JSON 的notes强调了三条执行纪律——范围步骤要"文档化范围内的目标、假设与范围外约束"；API 步骤要"按严重性与可利用性排序，而非只依赖 CVSS 分数"；加固步骤要"跟踪修复负责人与目标日期，用证据验证每项修复"。

工作流三：构建 AI Agent 系统（Build an AI Agent System）

设计并交付一个可测量可靠性的生产级 Agent。id为build-ai-agent-system，分类为ai-agents，关联Agent Architect、LLM Application Developer、Data Engineering（JSON 中core-dev+data-core）。

前置条件

• 收窄用例（narrow use case）且结果可测量；
• 可访问模型提供商与可观测性工具；
• 具备初始数据集或知识语料。

执行步骤

Prompt 示例：Use @agent-evaluation to define benchmarks and success criteria for my agent.、Use @rag-implementation to design chunking, embedding, and retrieval pipelines.、Use @langgraph to implement the agent graph with fallbacks and human-in-the-loop flows.、Use @kaizen to prioritize fixes for the failure modes identified by testing.

数据层补充：JSONnotes提供了关键实现纪律——步骤 1 "在实现前设定延迟、质量与失败率阈值"；步骤 2 "保持检索质量可测量，并对 prompt/工具契约做版本管理"；步骤 3 "从受限的工具权限与显式回退行为开始"；步骤 4 "用测试数据集与失败分桶（failure buckets）引导每一轮迭代"。

工作流四：QA 与浏览器自动化（QA and Browser Automation）

创建可在 CI 中确定性执行的、健壮的浏览器自动化。id为qa-browser-automation，分类为testing，关联QA & Testing、Full-Stack Developer。

前置条件

• 测试环境与稳定凭据；
• 已识别关键用户旅程；
• 可用的 CI 流水线。

执行步骤

Prompt 示例：Use @e2e-testing-patterns to define a minimal but high-impact E2E suite.、Use @go-playwright to implement browser automation in a Go project.、Use @systematic-debugging to classify and resolve flaky behavior in CI.

数据层补充：JSONnotes给出两条实操准则——步骤 1 "聚焦业务关键流程并保持环境搭建确定性"；步骤 3 "按根因分类失败：选择器漂移（selector drift）、时序、环境、数据"；步骤 2 明确工具选型："Go 原生项目用 go-playwright，JS/TS 技术栈用 Playwright"。此外 JSON 步骤 1 还额外推荐了code-review-checklist作为质量补充。

工作流五：设计 DDD 核心领域（Design a DDD Core Domain）

对复杂领域做连贯建模，仅在确有必要时才落地战术模式与事件化模式。id为design-ddd-core-domain，分类为architecture，关联Architecture & Design、DDD & Evented Architecture。

前置条件

• 可接触到至少一位领域专家或产品负责人代理；
• 具备当前系统上下文与集成全景；
• 对业务目标与关键领域结果达成一致。

执行步骤

Prompt 示例：Use @domain-driven-design to evaluate if full DDD is justified for our billing and fulfillment platform.、Use @ddd-strategic-design to classify subdomains and propose bounded contexts with ownership.、Use @ddd-context-mapping to model Checkout, Billing, and Inventory interactions with clear contract ownership.、Use @ddd-tactical-patterns to design aggregates and invariants for order lifecycle transitions.、Use @cqrs-implementation and @projection-patterns to scale read-side reporting without compromising domain invariants.

数据层补充：JSONnotes强化了本工作流的方法论基调——步骤 1 要求"文档化为什么需要 DDD、哪些地方保持轻量、成功标准是什么"；步骤 4 强调"从不变量与事务边界出发，而不是从表或端点出发"；步骤 5 明确"仅在一致性（consistency）与规模化（scale）的权衡被显式接受时才使用事件化模式"。这与 DDD 社区"战术模式按需引入"的主流共识一致，避免为模式而模式。

机器可读工作流：面向工具与自动化

对于工具链与自动化场景，工作流的元数据已沉淀在 data/workflows.json。该文件当前收录全部五个工作流，结构上每个步骤都携带title/goal/recommendedSkills/notes四个键：

• title与 Markdown 中的步骤标题一一对应；
• goal是每步的核心验收描述；
• recommendedSkills是可直接解析的技能 id 数组，例如["brainstorming", "concise-planning", "writing-plans"]；
• notes是 Markdown 未展开的执行纪律（如"Review the exact skill IDs and support files before an authorized direct installation; Core plans remain review artifacts"）。

这意味着 Agent、CLI 或任何自动化程序都可以直接读取该 JSON 来驱动技能选择与步骤编排，无需解析 Markdown。从源码结构看，data/bundles.json 与data/workflows.json分别承担"按角色聚合技能"与"按目标编排执行"两类职责，恰好呼应 Markdown 中"bundles 是工具箱、workflows 是执行手册"的分工。

记录在案的真实工作案例（Recorded Worked Cases）

为了让工作流不只是纸面建议，仓库在 docs/examples/workflows 下保存了三个真实执行案例，每个案例都附带三件证据产物：aas-stack.json（技能清单清单）、aas-selection-evidence.json（真实 MCP 会话证据）、plan.json（真实 CLI 生成的安装计划）。

案例一：Workbench 导入 QA

Workbench import QA 是对 QA and Browser Automation 的落地验证：Codex 使用配置好的 AAS 16.7.0 MCP 完成了真实技能选择（七个技能，包括react-patterns、typescript-pro、invariant-guard、vitest-skill等），随后在独立 checkout 中执行了 23 项组件/解析器检查并全部通过：

cd apps/web-app npm ci npm exec -- vitest run \ src/pages/__tests__/Workbench.test.tsx \ src/utils/__tests__/workbenchReview.test.ts

案例明确记录了浏览器覆盖的边界：最终桌面/移动端浏览器通过被本地锁定会话阻塞，不视为完整覆盖；屏幕阅读器交互、颜色对比度与所有受支持的浏览器引擎也未被这些测试建立。这是"区分已观察检查与未测试的生产或模型性能声明"的典型示范。

案例二：Bundle 读取边界安全评审

Bundle-read security review 将 Security Audit for a Web App 应用于 AAS 自身的本地 MCP 后端（tools/lib/aas-v1/mcp/server.js、tools/lib/aas-v1/skill-files.js）。案例界定了作用域信任边界，并执行了七项包含性/完整性检查：

npm ci npm run chain node --test tools/scripts/tests/aas_v1_skill_files.test.js

该案例给出的威胁模型与控制映射非常值得借鉴（源码验证于提交251eefb9a58e36d41902dbc4a4fadc4eab72ab66）：

该案例同样克制地声明了边界：这是本地读取边界，不是针对已具特权的宿主进程的沙箱；摘要一致性也不意味着恶意指令可信；不声称 OS 级对抗性竞态认证。

案例三：MCP 搜索契约评审

MCP search contract review 是对 Build an AI Agent System 的落地验证，重点评审 AAS 自身的检索契约（tools/lib/aas-v1/search.js、mcp/server.js、evidence.js）：

npm ci npm run chain node --test tools/scripts/tests/aas_v1_search_filters.test.js

观察结果为 5 项测试全部通过（覆盖 any/all 词检索、必选词与分类/标签过滤、有界输入与继承属性、完整目录可达性、真实的 server 端 search/compose/inspect/evidence 往返）。案例记录了一个重要真实发现：首次六文件导出请求参数达 4,452 字节，命中了发布运行时的 4 KiB 请求上限；改用三文件项目账本后保留全部九个适用能力维度并成功导出——这一真实客户端发现驱动了源码中一个有界工件帧回归修复。案例提醒："不要把发布运行时当作已经修复，也不要把成功的进程内服务器测试当作 stdio 兼容性的证明。"

用aas stack audit复核历史证据

三个案例都提供了同一条证据复核命令（需在 AAS 源码 checkout 之外运行，否则 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

观察结果为status: "consistent"：证据/计划/清单的 manifest、catalog、target 与 skills 全部绑定一致。该命令只验证历史示例的绑定结构，不执行技能安装；后续 catalog 身份不同，绝不可静默替换。这也再次印证了原文的纪律："Each case distinguishes observed checks from untested production or model-performance claims. New cases must retain their exact input revision and original evidence."（每个案例区分已观察的检查与未经测试的生产或模型性能声明；新案例必须保留其精确的输入修订版与原始证据。）

工作流编排的核心原则

综合五个工作流与三个真实案例，可以提炼出 AAS 工作流编排的四条核心纪律：

1. 最小化安装，显式选择：裸安装必须显式给出--skills清单；先--dry-run预览目标目录与文件列表，授权后再真正安装。安装器对未知或歧义的值采取 fail-closed（关闭即失败）策略。
2. 预览先行，授权后装：Core 计划只是评审产物，直接安装器始终先输出自身变更预览；浏览器端生成的安装命令永不直接执行。
3. 证据留存，边界声明：每步保留计划、决策、测试与验证证据；同时明确区分"已观察检查"与"未测试的生产/模型性能声明"，不夸大结论覆盖范围。
4. 机器可读，人机同源：工作流的权威元数据在 data/workflows.json，与 Markdown 文档一一对应，工具与 Agent 可直接消费，避免文档与数据漂移。

把这些原则落到实处，Antigravity Workflows 就能从一份"技能清单"变成一套可重复、可审计、可验证的交付方法论。

• AI 技能
• AI 插件
• 人工智能