上一篇把 GitHub Skill 整理成了前端任务地图。按任务类型选工具，能解决起步问题。
但真实写代码时，还会碰到另一个麻烦。一个任务可能同时命中两三个 Skill。比如新增批量操作区，TDD 说先写测试，设计类 Skill 关心焦点和响应式，webapp-testing 要走浏览器路径。它们单独看都合理，放到一个已有项目里，就会互相抢位置。
我不会让 Codex 自己临场决定听谁的。AI 很容易选择最方便生成代码的那条规则。对前端工程来说，方便生成和适合合并经常是两回事。
所以多 Skill 同时出现时，我会先定优先级。
第一层永远是当前项目
排在最前面的，是当前项目已经存在的东西。
目录结构、组件写法、请求封装、状态命名、样式体系、测试入口、构建命令，这些都比外部 Skill 更靠前。GitHub Skill 再好，也不能直接压过项目里的代码。
举个很直接的例子。web-artifacts-builder 适合 React、Vite、Tailwind、shadcn/ui 的独立产物。可如果当前仓库是 Vue3 后台管理项目，它的骨架规则就不能采用。能借的只是先确认技术栈、先建立可运行页面、交付前打包这类流程。
我会让 Codex 把这类冲突写明。
当前项目优先规则
- 沿用已有技术栈和目录结构
- 沿用已有组件和请求入口
- 沿用已有样式体系
- 沿用已有测试与构建方式
- 外部 Skill 示例不得直接覆盖项目约定这五条写在前面，后面的规则才不会失控。
第二层是本次需求
项目规则之后，才轮到本次需求。
用户要求新增一个筛选项，就不要顺手重构整张列表。用户要求修一个分页错位，就不要把表格列、搜索条件、接口封装一起改掉。需求范围小，Skill 的使用范围也要小。
这里我会要求 Codex 说清两个东西。
本次任务范围
- 必须修改的文件和原因
- 不应触碰的文件和原因很多多 Skill 失控，都发生在"不应触碰"没有写出来。TDD 让 Codex 增加测试，调试 Skill 让它查根因，浏览器测试让它补路径。每个动作都会打开新的文件。没有边界，任务会越走越大。
把范围框住以后，Skill 只能服务当前需求，不能借题发挥。
第三层才是选中的 GitHub Skill
到了这一层，才开始处理外部 Skill 的规则。
我会给 Codex 一个明确顺序。
| 优先级 | 规则来源 | 处理方式 |
|---|---|---|
| 1 | 当前项目代码和项目规则 | 必须遵守 |
| 2 | 本次需求和验收标准 | 必须对齐 |
| 3 | 已选 GitHub Skill 的流程规则 | 有冲突时降级 |
| 4 | Skill 里的示例代码 | 只作参考 |
| 5 | Codex 的通用建议 | 需要证据后再采用 |
这张表看起来普通，用起来很管事。
test-driven-development 的铁律很强，适合有测试入口、有可拆逻辑的任务。可如果当前项目没有测试环境，Codex 不能为了遵守 TDD 临时引入一整套测试栈。此时我会把它降级成行为样例，先写输入输出和边界条件。
webapp-testing 也一样。它鼓励用浏览器路径验收页面。可如果页面依赖登录态、内网接口或临时账号，自动化脚本拿不到环境，就先输出手动路径和未覆盖项。不能为了跑脚本去改业务代码。
好规则要服从现场条件。否则它会从帮助变成负担。
冲突表要在改代码前交
我会让 Codex 在正式修改前交一张冲突表。
请先输出 GitHub Skill 冲突表。
每一行包含
- 冲突规则
- 来自哪个 Skill
- 和当前项目或本次需求冲突在哪里
- 采用、降级或排除
- 需要我确认的点
冲突表确认后，再进入代码修改。这张表能提前暴露很多问题。
比如外部 Skill 建议换 UI 组件库，当前项目已经有统一组件。处理方式就是排除。比如 TDD 要求先写失败测试，当前项目有测试入口但没有覆盖这个模块。处理方式可以是采用，先补一个小测试。比如浏览器测试需要登录账号，当前没有账号。处理方式就是降级，先给手动验收路径。
冲突被写出来，人的判断才进得去。
我会重点看四类风险
第一类是技术栈漂移。外部 Skill 示例来自 React，当前任务在 Vue。Codex 如果开始新增 React 依赖，任务已经偏了。
第二类是范围外修改。为了让测试好写，顺手重构状态结构。为了让页面好看，顺手改公共样式。为了让浏览器脚本稳定，顺手加测试专用字段。这些都要提前拦住。
第三类是证据缺失。Codex 说已经按某个 Skill 处理，但没有测试结果、代码位置、页面路径或未覆盖说明，这条规则就不能算采用。
第四类是长期规则污染。一次任务里临时有效的处理方式，不能马上写进项目规范。它要先经过规则复盘，看下一次同类任务是否仍然成立。
这四类风险，比"有没有使用某个 Skill"更重要。
交给 Codex 的完整优先级任务卡
本次前端任务可能同时涉及多个 GitHub Skill。
请按以下优先级处理
1. 当前项目代码和项目规则
2. 本次需求和验收标准
3. 已选 GitHub Skill 的流程规则
4. Skill 示例代码
5. Codex 通用建议
请先输出
- 本次主 Skill 和后备 Skill
- 可能冲突的规则
- 每条冲突的采用、降级或排除结论
- 修改范围和禁止触碰范围
- 交付时对应的证据
确认前不要修改代码。这份卡片的重点是把"听谁的"说在前面。多 Skill 协作里，规则本身并不难，难的是它们进入同一个项目后的顺序。
写在最后
多个 GitHub Skill 同时出现时，我会让 Codex 先定优先级。
当前项目排第一，本次需求排第二，外部 Skill 排第三。示例代码只能参考，通用建议要拿证据说话。这个顺序固定下来以后，Codex 才不会把一个小前端任务写成一次大改造。
下一篇我准备把这两篇的地图和优先级继续压缩，做成一份可以反复贴给 Codex 的前端任务启动模板。模板不求花哨，只要能让任务在动代码前选对工具、框住范围、交出证据。
本系列持续更新，继续把 Codex 和 GitHub Skills 放回前端工程的真实场景里。