acceptance-check

验收检查

单元测试通过，只能证明有人编写的断言通过了，不能证明功能正常。两者之间的差距——API 返回 201，而客户端读取的是 200；复选框只在内存中切换，却没有写入存储；表单在提交失败后被清空——正是功能带着缺陷发布的地方。此技能旨在弥补这一差距：驱动正在运行的系统，而不是测试套件。

在 code-review 之后、finish-branch 之前运行。

1. 根据规格制定验收清单

阅读功能的 requirements.md、design.md 和 tasks.md。针对每项描述用户可观察行为的需求，列出具体检查项——包括正常路径和每项边界条件／错误标准——并标注对应的需求 ID。规格是依据：没有人特意告诉你的行为仍然需要验证；没有追踪到的行为是需要提出的缺口，不能跳过。

将清单写入 .skills/<slug>-acceptance.md（作为工作记录，不纳入 git），并为每项创建一个待办事项。阅读量太大？派遣扫描子 Agent 梳理受影响的范围，并将要点整理到工作记录中；保持当前上下文精简。完成标准：每个面向用户的需求 ID 至少有一项具体、可观察且包含预期结果的检查。

2. 按范围分派

清单按行为所在的位置拆分。根据实际情况执行相应项——大多数功能两项都需要：

• 变更暴露了客户端调用的 HTTP/RPC API → 必需子技能：使用 acceptance-api。
• 变更包含用户操作的前端 → 必需子技能：使用 acceptance-ui。
• 行为既不是 API，也不是 UI（例如 CLI、库、批处理／cron 作业）→ 亲自针对正在运行的系统直接验证，将每项观察结果记录到工作记录中，并将通过的检查纳入已提交、带 ID 标记的测试中。对于需要人工观察的特性（视觉效果、手感），交由 dogfood 处理。

按路径将清单中相应的部分交给每个子任务；它们会将结果写回同一个文件。

3. 闭环

报告清单及每项观察结果。任何无法验证的项目都是尚未解决的风险——明确指出，不要悄然放行。然后交回给 finish-branch。完成标准：清单中的每项都已在运行中的系统上观察到通过；每项失败都已修复并补充回归测试；持久化测试已提交并标记，以便 finish-branch 的验证门禁持续强制执行。