acceptance-criteria-review

验收标准评审（中文版）

何时使用

• 需要把需求与用户故事转成可验证、无歧义且覆盖异常路径的验收标准。
• 需要对现有方案、结果或证据做风险评审，并形成可执行改进项。
• 输入不完整，但仍需先给出带假设和信息缺口的可用初版。

输出格式选项

• 默认输出 Markdown，适合评审、执行和持续补充。
• 用户要求表格、CSV、JSON 或工单格式时，保留同样的风险、证据、优先级和边界字段。
• 若输出会进入自动化流程，先确认字段 schema、枚举值和必填项。

如何使用

1. 先阅读并遵循 prompts/acceptance-criteria-review.md 的输入、执行规则、最低覆盖清单和输出顺序。
2. 补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
3. 先做输入审计，再区分已确认事实、合理假设和待确认问题。
4. 按风险和证据强度排序，产出可直接执行、评审或验证的结果。
5. 信息不足时不要停在提问：先交付受限初版，并说明哪些结论暂不能成立。

参考文件

• 校准领域结果、正确对照或证据缺口时，读取 references/domain-decision-example.md 的脱敏输入、逐项预期与复算依据。

• 每次执行必须读取 prompts/acceptance-criteria-review.md；它是本 Skill 的完整执行规范。

• 需要评测或回归本 Skill 时，读取 evals/eval.yaml 与匹配的 evals/cases/ 用例。

• 只有目录实际存在且任务需要时，才读取 references/、examples/、scripts/ 或 output-formats.md，不要假设不存在的资产。

领域执行要点

1. 先选择 review（核对原标准）、proposed-rewrite（建议改写）或 missing-rule（规则缺失）；保留原 AC ID、版本、原文和来源，不把建议覆盖成原规则。
2. 逐条输出：AC ID | 原标准 | 模式 | 可观察预期 | 建议文本 | 差异原因 | 待产品确认。无规则的格子保持待确认。
3. 对比较符按原文拆出小于、等于、大于三个输入；对重复请求记录业务键、累计退款、剩余可退额和最终状态。响应成功不等于账务正确。
4. 建议改写应包含 Given/When/Then、可观察数据与错误路径；确认充分的原标准标为可测试，不为凑问题制造歧义。

核心约束

• 不要替产品方决定缺失的业务规则
• 每条标准写成可观察结果
• 把阻塞开发或测试的歧义单独升级
• 不编造输入中不存在的系统行为、字段、数据、指标或根因。
• 关键结论必须关联证据；证据不足时标记为假设并给出验证方法。
• 优先级必须说明业务影响、发生可能性或可探测性依据。

交付前自检

• 已覆盖：可测试性与可观测结果、正常、异常和边界路径、角色权限、数据规则、状态迁移、依赖与失败处理、非功能约束、需求歧义。
• 已区分事实、假设、缺口和建议。
• 高风险项有明确优先级、证据、负责人或下一步。
• 输出包含可验证的判断标准，而非泛泛而谈。
• 未执行未经授权的生产写操作或破坏性动作。

常见误区

• 只列检查点，不说明输入条件、预期结果或证据。
• 把所有事项都标为高优先级，失去取舍价值。
• 用工具名或通用理论替代领域判断。
• 输入不完整时直接拒绝，或反过来假装结论已经确定。

最佳实践

• 从最可能造成业务损失、安全问题或发布阻塞的路径开始。
• 用最小可验证实验缩小不确定性，并记录复现条件。
• 让输出能够被另一位工程师直接执行和复核。