validate-feature

验证功能

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

在 inspect-change 之后、land-branch 之前运行此技能。

冷启动控制。 如果 docs/agents/verify.md 存在，请在执行任何检查项之前，按照该文件启动并运行 Doctor（该文件规定后续 Agent 如何启动此应用）。如果某个检查项有匹配的 Feature 部分，则使用该部分进行验证；证据必须包含该文件指定的持久化／重新加载检查。如果该文件不存在，则像现在一样，根据 project.md 中的 Run locally (dev) 继续操作，并提及一次 /configure-repo，让用户能够生成该操作指南（决策 M）——不要调用它。

1. 根据规范制定验收检查清单

阅读该功能的 requirements.md、design.md 和 tasks.md。对于每项描述用户可观察行为的需求，列出具体检查——包括正常路径以及每一项边界／错误标准——并按需求 ID 标记。规范是事实来源：没人特别告诉你的行为仍然需要验证；没有追踪到的行为是需要提出的问题，而不是可以跳过的内容。

将检查清单写入 .skills/<CODE>/acceptance.md（用作工作记录，已在 git 中忽略），并为每个检查项创建一条待办事项。内容较多？可以派遣扫描子 Agent 梳理受影响的部分，并将摘要整理到记录中；保持此上下文精简。完成条件：每个面向用户的需求 ID 至少有一项具体、可观察且注明预期结果的检查。

产品背景文档（可选）

适用范围： 验收标准涉及用户画像或可衡量的成功指标。
加载： skills/project/define-system-doc/consult-recipe.md。
路径： docs/product/personas.md、metrics.md、principles.md。

获批时： 将相关约束纳入检查清单预期（仅供参考；需求仍具规范效力）。不存在时： 继续；只有在缺少这些内容会实质性影响验收清晰度时，才建议一次调用 /define-system-doc product/personas|metrics|principles；切勿自动调用。

2. 按界面类型分派

根据各项行为所属的位置，将检查清单拆分执行。运行适用的验证方式——大多数功能两者都需要：

• 此变更公开了客户端会调用的 HTTP/RPC API → 必需子技能：使用 validate-api。
• 此变更包含用户操作的前端 → 必需子技能：使用 validate-ui。该操作使用 kimi-webbridge。 它不会安装浏览器测试工具。
• 此行为既不是 API，也不是 UI（例如 CLI、库、批处理／cron 作业）→ 自行直接对正在运行的系统进行验证，将观察到的每项结果记录在检查清单中，并将通过的检查提升为已提交的测试，以描述领域行为（仅文档主干——测试文件中无需添加需求 ID 标签）。对于需要人工观察的质量（视觉效果、使用感受），交由 write-dogfood 处理。

按路径将检查清单中各自的部分交给每个子 Agent；由其将结果写回同一文件。

3. 完成闭环

汇报检查清单以及每项检查的观察结果。任何未能验证的检查项都是尚未解决的风险——请明确指出；不要让它悄然通过。然后交回给 land-branch。UI 验收证据是通过 webbridge 操作生成的 .skills/<CODE>/validate-ui.md。产品缺陷仍需使用仓库现有的测试技术栈编写回归测试。完成条件：针对正在运行的系统观察到所有检查项均通过，每个失败项都已修复并在现有测试技术栈中添加回归测试，并且 UI 操作记录已保存到磁盘。