如果只能安装 5 个 Agent Skills：一套精简开发组合

第一个角色不是执行，而是找到范围更窄的候选。find-skills 可以帮助搜索生态，但搜索结果只是候选；仍需打开来源、比较权限，不能因为出现在结果中就直接安装。

组合稳定后，它的使用频率可能降低。这没有问题：它的价值是避免第一次选择过于草率，而不是参与每次执行。

修改代码前，create-implementation-plan 把仓库上下文整理成文件、依赖、检查与待确认问题的书面顺序。计划可以在扩大写入权限前先被审查。

计划不能证明架构一定正确。它的验收标准是：另一位开发者无需猜测，就能识别目标变更、潜在影响范围和首个验证步骤。

skill-creator 值得占一个位置，是因为好的项目或团队 Skill 能减少重复提示，并保留检查、引用与边界。应在流程已经手动跑通后再固化，而不是在尚未理解流程时提前生成。

生成的 Skill 仍需触发测试、反例、最小引用和脚本审查。产物是可维护的指令包，不是自动质量或安全认证。

differential-review 为组合增加以变更为中心的审查角色，适合回答当前差异修改了什么、触及哪些敏感路径、影响范围可能扩展到哪里。相比泛泛要求找出所有问题，它的范围更窄、更容易审计。

它不能替代仓库知识、静态分析或最终批准。如果项目确实需要规则或数据流扫描，可在团队能够分诊结果时用 Semgrep 或 CodeQL 替换或补充该角色。

webapp-testing 用针对具体本地流程的可观察浏览器证据补完整个闭环。运行前明确路由、状态、预期结果和失败条件，并保留可由审查者重复的步骤与产物。

如果产品不是 Web 应用，就应替换第五个角色。CLI 项目可能更需要 TDD 或复现工具；文档流程需要转换与核对；数据管道需要查询与成本检查。应保留的是证据角色，不是某个名称。

不要第一天就装完五个。先安装解决当前瓶颈的 Skill，运行一次小型受控任务，并记录它读取、修改、执行和产出了什么；首个产物通过验收后，才增加下一角色。

只有当 Skill 拥有独立职责、来源可重新打开、产物确实会被检查、失败条件也能理解时才保留。如果两个 Skills 负责同一个决策，应先移除一个，再考虑第六个。

• 每个 Skill 只负责一个角色和一种可检查产物。
• 默认使用项目范围；个人范围必须有明确的跨项目理由。
• 首轮测试不需要的凭据或写入权限一律不授予。
• 来源提交和安装路径都能被重新构建。
• 批准、部署和破坏性操作仍由明确的人负责。