oh-my-claudecode 的 verify 技能实战用证据取代应该没问题的完成声明【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode导读本文讲解 oh-my-claudecode 项目中内置的verify技能skills/verify/SKILL.md——一套把我觉得应该没问题这类口头完成声明转变成可验证、可复现证据的标准化验证流程。它适用于功能开发、缺陷修复、重构等任何需要向用户交付确实能工作结论的场景。读完本文你将掌握 verify 技能的 5 步工作流、4 级验证优先级、硬性规则与输出契约并通过仓库内的验证模块源码src/features/verification/index.ts、Verifier 专属 Agentagents/verifier.md与分层验证策略docs/shared/verification-tiers.md理解其底层实现与落地方式。verify 技能是什么verify是 oh-my-claudecode 内置技能之一其 frontmatter 定义如下name: verify description: Verify that a change really works before you claim completion技能的唯一目标Goal被定义为一句话Turn vague it should work claims into concrete evidence. 把含糊的应该能工作声明转化为具体的证据。在 oh-my-claudecode 中用户可以通过斜杠命令/oh-my-claudecode:verify target触发该技能参见 docs/REFERENCE.md 与 docs/REFERENCE.md。这一命令由 commands/verify.md 兼容性命令承载它并不重复加载完整技能描述而是保持/oh-my-claudecode:verify可用并在被调用时去读取活动 OMC 插件安装中的skills/verify/SKILL.md把用户参数作为$ARGUMENTS交由技能处理。若从当前工作目录无法直接读取该文件则定位到CLAUDE_PLUGIN_ROOT/OMC_PLUGIN_ROOT、包根目录或已安装的 OMC 插件目录后继续执行。技能触发词被注册在斜杠命令自动识别列表中见 src/hooks/auto-slash-command/constants.ts并在迁移文档中替代了旧的ultraqa命令见 docs/MIGRATION.md。五步工作流从要证明什么到只报告已验证的SKILL.md 定义了严格的执行顺序每一步都在缩小不确定性的范围识别必须被证明的确切行为Identify the exact behavior that must be proven —— 不是笼统的做完功能而是明确哪个行为、在什么输入下、应该产生什么结果。优先使用已有测试Prefer existing tests first —— 已有回归测试是最廉价、最可靠的证据来源。若覆盖缺失运行现有最窄的直接验证命令run the narrowest direct verification commands available —— 选择范围最小、针对性最强的命令避免全量构建/全量测试造成噪音。若直接自动化仍不足描述手动验证步骤并收集具体可观察证据describe the manual validation steps and gather concrete observable evidence —— 手动验证不等于口头断言必须产出可观察的现象。只报告实际已验证的内容Report only what was actually verified这套由自动到手动、由宽到窄的思路与仓库中验证分层策略Verification Tiers的取舍逻辑一脉相承验证强度应随任务复杂度伸缩以控制成本同时保证质量。四级验证优先级SKILL.md 明确规定了验证手段的优先级顺序任何一层都不应跳过直接跳到下一层已有测试Existing tests类型检查 / 构建Typecheck / build窄范围直接命令检查Narrow direct command checks手动或交互式验证Manual or interactive validation这一顺序在 Verifier Agent 的 Investigation Protocol 中有更细的落地见 agents/verifier.mdDEFINE定义哪些测试能证明它能工作哪些边界情况重要什么可能回归验收标准是什么EXECUTE并行执行用 Bash 运行测试套件用lsp_diagnostics_directory做类型检查运行构建命令用 Grep 搜索应当一并通过的相关测试。GAP ANALYSIS缺口分析对每个验收标准标记VERIFIED测试存在且通过且覆盖边界/PARTIAL测试存在但不完整/MISSING无测试。VERDICT裁决PASS全部标准验证通过、无类型错误、构建成功、无关键缺口或FAIL任一测试失败、类型错误、构建失败、关键边界未测、无证据。类型检查/构建被放在第二优先级与其在源码中的必须属性一致在验证模块的STANDARD_CHECKS中BUILDbuild_success对应npm run build与TESTtest_pass对应npm test均为 required 检查项见 src/features/verification/index.ts。四条硬性规则不许在无证据时宣布完成SKILL.md 的 Rules 部分是对 Agent 行为的约束底线没有证据就不要说变更已完成Do not say a change is complete without evidence检查失败必须明确包含失败信息If a check fails, include the failure clearly如果不存在现实的验证路径要明确说明而不是虚张声势If no realistic verification path exists, say that explicitly instead of bluffing优先给出简洁的证据摘要而不是嘈杂的日志Prefer concise evidence summaries over noisy logs这些规则在 Verifier Agent 中被强化为 Failure Modes To Avoid见 agents/verifier.md列出了最容易踩的坑Trust without evidence无证据的信任只因实现者说它能工作就批准。必须自己运行测试。Stale evidence过期证据使用 30 分钟前、早于最新改动的测试输出。必须重新运行。Compiles-therefore-correct能编译即正确只验证能构建不验证满足验收标准。要检查行为。Missing regression check缺失回归检查验证了新功能却没有检查相关功能是否仍正常。要评估回归风险。Ambiguous verdict含糊裁决基本能工作。必须给出明确的 PASS 或 FAIL 及具体证据。Verifier 还明确要求验证必须是与作者分离的独立检查通道Never self-approve且不得出现should/probably/seems to这类词汇——一旦出现即视为证据不足而直接拒绝见 agents/verifier.md 与 agents/verifier.md。这一要求同样写入了 Prompt SSOT 的 Verifier 角色定义It should work is not verification见 generated/prompt-ssot/role-verifier.md。输出契约四条必答项验证完成后输出必须包含以下四项不可省略已验证了什么What was verified运行了哪些命令/测试Which commands/tests were run哪些通过了What passed哪些失败了或仍未验证What failed or remains unverified在仓库中这一契约被 Verifier Agent 具体化为强制的结构化交付物见 agents/verifier.md其最终消息必须包含VerdictPASS | FAIL | INCOMPLETE附 Confidencehigh/medium/low与 Blockers 计数Evidence 表格Check / Result / Command-Source / Output 四列例如npm test的 X passed / Y failed、lsp_diagnostics_directory的错误数、npm run build的退出码Acceptance Criteria 表格每条标准对应 VERIFIED / PARTIAL / MISSING 状态及具体证据Gaps缺口描述、风险等级high/medium/low与关闭建议RecommendationAPPROVE | REQUEST_CHANGES | NEEDS_MORE_EVIDENCE及一句话理由。同时有明确的 Final Response Contract最后一次消息必须承载完整的结构化验证报告禁止以 done、complete、looks good 之类的空话收尾。Verifier Agent 的前置声明agents/verifier.md也界定了其职责边界负责验证策略设计、基于证据的完成检查、测试充分性分析、回归风险评估与验收标准校验不负责编写功能executor、收集需求analyst、代码风格审查code-reviewer或安全审计security-reviewer。源码级的证据采集verification 模块verify 技能所要求的证据在 oh-my-claudecode 中由独立的验证模块提供统一实现。该模块被抽象为 ralph、ultrawork、autopilot 等工作流共享的单一事实来源见 src/features/verification/README.md 与 src/features/verification/types.ts。核心 API 与证据类型如下证据类型VerificationEvidenceType源码定义了七种证据类型见 src/features/verification/types.tsexport type VerificationEvidenceType | build_success // 构建成功 | test_pass // 测试通过 | lint_clean // 无 lint 错误 | functionality_verified // 功能已验证 | architect_approval // 架构师审批 | todo_complete // TODO 全部完成 | error_free; // 无未处理错误每条VerificationEvidence都记录了证据类型、是否通过、运行过的命令、命令输出、错误信息与采集时间戳timestamp: Date这正是只有带输出的命令结果才算证据的工程化体现。标准检查项STANDARD_CHECKS模块预定义了七项标准检查见 src/features/verification/index.ts对应文档中的验证顺序与证据类型检查项证据类型对应命令是否必需BUILDbuild_successnpm run buildTS 编译无错是TESTtest_passnpm test是LINTlint_cleannpm run lint是FUNCTIONALITYfunctionality_verified手动功能验证是ARCHITECTarchitect_approval架构师评审是TODOtodo_complete零 pending/in_progress 任务是ERROR_FREEerror_free零未处理错误是执行与裁决逻辑runVerification支持并行/串行、failFast、skipOptional、超时与自定义工作目录等选项见 src/features/verification/index.tsawait runVerification(checklist, { parallel: true, // 并行运行所有检查 failFast: false, // 失败后是否立即停止 skipOptional: false, // 是否跳过非必需检查 cwd: process.cwd(), // 工作目录 timeout: 60000 // 单检查超时默认 60 秒 });裁决由generateSummary给出若存在跳过项则 verdict 为incomplete在 strictMode 下任一失败即rejected全部必需项通过则为approved见 src/features/verification/index.ts。checkEvidence还会执行证据新鲜度校验超过 5 分钟的证据会被标记为 stale 并要求重新运行见 src/features/verification/index.ts——这与 Verifier Agent 对 stale evidence 的拒绝规则完全一致。无命令的手动检查项会被标记为requiresManualVerification: true、status: pending_manual_review不会自动通过从而避免门禁逻辑误放行见 src/features/verification/index.ts。报告可通过formatReport输出为markdown人类可读、json程序可读或text日志友好三种格式见 src/features/verification/index.ts分别对应 SKILL.md 输出契约在不同场景下的呈现。分层验证让验证强度随任务复杂度伸缩verify 技能强调用最窄的验证路径仓库为此提供了分层验证策略docs/shared/verification-tiers.md共三档Tier适用条件Agent / 模型所需证据LIGHT5 文件、100 行、测试全覆盖architect-low / haikulsp_diagnostics 干净STANDARD默认档非 LIGHT 亦非 THOROUGHarchitect-medium / sonnet诊断 构建通过THOROUGH20 文件 或 架构/安全变更architect / opus全面审查 全部测试选择逻辑是确定性的涉安全或架构变更 → THOROUGH文件数 20 → THOROUGH小改动且有全量测试 → LIGHT其余 → STANDARD。用户关键词可覆盖自动判断thorough/careful/important/critical强制 THOROUGHquick/simple/trivial/minor强制 LIGHT安全相关文件变更永远走 THOROUGH。架构变更通过**/config.{ts,js,json}、**/schema.{ts,prisma,sql}、**/types.ts、package.json等路径模式检测安全影响则通过**/auth/**、**/security/**、**/credentials?.{ts,js,json}、**/.env*等模式识别。该文档还给出了不同类型声明的证据要求对照表Fixed需要展示现在能通过的测试Implemented需要 lsp_diagnostics 干净 构建通过Refactored需要所有测试仍然通过Debugged需要以 file:line 定位根因。分层设计据其估算可节省约 40% 的验证成本相对于始终使用 THOROUGH。实战落地示例结合上述全部要素一次符合 verify 技能的验证流程可以这样组织1. 定义待证行为 - 行为修复了登录接口在空密码时的 500 错误 - 验收标准空密码请求返回 400 明确错误信息 2. 按优先级执行验证 - 已有测试npm test -- auth回归套件通过 - 类型检查lsp_diagnostics_directory → 0 errors - 构建npm run build → exit 0 - 窄命令针对修复的接口发起空密码请求观察响应 3. 缺口分析 - 标准1空密码→400VERIFIED测试 auth.test.ts 通过 - 标准2错误信息内容PARTIAL测试未校验信息文本 4. 输出契约 - 已验证内容 / 运行的命令 / 通过项 / 失败或未验证项 - VerdictREQUEST_CHANGES错误信息内容未覆盖若某一环节失败按规则必须原样呈现失败信息含命令与输出而不是掩盖若确实不存在自动化验证路径则明说该变更目前无自动化验证手段而非虚报已验证。结语verify 技能的本质是一套纪律先定义什么才算证明再按已有测试 → 类型检查/构建 → 窄命令 → 手动验证的优先级逐级收敛最后只报告带有命令与输出的实际证据。在 oh-my-claudecode 中这一纪律通过 agents/verifier.md 的 Agent 化、src/features/verification/index.ts 的模块化实现、docs/shared/verification-tiers.md 的分层策略以及 generated/prompt-ssot/role-verifier.md 的提示词固化得以系统性落地。对任何使用 Claude Code 或其派生工具的开发者而言将这套证据先行的验证流程引入自己的工作习惯都能显著降低声称完成、实则带病上线的风险。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考