技能协同 — 仲裁规则 是做什么的？
当多个技能被触发时，决定哪个技能获胜的唯一权威。当两个或更多技能看起来都适用于当前任务时，请阅读此规则。
使用说明：本技能是详细的规则集。一份简洁的章程（建议用于始终开启的设置）位于仓库根目录的
AGENTS.md.template中；将其复制到AGENTS.md中，以便核心规则在每个会话中加载。本技能是按需参考的详细规则。
核心规则
工作流技能（做什么）在相同任务上的优先级高于模式技能（如何说/写）。模式技能应适应；工作流技能绝不被削弱。
以下所有内容都是此规则的应用。如果未列出特定情况，请应用核心规则并说明。
工作流 vs 工作流仲裁
两个或更多工作流技能都可能匹配同一任务。按以下层级顺序选择：
- 显式意图优先。 如果用户命名了任务类型（review, test, design, plan...），则该类型的技能主导。无需斟酌。
- 范围决定。 单次更改（一个差异、一个函数、一个文件）采用较简单、成本较低的技能；跨领域更改（架构、多文件重构、新系统）采用较深入、成本更高的技能。
- 生命周期顺序。 规划 → 构建 → 验证是默认顺序。当技能是同一工作的不同阶段（如设计、然后实现、然后审查）时，按此顺序运行它们，而不是选择其中一个。
- 组合优于选择。 如果两个技能是顺序阶段，则按顺序运行两者，并明确说明顺序（例如“先TDD，然后审查”）。
- 仍然模棱两可？询问。 给出一行推荐，让用户选择。永远不要静默地选择工作流技能——错误的技能会浪费整个任务，而不是一次回复。
技能分类
在仲裁之前，对每个已安装的技能进行分类：
- 工作流技能 — 规定做什么：review, test, design, research, writing, refactoring, planning。它们产出交付物。
- 模式技能 — 规定代理听起来如何或写多少：compression, verbosity, style, brevity。它们自身不产出任何东西。
- 路由技能 — 选择运行哪个工作流（可选）。它们绝不应被模式技能覆盖。
如果模式技能会改变工作流技能的交付物（报告、文档、提交消息、PR正文），则模式技能让路。如果工作流技能和模式技能同时触发，并且工作流技能的输出是交付物，则模式技能让路。
本章程优先级高于技能自述。 技能的元数据可能声称在宽泛短语上自动触发（例如“auto-triggers on review”）。此类声明在此被取代：路由遵循本章程的消歧规则，而不是技能自身的触发声明。如果一个技能声称的触发器被本章程分配给了其他地方，则本章程胜出。
优先级矩阵（填入你自己的技能）
用你环境中实际安装的技能名称替换下面优先级矩阵中的示例技能名称。行的排列顺序依据实践中冲突出现的频率。
| 任务 | 主导（工作流） | 让路 | 行为 |
|---|---|---|---|
| UI设计 / 打磨 / 视觉批评 | 例如你的设计技能 | 例如你的最小代码技能 | 设计主导；最小代码降低强度（不要膨胀，但不要用YAGNI否决设计工艺） |
| 深度代码审查（标准+规范） | 例如你的完整审查技能 | 例如你的压缩技能 | 以正常行文提供完整报告；除非用户要求简洁反馈，否则关闭压缩 |
| 过度工程审计 | 例如你的删除聚焦审查 | 例如你的完整审查技能 | 单轴线、聚焦删除的执行；跳过完整报告 |
| 快速简洁的PR反馈 | 例如你的简洁评论技能 | — | 仅在用户明确要求压缩评论时 |
| 对计划/想法进行压力测试 | 例如你的面试/拷问技能 | 例如你的压缩技能 | 以正常行文进行面试；压缩后的拷问会失去深度 |
| 测试先行的功能构建 | 例如你的TDD技能 + 你的最小代码技能 | — | 组合：测试是验证，绝不削减；通过红-绿测试的最小实现 |
| 模块/API设计 | 例如你的设计文档技能 | 例如你的最小代码技能 | 设计阶段：深度优先。实现阶段：适用最小代码层级。 |
| 写作/编辑/教学 | 例如你的写作技能 | 例如你的压缩技能 | 需要完整表达；关闭压缩 |
| 研究/文档捕获 | 例如你的研究技能 | 例如你的压缩技能 | 输出文件是交付物；压缩仅影响聊天，绝不影响文件内容 |
| 任何编码任务，无其他技能触发 | 例如你的最小代码技能 | 例如你的压缩技能 | 最小代码全强度运行；压缩按需启用（其每次执行的输入成本通常超过在代码密集型工作上的节省） |
触发词消歧
当多个技能共享一个触发词时，根据意图路由，而不是根据哪个技能先匹配：
- "review this" → 默认进行完整审查。只有当用户说“over-engineered”/“too much code”时，才使用删除聚焦审查。只有当用户要求压缩反馈时，才使用简洁评论审查。
- "grill" / "interview me" → 当存在代码库时使用有状态变体（留下文档痕迹）；独立运行时使用无状态变体；当用户希望一次性提出所有问题时使用批处理变体。
- "handoff" → 默认使用文档编写变体；仅当用户希望立即产生后台代理时，才使用生成后台代理变体。
- "make a plan/spec/tickets" → 根据工件类型路由：spec, tickets, PRD, issues, questionnaire。
模式技能纪律
- 模式技能从不压制工作流技能的交付物。 它只能压缩聊天行文。由工作流技能编写的报告、文件、提交消息和PR正文保持完整。
- 最小代码技能的验证线有三个层级： (1) 真正的验证保留：输入验证、外部依赖的错误处理、安全性、可访问性——绝不削减。 (2) 推测性防御在范围内：不可能触发的检查、针对“万一”的防御性包装——削减它们，这是最小代码技能的工作。 (3) 测试和任务文档遵循用户的明确要求：最小代码技能绝不用YAGNI来削减用户要求的测试或文档——但测试中的冗余、过度模拟以及文档中的冗余仍然是可以削减的。
- 两个模式技能同时触发（压缩 + 最小代码）：最小代码管理代码，压缩管理聊天——但仅当会话以散文为主时；在代码密集型会话中，压缩应关闭或降低强度（否则净token损失）。
- 子代理继承仲裁规则。 当派生一个子代理进行审查或研究任务时，在任务中明确说明模式：“normal prose”或“compressed output”。绝不留作隐式。
能产生价值的组合
- TDD技能 + 最小代码技能 — 测试先行，最小实现。
- 完整审查，然后对同一差异进行删除聚焦审查 — 先完整扫描，然后进行删除扫描。
- 面试技能 + 记忆压缩技能 — 在面试后压缩积累的会话笔记。
- 在任何工作流技能完成之后使用简洁提交消息技能 — 始终安全。
- 路由技能用于流程路由，本技能用于模式仲裁 — 路由选择道路，协同选择档位。
定制化
本技能是一个框架，而非配置。要使其为你所用：
- 将优先级矩阵中的每个“例如你的X技能”替换为你环境中真实的技能名称。一个使用常见公共技能的填写示例位于
examples/example-config.md中 —— 复制它并替换为你自己的名称，而不是从头开始填写模板。 - 删除你从未遇到过的任务类型的行。
- 如果你的环境有全局规则文件（AGENTS.md 或等价文件），将核心规则复制到其中，以便每个环境都加载它。
- 如果出现新的未被覆盖的冲突，对两个技能进行分类（工作流或模式），应用核心规则，并添加一行。