SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场verify

verify

测试与质量

查看项目

更新于 10-15 12:28

技能介绍

用途

verify 用于在归档变更之前，对照变更产物验证实现。它从五个维度进行检查，并使用独立子代理来消除上下文偏差。

适用场景

  • 在归档前验证实现相对于规格产物的完整性
  • 验证提炼后的规格是否与当前代码行为一致（accuracy 模式，source: distill）
  • 通过子代理进行独立验证，以捕捉上下文偏差
  • 将活文档漂移（Layer 1/2/3）作为建议性发现呈现

不适用场景

  • 创建或修改规格产物（使用 /beat:design）
  • 编写任务（使用 /beat:plan）
  • 执行实现（使用 /beat:apply）
  • 归档变更（使用 /beat:archive）

触发示例：“Verify the change” / “Check implementation against spec” / “Run verification”。不应触发：“design a feature” / “implement the change” / “archive it”。

主要能力

  • 并行派发验证子代理和代码审查子代理，两者相互独立。
  • 若一个子代理失败，继续使用另一个的发现；若两者都失败，报告失败，不回退到自我验证。
  • 若用户明确要求跳过子代理，需说明主会话检查存在上下文偏差、不构成验证，确认一次后按用户要求做快速检查，但不写入 verification 字段。只有子代理运行才算验证结果。
  • 在呈现合并报告后，必须将结果记录到 status.yaml 的顶层 verification 字段。若验证完全无法运行（两个子代理都失败），则不记录。

防止合理化

  • “变更很小，我可以自己验证”——自我验证会产生确认偏差。
  • “我在 apply 期间已经审查过代码”——这正是需要独立验证者的原因。
  • “运行两个子代理是过度设计”——代码质量和规格对齐是独立维度。
  • “只运行测试就足够验证”——测试验证行为，但不验证规格对齐、设计遵循或代码质量。
  • “用户让我不要派发代理，所以快速看一眼算验证”——这算快速看一眼，需说明并确认一次，但不设置 verification，归档时仍会警告该变更从未验证。
  • “顺序派发以节省上下文”——它们相互独立，并行派发更快且防止一份报告影响另一份。
  • “报告已交付，写 status.yaml 只是记账”——verification 字段是归档判断 verify 是否运行过的依据。

危险信号

  • 自己验证任何维度而不是派发子代理
  • 顺序派发子代理而不是并行
  • 因为“代码简单”而跳过代码审查
  • 未阅读子代理报告就声称验证通过
  • 在验证期间编辑代码或产物（唯一写入是 status.yaml 中的验证记录）
  • 呈现报告但未在 status.yaml 中记录结果
  • 因子代理失败而回退到自我验证

使用方式

输入

可选指定变更名称。若省略，则从上下文或提示中推断。

步骤

  1. 选择变更：若无名称，查找 beat/changes/ 目录（排除 archive/）；若只有一个则使用；若有多个则用 AskUserQuestion 工具让用户选择。

  2. 读取所有产物并确定测试上下文：从 beat/changes/<name>/ 读取 status.yaml、features/*.feature（若 gherkin 状态为 done）、proposal.md、design.md、tasks.md；读取 beat/config.yaml（若存在）。确定驱动模式：若 gherkin 状态为 done 则 Gherkin 驱动验证；若为 skipped 则 Proposal 驱动验证。确定测试上下文（三层优先级：tag > source > config）：config 层 testing.required 为 false 则全局跳过测试存在性检查；source 层 status.yaml 含 source: distill 则维度 1 切换为 accuracy 模式；tag 层每个场景预期有对应测试（TDD 模式）。修改文件：若 status.yaml 有 gherkin.modified，收集列出的路径及其 .feature.orig 备份路径。

  3. 并行派发验证子代理和代码审查子代理：使用单条消息发起两个 Agent 工具调用。Agent A 验证子代理（subagent_type: Explore）：读取 verification-subagent-prompt.md，仅提供所有产物内容、测试上下文、修改文件列表，不传对话历史或会话上下文。Agent B 代码质量审查（subagent_type: general-purpose）：读取 code-reviewer-prompt.md，提供变更名称和描述、创建/修改文件列表、规划文档、git 范围（若可用）。审查代码质量、架构、命名、错误处理、测试质量、安全和计划对齐，输出为维度 4。回退：一个失败则用另一个；两个都失败则报告失败，不自我验证。

  4. 若可用则运行自动化测试：检测并运行项目测试套件；行为测试使用 testing.behavior 框架（或自动检测）；E2E 测试使用 testing.e2e 框架（或自动检测），若 features/ 含 feature 文件则合并 BDD 特性路径；分别报告行为和 e2e 结果。

  5. 呈现合并验证报告：合并两个子代理报告——维度 1-3 来自验证子代理（规格对齐），维度 4 来自代码审查（代码质量），维度 5 来自验证子代理（活文档同步，仅建议），步骤 4 测试结果（若可用）。

  6. 在 status.yaml 中记录结果：读取 beat/changes/<name>/status.yaml（先读后写，保留现有字段），按 references/status-schema.md 设置顶层 verification 字段：verification: { status: passed, critical: 0, date: YYYY-MM-DD }。status 为零 CRITICAL 发现时为 passed，否则 issues-found；critical 为合并报告中的 CRITICAL 计数，包括步骤 4 失败的自动化测试。不推进阶段——验证结果仅存于此字段。若验证无法运行（两个子代理都失败）则完全跳过记录，改为报告失败。这是 verify 唯一写入的文件。/beat:archive 用它来警告归档未验证的变更。修复后重新运行 verify 会覆盖该字段。

问题分类

  • CRITICAL：必须修复（缺失场景测试[覆盖模式]、不准确场景[accuracy 模式]、未实现目标、设计违规、安全漏洞、步骤 4 失败的自动化测试）
  • WARNING：应该修复（部分覆盖、可能分歧、不可执行测试、Gherkin 质量问题、代码质量关注、活文档漂移——Layer 1/2/3 同步缺口）
  • SUGGESTION：建议修复（模式不一致、小改进、distill 模式缺失测试、模块无 README）

维度 5 为建议性——其发现仅分类为 WARNING 或 SUGGESTION，绝不 CRITICAL。用户决定是否在归档前处理；活文档漂移从不阻止归档。

优雅降级

  • Gherkin 跳过：跳过维度 1，加强维度 2（proposal 对齐）
  • 仅存在 features：仅验证 Gherkin 覆盖
  • Features + proposal：验证覆盖 + 对齐
  • Features + proposal + design：验证全部五个维度（维度 5 仅在活文档存在时）
  • 始终注明哪些检查被跳过及原因

适用场景

适用于采用 beat 工作流、需要在归档前对实现进行独立验证的团队。特别适合需要消除上下文偏差、确保规格与代码一致、并希望自动化测试与代码质量审查并行的开发流程。

限制

  • 不负责创建或修改规格产物、编写任务、执行实现或归档变更。
  • 若两个子代理都失败，验证无法运行，不记录结果。
  • 维度 5 仅为建议性，不阻止归档。
  • 具体配置细节（如 testing.required、source: distill 等）需参考 beat 工作流的相关文档。
  • 官方文档未提供收费、价格、平台等信息。