mcpField
V
verification

verification

github.com/fusengine测试与质量3440 次安装2 周前更新
代码仓库

关于 verification

verification 是用于确认任务是否满足原始请求的验证技能，适合在任务完成前检查功能正确性与回归风险。它逐项核对验收标准和证据、运行完整测试、检查修改影响，并要求保存验证记录。

主要功能

  1. 01重读原始请求并列出标准
  2. 02为每项标准收集证据
  3. 03运行完整测试检查回归
  4. 04审查修改文件的副作用
  5. 05保存验证报告并进行挑战审查

适用场景

  1. 01提交任务完成声明前核实需求
  2. 02检查修复是否引入回归或无关改动
  3. 03为后续流程保存验证证据

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/fusengine/agents --skill verification

安装后在 Claude Code 中输入/verification确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
checklist.md
common-misses.md
verify-template.md

详细介绍

验证会确认原始请求是否确实得到满足，这与 sniper 不同，sniper 只确认代码是否整洁。验证按 6 个步骤进行：逐字重读原始请求，列出每项验收标准（明确和隐含的），用具体证据（测试输出、日志、截图、差异）逐项验证，运行完整测试套件以检查回归，检查每个修改过的文件以确认没有意外副作用，然后在记录“功能已解决”这一声明前，先将其交由 `challenger` Agent 审核。

第 6 步始终会保存 .claude/apex/docs/verify-{task-slug}.md：仅在当前上下文中声明“已正常运行”无法跨会话留存，而后续关卡（sniper、elicitation）实际检查的正是这一产物。在 APEX 中，它位于 eLicit 和 eXamine 之间：只有验证和 sniper 都通过，任务才算完成。

完成前验证

概述

Sniper 验证代码质量。验证确认功能已得到解决。 结束任何任务前，两者缺一不可。

Sniper 会捕获 lint 错误、SOLID 违规和代码风格问题。验证则确保原始请求确实得到满足——行为正确、输出正确、修复正确。任务即使通过 sniper 且零错误，功能上仍可能有误。

方面Sniper验证
关注点代码质量功能正确性
检查内容Lint、SOLID、风格验收标准、回归、副作用
运行时机任何代码变更后将任务标记为完成前
结果代码整洁问题解决

Agent 工作流

调用后，在将任何任务标记为完成之前，请遵循以下 6 步验证流程。

6 步验证流程

步骤 1：重新阅读原始请求 回到原始 issue、任务描述或用户消息，逐字阅读。不要依赖记忆或假设。

步骤 2：列出所有验收标准 从原始请求中提取所有明确和隐含的要求，并为它们编号。如果请求含糊不清，请列出合理用户会期待的内容。

步骤 3：用证据验证每项标准 针对每项标准，提供解决问题的具体证据：

  • 显示预期行为的测试输出
  • 确认修复有效的日志输出
  • 展示 UI 变更的截图
  • 显示实现内容的代码差异

步骤 4：检查回归问题 运行完整测试套件。比较修改前后的结果，不得出现新的失败或警告。

步骤 5：检查副作用 检查每个已修改的文件，确认没有意外改动无关代码。确认依赖项和配置没有变更，除非变更是必要的。

步骤 6：确认功能问题已解决——先质疑，再编写产物 在写下“原始问题已在功能上解决”之前，始终将该结论交由 challenger Agent（或 challenge 技能）审查，并使用全新上下文：结论 =“功能问题已解决”+ 步骤 3–5 中的证据，绝不能包含调查推理。这是系统性要求——适用于每个 Verify 门，不得例外，正如 sniper 在每次 eXamine 时都会运行。只有在得到 CONFIRMED 结果（或所有者明确接受 UNCERTAIN 结果）后，才能写下“功能问题已解决”的结论。必须先解决 REFUTED 结论（修复并重新验证），再向所有者提交——这是软性门槛，而非绝对否决。

编写 .claude/apex/docs/verify-{task-slug}.md（模板：references/verify-template.md）：每项验证步骤均须检查，每项标准均须提供一条证据（命令输出、日志摘录、截图路径或差异），并附上本步骤的审查结论。只有“它能用”这类上下文声明无法跨会话保留；写入文件的产物才是 guardrail 门实际检查的内容（包括 sniper 和后续 elicitation 阶段）。然后在回复中明确说明：“原始问题已在功能上解决”，并总结证据；或者列出尚未解决的事项。

{task-slug}：按照 apex-methodology/references/init-tracking.md 推导（git 分支 slug 或活动的 TaskCreate id）——与 elicitation 技能产物采用相同模式。

参考指南

资源路径内容
检查清单references/checklist.md包含所有类别的完整验证清单
常见遗漏项references/common-misses.md经常被忽略的验证项目
产物模板references/verify-template.mdverify-{task-slug}.md 模板及 task-slug 推导方法

与 APEX 集成

在 APEX 工作流中，验证在 eLicit 和 eXamine 之间运行：

Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)

这样可确保在验证代码质量之前确认功能正确性。只有验证和 sniper 均通过，任务才算完成。

关键规则

规则原因
切勿跳过重新阅读原始请求避免解决错误的问题
每项标准都必须有证据“它能用”不是证据
运行完整测试套件，而非仅运行新测试捕捉回归问题
检查所有已修改的文件捕捉意外副作用
验证和 sniper 都必须通过没有正确性，质量毫无意义
步骤 6 将 verify-{task-slug}.md 写入磁盘未持久化状态的上下文内自检会在不同会话间退化

评论

支持 Markdown