Skill 组合与编排
code-review 发现了一个严重的安全漏洞，你脑子里冒出一个想法：让它顺手修了吧。
忍住。
审查和修复是两件事。把修复逻辑塞进 code-review，它的 SKILL.md 会膨胀，上下文被修复逻辑占用，审查质量反而下降。而且”发现问题”和”修复问题”需要完全不同的思维模式——审查要求怀疑一切、吹毛求疵；修复要求理解意图、权衡取舍。
正确做法：code-review 发现问题，交给 fix-issue 处理。两个 Skill 各司其职。
四种组合模式
顺序链：A 完成后 B 接手
最直接的组合。code-review 输出审查报告，fix-issue 读取报告中的 Critical 问题逐个修复。
两个 Skill 之间怎么传数据？通过文件系统。code-review 把结果写到 .code-review/report.md，fix-issue 读这个文件。或者更简单——code-review 的输出本身就在对话上下文里，用户接着说”修一下那个 SQL 注入”，fix-issue 自然能看到之前的审查结论。
不需要设计 API 契约、不需要定义数据格式。文件或对话文本就是接口。
并行扇出：同一输入交给多个 Skill
一个 PR 同时需要安全审查、性能审查、风格审查。串行跑三遍太慢，用上一章的子代理并行执行。
总时间取决于最慢的那个，而不是三个之和。一个 3 分钟的审查变成 1 分钟。
实现方式：在主 Skill 中按维度启动子代理，每个子代理加载不同的 references（安全规则、性能规则、风格规则），审查同一份 diff。
条件路由：根据结果走不同分支
## 后续动作
- 如果审查评分 < 6 分，启动 deep-analyzer 做根因分析
- 如果评分 6-7 分，列出问题清单等待开发者处理
- 如果评分 >= 8 分，输出"审查通过，可以合并"这种条件逻辑直接写在 SKILL.md 里就行。AI 看到评分和条件，自然知道走哪条路。不需要写 if-else 代码，自然语言本身就是控制流。
知识叠加：多个 Skill 同时生效
你有一个 api-conventions Skill 定义了 REST API 的命名规范，还有一个 team-standards Skill 定义了团队的通用编码标准。当用户说”review 这个 API”，两个 Skill 的 description 都能匹配，它们的内容会同时加载到上下文中。
这是自动发生的，你不需要手动编排。只要 description 写得准确，匹配上了就会加载。
但要注意：两个同时生效的 Skill 不能有矛盾的指令。如果 api-conventions 说”用 snake_case”，team-standards 说”用 camelCase”，AI 会懵，输出不可预测。
Skill 间的数据传递
三种方式，从简单到复杂：
对话上下文——A 的输出就在对话里，用户触发 B 时 B 自然能看到。零配置，适合顺序交互。
文件系统——A 写文件，B 读文件。适合数据量大或需要结构化传递的场景。约定好文件路径就行。
$ARGUMENTS 传参——主 Skill 调用子代理时把信息塞进参数。适合子代理场景。
不要过度设计。Skill 之间不需要 gRPC 接口、不需要消息队列。你在编排的是 AI 助手，不是微服务。
实战：code-review + explain-code 联动
code-review 发现了一个 Critical 问题：一个函数在并发场景下有竞态条件。开发者看了报告，可能知道这是个问题，但不理解为什么——竞态条件本来就是最反直觉的 bug 类型。
在 code-review 的 SKILL.md 中加一段：
## 复杂问题解释
如果发现 Critical 问题且涉及并发、状态管理、数据一致性等复杂逻辑：
不要只说"这里有竞态条件"。用 explain-code 的方式展开：
1. 用时间线描述两个并发请求交错执行时会发生什么
2. 指出具体哪一行在哪个时刻被哪个请求执行
3. 说明最终结果为什么和预期不同
目的：让开发者不只知道"这有问题"，还理解"为什么是问题"。注意这里不是调用另一个 Skill，而是借用了 explain-code 的方法论（时间线、逐步推演）。Skill 的”组合”不一定是技术层面的调用链，也可以是方法论层面的交叉引用。
什么时候不该组合
组合不是越多越好。三个信号告诉你该收手：
两个 Skill 总是一起用——如果 A 和 B 从来没被单独触发过，它们大概率应该合并。拆得太细只会增加维护成本。
组合增加了复杂度但没增加价值——你花了两个小时设计 A 和 B 的数据传递协议，但用户体感没有任何改善。保持简单。
数据传递太复杂——如果 A 需要把 10 个字段传给 B，B 还需要把 3 个字段传回 A，再由 A 决定下一步——这不是两个 Skill，这是一个 Skill 被错误地拆成了两个。
最终判断标准：用户说一句话能不能把事办了？如果用户需要手动串联多个 Skill（“先跑 review，再把结果复制给 fix，再跑 test”），那你的编排设计有问题。好的组合对用户是透明的。