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

verify-workflow-review

测试与质量

查看项目

更新于 10-16 10:04

技能介绍

用途

verify-workflow-review 是一个产物审查工作流技能，用于在软件、文档、文章、PPT（deck）或视觉稿完成后进行质量把关，也适用于即将合并或交付的变更。它的入口是已完成并准备进入 formal review 的产物，出口是 docs/features/<name>/04-review.md 审查报告。通过后指向 ship-workflow-ship；有问题则退回 build 修复后重审。前置加载 CANN.md。

何时不使用

  • 产物还处于私有草稿阶段，尚未准备进入 formal review。
  • 已有等价两阶段审查报告，且包含 Spec Compliance、质量评估和验证证据。

主要能力

两阶段审查

先读取 spec 的 artifact_type：

  • software（默认）→ 执行两阶段审查。
  • document / article → 加载 verify-content-review。
  • deck → 加载 verify-content-review，并默认检查是否需要叠加 verify-visual-review。
  • visual → 加载 verify-visual-review。

Stage 1 Spec Compliance：必须加载 verify-workflow-spec-compliance。检查 spec 每个需求是否实现、每个验收标准是否有对应证据、是否有 scope creep。所有 spec 需求有对应实现且无 Blocking 遗漏才通过；不通过则退回 build，不进入 Stage 2。

Stage 2 Artifact Quality：Stage 1 通过后执行。software 必须加载 verify-quality-code-quality，执行 Correctness / Readability / Architecture / Security / Performance 五轴审查；document / article 的 Stage 2 默认由独立的 agents/review-content-auditor.md 执行；deck 的 Stage 2 默认由独立的 agents/review-content-auditor.md 执行，涉及页面层级、信息密度、版式或投屏可读性时再追加独立的 agents/review-visual-auditor.md；visual 的 Stage 2 默认由独立的 agents/review-visual-auditor.md 执行。安全敏感追加 agents/review-security-auditor.md；测试覆盖不确定追加 agents/review-test-engineer.md；UI/a11y 风险追加 agents/review-accessibility-auditor.md。

独立性分档

/review 按独立性分为三档，阶段顺序不能被 persona 选择改变：

  • trivial exemption：仅限单文件、纯文案/格式/注释或机械性重命名、无 UI/安全/schema/public API 风险的微小变更；允许 current agent 完成两阶段，但必须在 04-review.md 记录 Exemption reason。
  • standard：Stage 1 可由 current agent 或 agents/review-spec-compliance-auditor.md 执行；Stage 2 必须由与 artifact_type 对应的独立 reviewer persona 执行（software → agents/review-code-quality-auditor.md）。
  • high-risk/full：Stage 1 必须由 agents/review-spec-compliance-auditor.md 执行；Stage 2 必须由与 artifact_type 对应的独立 reviewer persona 执行。

如果当前 session 在本 feature 的 /build 中承担过 implementer，则除 trivial exemption 外，不能同时完成 Stage 1 和 Stage 2。

意见分级

  • 无前缀：必须改，合并前必须处理。
  • Critical：阻塞合并，如安全漏洞、数据丢失、功能崩溃。
  • Nit：可选，风格偏好，可忽略。
  • Consider：建议，值得执行但不强制。
  • FYI：仅供参考，不需要操作。

验证验证者

检查提交者的验证证据：software 看跑了什么测试、构建是否通过、UI 变更是否截图、前后对比；非 software 看预览、导出的 final 文件、来源、引用、尺寸、层级或导出结果。

审查独立性记录

在 04-review.md 明确记录 Built by、Stage 1 reviewed by、Stage 2 reviewed by、Independence status、Exemption reason。判定规则：PASS 满足当前独立性档位要求；FAIL 标准或高风险变更未满足独立性要求；EXEMPT 命中 trivial exemption 且理由具体可审计。

文档合同兑现检查

如果 01-spec.md 的 Documentation Impact 声明 project_truth_changed: yes 或 doc_intent != feature_only，检查 03-plan.md 是否包含 Project Doc Sync Plan，检查受影响的项目级文档是否已更新或有明确 defer 理由，并在 04-review.md 写 Documentation Compliance。Required project docs updated: FAIL 时，整体 verdict 不能是 APPROVED。

使用方式

流程如下：

  1. 理解上下文：看产物前先理解意图，变更要达成什么、对应 spec/plan 的哪个部分、预期的行为或读者判断变化是什么。
  2. 先看主要验证证据：software 看测试是否揭示意图和覆盖、是否测行为而非实现细节、边界是否覆盖、代码改了测试能否捕获回归；非 software 看预览、导出结果、引用来源和前后对比。
  3. 两阶段审查：先读取 spec 的 artifact_type，再判定独立性档位，然后执行 Stage 1 与 Stage 2。
  4. 分类意见：按 Critical、无前缀、Nit、Consider、FYI 分级。
  5. 验证验证者：检查提交者的验证证据，并检查审查独立性。
  6. 检查文档合同兑现。

审查完成后，04-review.md 必须包含 Artifact Type、Review Scope、Review Independence、Stage 1: Spec Compliance、Stage 2: Artifact Quality、Evidence Reviewed、Findings Summary、Findings Detail、Documentation Compliance、Resolution & Re-review、Residual Risk、Verdict 等部分。模板起点为 templates/feature/04-review.md。

Verdict 决策为 APPROVED / APPROVED_WITH_CONCERNS / REJECTED，并记录 Blocking issues 数量、Important issues 数量、Merge / ship condition、Blockers remaining、Next command（/ship、/build 或 /review）。

适用场景

  • 软件变更合并前的正式审查。
  • 文档、文章、deck、视觉稿交付前的质量把关。
  • 高风险变更（敏感数据、认证授权、UI/a11y、公共 API、schema/migration、发布前审查或用户指定 --full）的并行发散审查。
  • 大 diff、测试日志、构建日志或 artifact 体量过大时的高噪音审查，分派 reviewer subagent 只读压缩。

限制

  • 产物还处于私有草稿阶段时不适用。
  • 已有等价两阶段审查报告时不适用。
  • 未被选中的 reviewer 不产出占位反馈；所有已选 reviewer 输出 Blocking / Important / Suggestion。
  • Reviewer persona 默认 read-only，输出必须压缩；禁止返回原始日志、完整 diff、大段代码、长篇推理或无关背景。
  • 大 diff、测试日志或专项风险会污染主 session 时，优先分派对应 reviewer subagent 做摘要；主 session 只合并结论、证据、文件行号、风险和下一步。
  • build 阶段产生的 pre-review / implementation gate 结果只能作为输入线索，不能替代本阶段正式 Stage 1 / Stage 2 证据。
  • 变更过大（>1000 行或内容/视觉产物体量无法单次审好）时要求拆分为多个 PR / 交付包。
  • 审查者与作者有分歧时，按技术事实 > 风格指南 > 设计原则 > 代码库一致性裁决；不接受“之后清理”，合入前要求清理，除非真正紧急。
  • 审查完成后实施反馈时参考 verify-workflow-receiving-review 技能。

红旗

产物未经审查就合入/交付；跳过 Spec Compliance 直接进入 Code Quality；功能不完整时进行质量审查；审查只检查测试是否通过或文件能打开；LGTM 而没有实际审查证据；安全敏感变更没有安全审查；PR 或交付包太大无法审好；Bug fix PR 没有回归测试；审查意见没有严重级别标签；接受“之后清理”；spec 说要同步 project docs 但 04-review.md 没有 Documentation Compliance；标准变更由 build implementer 独自完成 formal review 两阶段。