用途：将模糊的成果语言转化为可度量、可验证的 Definition of Done（DoD）标准。每条标准必须是二元的：PROVEN 或未证明，不存在“基本完成”。
适用时机：用户询问某功能或项目的“完成”含义；已产出成果翻译并需要正式标准；里程碑开始前需要明确验收标准；完成声明需要对照约定标准验证。不适用于已有明确验收标准的书面规格任务，以及验证方式显而易见的简单缺陷修复（如“修复 500 错误”）。
输入：成果短语或目标描述；可选当前系统状态（已证明内容）；可选范围约束（如“支付暂不在范围内”）。
流程：第一步，将目标映射到生产类别：Frontend、Backend、Data/Security、Payments、Integrations、Deployment、Business、Visual。第二步，按类别生成二元标准，格式为“□ [动词] [可度量条件] — Proof: [确切产物]”，例如“□ 生产 URL 返回 HTTP 200 — Proof: curl -I 输出”。拒绝不可度量、无证明或非二元的表述。第三步，为每条标准分配状态：PROVEN（证据存在且已验证）、UNKNOWN（尚未验证，声明完成前必须验证）、MISSING（确认缺失或损坏，声明完成前必须修复）。第四步，为每条 UNKNOWN 指定验证动作，如“UNKNOWN — requires: curl -I https://production-url.com”。
输出格式：按类别列出标准及状态与证明/验证/修复要求，并给出 PROVEN、UNKNOWN、MISSING 数量汇总，最后注明 GATE：所有标准必须为 PROVEN 才能声明完成。
验证门：输出前检查每条标准是否二元、每个 UNKNOWN 是否有具体验证动作、每个 MISSING 是否有具体修复、证明产物是否确切（不是“运行测试”，而是“运行 pnpm test 并捕获输出”）。
失败模式与恢复：目标过于模糊无法分类时，询问“对用户而言成功是什么样”；标准主观时改写为二元可观察结果；证明产物模糊时指定确切命令、文件路径或截图要求；标准超过 30 条时拆分为第一阶段（关键）与第二阶段（可选）。
限制：资料未提供该技能的安装方式、收费、价格、平台或效果信息。