go-live-audit

此技能用于编写并运行多 Agent 审计工作流。以下规则不可妥协：

1. 你是在根据随附模板编写一个全新的、针对项目定制的工作流，绝不能盲目运行某个固定脚本。运行前必须填完所有 FILL: 标记。
2. 工作流架构至关重要。模板中的架构和整个控制流部分必须保持不变：Gates → Find → Dedup → Verify → Critic → report。唯一例外是 MAX_PARALLEL（并发上限）——你可以调整其值，但绝不能移除 gate 或用于强制执行该限制的 gAgent 包装器。
3. meta 必须是纯字面量（不得包含变量或插值），否则 Workflow 工具会拒绝它。
4. Finder 和 verifier 只能读取数据。绝不能修改、创建或删除文件，也绝不能运行构建或安装。只有 gate Agent 可以执行命令（构建可能会写入 dist/）。
5. 绝不能在发现或证据中引用机密值——只报告类型和位置，并使用 <REDACTED> 隐去值。
6. 运行前必须确认范围，并告知用户 Agent 数量（通常为 40–80 个）。
7. 这些指示已授权调用 Workflow 工具，无需另行征求同意，但必须先确认范围并发出上述规模警告。

上线审计

输入

• $request：可选的仓库路径、上线背景或关注方向，例如 audit ~/work/myapp before public beta 或 light pass, security only

目标

生成并运行一个针对项目定制的发布前审计工作流，给出可信的上线准备情况判定：

• Gates — 并行运行类型检查 / 测试 / lint / 构建
• Find — 针对每个适用的审计维度，安排一个只读 finder Agent
• Dedup — 安排一个 Agent 合并根本原因相同的发现
• Verify — 通过对抗性 Agent 尝试反驳每项发现；对于阻塞项和高优先级项，加入代码视角和规范视角的审查
• Critic — 指出未覆盖的领域，启动后续 finder，并验证其结果
• 结构化的 GO / NO-GO / GO-WITH-FIXES 报告

所有阶段都通过全局并发 gate（MAX_PARALLEL，默认值为 6）分批执行，因此大范围审查也不会让超过该数量的 Agent 同时运行——Agent 总数不变，但会分波次运行，避免触发 Claude API 速率限制。

步骤 0：确认范围

确认以下事项，仅在不明确时询问用户：

• 仓库（绝对路径）。默认为当前工作目录。
• 上线背景——此处“上线”的含义：公开发布、迎来首批付费客户，或内部 GA。这会影响何种问题算作阻塞项。

不要询问不必要的问题；能从仓库推断时就直接推断。

成功标准：明确目标仓库和上线背景。

步骤 1：了解项目

充分阅读代码库，准确填写模板。收集以下信息：

• 构建／测试命令 — 检查 package.json 中的脚本（以及它是否属于 pnpm/npm/yarn/bun 工作区、turbo 等），或查看 Cargo.toml、go.mod、Makefile、pyproject.toml。确定从代码库根目录运行的确切类型检查／测试／lint／构建命令（references/workflow-template.js 列出了各技术栈的常见命令）。
• 目录结构 — apps/packages 或 src 树；现有模块。
• 权威文档 — 规范／PRD、根目录中的 CLAUDE.md、README、docs/。注明权威顺序（例如“规范 > CLAUDE.md > 代码”）。
• 产品用途 — 用一段话说明产品是什么、面向哪些用户。
• 硬性不变量 — 项目绝不可违反的规则（来自规范／CLAUDE.md）：隐私保证、安全／租户规则、“到处软失败”、架构约定、反功能。如果没有相关文档，则推导出合理的通用规则（数据完整性、读取敏感数据时进行授权、不得提交密钥、构建／测试／lint 均通过、上线代码中不得有 TODO／占位内容）。

此处可自由使用 Explore/Glob/Grep/Read；这一步决定审计质量。

成功标准：充分了解技术栈命令、目录结构、权威文档、产品用途和硬性规则，能够不靠猜测填写模板。

步骤 2：选择审查维度

从 references/dimensions.md 中选择实际适用于此代码库的 8–16 个维度——CLI 不需要多租户，静态网站不需要金额计算。可添加目录中未涵盖的项目专属维度。

每个审查器都必须列出要阅读的具体文件／目录和具体且可验证的检查项，不能只写“审查 X 的质量”。最严格的检查应对应项目的硬性规则。

成功标准：每个选定维度都对应代码库中真实存在的部分，且每条审查器提示都包含具体目标和检查项，可独立执行。

步骤 3：填写模板

复制 references/workflow-template.js 并填写所有 FILL: 标记：

• ROOT — 代码库的绝对路径。
• meta — 保持为纯字面量（不得使用变量／插值），否则 Workflow 工具会拒绝。将 description 更新为项目描述；保留各阶段标题。
• PRODUCT_CONTEXT、HARD_RULES — 根据步骤 1 填写。
• SEVERITY_DEFS — 将阻断示例替换为此产品上线前必须解决的问题。
• FINDERS — 使用步骤 2 选出的维度。
• STACK — 填入检测到的命令；将任何门禁设为 null 即可跳过。

保持架构定义和整个控制流部分不变——它们是通用内容。此处唯一可调整的值是 MAX_PARALLEL（默认值为 6）：它限制同时运行的 Agent 数量。如果账号遇到速率限制，就调低（例如 4）；如果账号的速率限制较高，可调高（例如 8–10）以提高吞吐量。不要设为 1–2（这会让审计串行运行），也绝不要删除门禁本身。

成功标准：不再有 FILL: 标记，meta 是纯字面量，且控制流部分与模板逐字节一致。

步骤 4：说明规模，然后运行

告知用户预计会启动多少个 Agent（审查器 + 每个约 1–2 个验证器 + 门禁 + 批评轮次——通常总计 40–80 个 Agent，但默认情况下最多同时运行 MAX_PARALLEL 个（默认值为 6），因此审计会分批进行，不会集中冲击 API），让用户了解预期成本和运行节奏。然后调用 Workflow 工具，并将填写完成的模板设为 script。通过 /workflows 查看进度。

若要迭代修改脚本，请编辑工具返回的已保存 scriptPath，并使用 {scriptPath} 重新调用 Workflow，而不要再次发送整个脚本。

成功标准：工作流启动前，用户已了解预期规模，且工作流运行至完成。

第 5 步：报告

工作流会返回 { gates, findings, finderNotes, stats }。生成发布就绪报告：

• 结论 — GO / NO-GO / GO-WITH-FIXES，由门禁失败和已确认的阻塞问题决定。
• 门禁 — 列出每项门禁的通过／失败情况，并附上失败摘录。
• 按 status 再按 severity 分组的问题。 优先列出已确认的阻塞问题和高严重性问题。 将 uncertain 单独列出（验证者意见不一）。省略或折叠 rejected（验证者已驳回）——只提及数量，不列出详情。
• 对于每个保留的问题：列出严重性、文件:行号、问题描述和验证者的推理。如果有多个发现者标记了该问题，注明 alsoReportedBy。
• 覆盖范围 — 列出 stats（原始与去重后的数量、报告问题的发现者、评审者指出的空白区域），以及评审者标记的任何覆盖盲区。

成功标准：用户无需从头重新推导任何问题，即可根据报告决定是否发布。

防护措施

• 此技能仅负责审计和报告，不会修复问题。不要在此技能中修改应用程序代码——将已确认的问题交给 bugfix 或用户处理。
• 发现者和验证者必须保持只读；编辑提示词时也要遵守这一原则。
• 根据需求调整规模：轻量检查使用较少的发现者，并仅进行代码验证；“全面审计”则使用完整的 16 个发现者、双视角验证和评审者检查。
• 严重性以是否适合上线为准，而非抽象判断——阻塞问题是指依据项目硬性规则，在本次发布前必须修复的问题。
• 绝不要在问题、证据或报告中包含机密值——只说明位置和类型。
• 不要代替用户修改设置文件或安装任何内容。

何时加载参考资料

• references/workflow-template.js 参数化工作流。生成前先阅读；复制后填入每个 FILL: 标记并运行。
• references/dimensions.md 审计维度目录，用于选择发现者；还包含发现者提示词风格指南。

输出约定

报告：

1. 结论——GO / NO-GO / GO-WITH-FIXES，并附一行理由
2. 门禁结果及失败摘录
3. 已确认的阻塞问题和高严重性问题，包括文件:行号、证据和验证者的推理
4. 单独列出不确定的问题（验证者意见不一）
5. 驳回问题的数量（不列详情）
6. 覆盖范围统计和评审者指出的空白