前面几篇把 GitHub Skill 逐个拆开讲了一轮。写页面可以看 web-artifacts-builder，写逻辑可以借 TDD，修 bug 可以走 systematic-debugging，交付前可以用 webapp-testing 去点页面。
问题也随之来了。
一个前端任务摆在面前，Codex 到底该先用哪个？如果每次都把所有 Skill 全塞进去，看起来材料很足，实际会让任务变慢。它要先处理一堆外部规则，再回到当前项目。对于已有 Vue 页面、后台列表、弹窗表单这种高频任务，外部规则用错了，干扰比帮助更明显。
所以我现在会先画一张地图。地图不追求覆盖所有 GitHub Skill，只处理当前专栏已经核过的几类前端编码场景。
先问任务要交什么证据
我不会先问"这个 Skill 强不强"。我会先问当前任务最后要交什么证据。
独立页面任务通常要交页面骨架、依赖清单和首屏效果。此时 web-artifacts-builder 有价值，它本来就围绕 React、Vite、Tailwind、shadcn/ui 这类独立前端产物展开。
稳定逻辑任务更看重测试证据。比如状态转换、字段格式化、按钮禁用、参数组装。这里更适合 test-driven-development，让 Codex 先写失败测试，再写最小代码。
报错或异常行为摆在前面时，证据应该是根因。此时不要急着让 Codex 改文件，先让 systematic-debugging 接管调查顺序，记录复现、假设和验证结果。
代码已经改完，证据应该回到页面。webapp-testing 负责把用户路径走一遍，至少覆盖打开、输入、点击、状态变化和结果展示。
任务结束后准备沉淀规则，证据就换成规则去处。采用了什么，排除了什么，和项目哪里冲突，哪些可以留到长期规范，哪些只留在本次记录。
这个顺序能帮我挡住一个常见误用。Skill 要跟着证据走，少跟着工具数量走。
我会按这张表做第一轮选择
| 前端任务信号 | 优先考虑的 GitHub Skill | 让 Codex 先交什么 |
|---|---|---|
| 从零做独立页面或演示页 | web-artifacts-builder |
技术栈适配说明和页面骨架 |
| 写纯逻辑或状态规则 | test-driven-development |
失败测试和最小用例 |
| 已有报错、异常行为、复现路径 | systematic-debugging |
根因调查记录 |
| 页面已经改完，准备验收 | webapp-testing |
浏览器路径和未覆盖项 |
| 任务准备收尾 | 规则复盘模板 | 采用、排除、冲突和证据 |
这张表还有一列我会在心里补上，叫作"不采用理由"。
已有 Vue 项目不需要 React 骨架，web-artifacts-builder 就先放下。没有明确 bug，systematic-debugging 就先放下。没有测试环境，TDD 不能硬写一套跑不起来的测试，只能先把行为样例列出来，等项目确认测试入口以后再接。
把不采用理由写清楚，Codex 才不会在后面偷偷把外部示例带进项目。
一次任务最多先选两个
我给自己的限制很简单。普通前端任务启动时，先选一个主 Skill，一个后备 Skill。
比如新增一个后台列表操作区，主 Skill 可以选 TDD，先管选择状态和参数组装。后备 Skill 可以选 webapp-testing，等页面改完再验收。web-artifacts-builder 和 systematic-debugging 暂时不进入任务。
如果是修一个列表分页错位的问题，主 Skill 就换成 systematic-debugging。先查请求参数、响应数据和状态提交。TDD 可以当后备，等根因明确后，为分页状态补一两个小测试。
如果是做一个独立的活动页原型，主 Skill 才轮到 web-artifacts-builder。这时还要让 Codex 先确认项目是否允许 React、Vite、Tailwind 和 shadcn/ui。只要当前仓库已经固定了别的技术栈，它就只能借流程，不能搬骨架。
前端任务最怕一开始就变成"工具大会"。选两个，Codex 的注意力会集中很多。
我会这样让 Codex 先选
请先判断本次前端任务属于哪一类。
可选类型
- 独立页面生成
- 纯逻辑开发
- bug 修复
- 页面验收
- 规则复盘
请输出
- 主 Skill
- 后备 Skill
- 不采用的 Skill 和原因
- 与当前项目可能冲突的规则
- 交付时需要提供的证据
在我确认前，不要修改代码。这个任务卡的价值在于让 Codex 先停一下。它要先解释选择，再动手。解释不清，就说明任务边界还不够清楚。
我尤其会看"冲突"这一项。外部 Skill 的建议如果要求新技术栈、新目录结构、新 UI 组件，必须先标出来。当前项目的代码习惯、依赖和交付方式，比 GitHub 示例更靠前。
地图只解决起步
这张地图不能替代人的判断。它只解决起步时的选择问题。
真正进入代码以后，还要回到项目。看已有组件怎么写，看接口怎么封装，看测试能不能跑，看页面路径能不能打开。Skill 给的是流程，项目给的是边界。
还有一种情况要收住。任务材料不足时，不要硬选 Skill。比如用户只说"页面优化一下"，没有说明页面、问题、目标和验收方式，此时先让 Codex 补任务卡。盲选任何 Skill 都会把模糊需求包装得很像工程流程，最后还是要返工。
写在最后
GitHub Skill 的数量会继续变多，前端开发者不可能每次都完整读一遍。我的做法是先把任务按证据分类，再选最小组合。
要页面骨架，找构建类。要行为稳定，找 TDD。要修问题，找调试。要验收页面，找浏览器测试。要沉淀规则，走复盘模板。
这张地图帮 Codex 开始得更稳，也帮我少做无效解释。下一篇继续往下走。多个 GitHub Skill 同时命中时，规则之间会打架，我会先给 Codex 定一套优先级。
本系列持续更新，继续围绕 Codex 和 GitHub Skills，把公开材料压成前端任务里能执行、能验收的工作方式。