开发任务该选哪些 Agent Skill：从需求到验收的工作流

选择 Skill 之前，先明确这次要完成什么。对开发者来说，“完成一个设置表单，并检查保存行为”比“装齐所有热门技能”更容易得到可判断的结果。技能数量不能替代清楚的任务边界。

先写清楚完成标准

把输入、输出和检查方法写在一起。例如：输入是现有项目和一份通知设置需求；输出是可以保存偏好的表单；检查包括键盘操作、窄屏布局、无效输入提示，以及项目已有的相关测试。截图可以支持视觉检查，但不能证明数据已经保存。

完成标准越具体，越容易判断缺的是实现能力、环境配置，还是验收证据。不要等到页面看起来完成之后，才发现从来没有约定保存失败该如何处理。

Agent Skills 格式以 SKILL.md 描述任务步骤，也可能附带脚本和参考资料。具体客户端决定如何发现、加载和使用这些内容。目录格式相同，不代表每个客户端都有相同工具和权限。

可以先看 Agent 入门组合，对照每个技能负责的任务。前端技能帮助组织界面实现，测试技能帮助设计检查。进入详情后，继续核对原始来源、固定版本、许可和运行前提。只选择覆盖本次任务所需的最小组合；出现具体缺口时再增加。

下面是说明性示例，不是一次已经执行的测试记录：

在现有应用里增加通知偏好表单。
先检查项目约定，说明准备改哪些地方。
读取所选前端技能的前提后，再决定如何使用。
检查键盘操作、无效输入提示和 390px 窄屏。
运行项目已有的相关检查，记录命令与实际结果。
把观察结果、推测和没有测试的部分分开写清楚。

不要直接把其他仓库的测试命令当成本项目的验收方法。如果技能需要浏览器、插件或远程账号，先单独完成对应配置；复制技能文件本身不会连接这些服务。

把需求、版本和结果保存在一起。某套项目约定反复解释多次后，再把它整理为团队 Skill。具体安装位置以当前客户端官方文档为准；SKILLPI 专题提供组合建议，不会替你安装或运行软件。

产品发布专题把实现和发布判断串在一起。发布证据指南进一步说明：本地检查通过和线上发布验收通过，分别需要什么证据。