连续写了几篇 GitHub Skill 以后，问题从“哪个 Skill 好用”变成了“它们一起怎么用”。

单个 Skill 讲起来都很顺。web-artifacts-builder 负责把页面骨架立起来，test-driven-development 要求先写失败测试，systematic-debugging 让 Codex 修 bug 前先查根因，webapp-testing 用浏览器验证页面路径。每一个都能解决一段问题。

可真正写前端代码时，麻烦经常发生在顺序上。先让 Codex 生成页面，再想起来补测试，测试会顺着已有实现写。先让它修 bug，没有复现路径，修复就容易变成猜。页面改完只看代码，浏览器里按钮有没有真的点通还不知道。

所以我会把这四个 Skill 按任务时序排好。它们分段上场，各自守住一段。

先用构建 Skill 限制起点

独立页面或原型任务，最怕 Codex 从空白开始发挥。它一旦自己选技术栈、自己造组件结构、自己决定样式方式，后面再补规则会很费劲。

这时我会先让 web-artifacts-builder 上场。它的价值不在写了多少业务代码，而在起手就把 React、TypeScript、Vite、Tailwind、shadcn/ui 这些骨架固定住。骨架固定后，Codex 的主要精力才会落到页面和交互上。

任务可以这样写。

本次是独立前端页面任务。
先按 web-artifacts-builder 初始化工程骨架。
初始化完成后再写页面，不自行更换技术栈、组件库和样式方案。
业务代码必须放进生成后的工程结构里。

如果是已有 Vue 后台项目，我不会用这一步。已有项目的骨架已经在仓库里，外部构建 Skill 只能做参考，不能接管结构。

写逻辑前先让 TDD Skill 盯住行为

页面骨架有了，下一步不要急着铺满组件。

凡是能抽成纯逻辑的部分，我会先让 test-driven-development 参与。比如金额格式化、状态转换、搜索参数归一、分页计算、表单校验。这些代码有明确输入和输出，适合先写失败测试。

我给 Codex 的要求会很短。

这个功能里先处理可独立测试的逻辑。
按 test-driven-development 执行。
先写会失败的测试，运行后说明失败原因。
再写最小实现让测试通过。
通过前不要进入 UI 组件开发。

这条顺序能挡住一个常见问题。Codex 先写实现，再补测试，测试往往只证明它刚写的代码符合它自己的想象。先失败一次，行为边界会更早暴露。

出问题时切到调试 Skill

写代码过程中总会出错。构建报错、单测不通过、页面渲染异常、接口数据进来以后状态变乱，这些都不能靠继续加代码解决。

一旦出现错误，我会暂停生成任务，把 Codex 切到 systematic-debugging。

现在进入调试流程。
先输出根因调查，包含错误信息、复现路径、最近改动、相关数据流和相似正常实现。
不完成根因调查，不给修复代码。
一次只验证一个假设。
同一个问题连续三次修不好，停下来重新评估结构。

这里我最看重的是暂停。很多前端问题的成本，不在 bug 本身，而在 Codex 边猜边改，把一个小问题扩成多文件修改。调试 Skill 把它按住，让它先解释证据，再动代码。

页面交付前让浏览器 Skill 收尾

测试通过以后，还差一步。

函数层测试能证明纯逻辑，证明不了用户真的能完成页面动作。页面按钮可能被遮住，弹窗焦点可能丢了，异步加载可能让 DOM 还没出来就被查找。这个时候轮到 webapp-testing。

我会让 Codex 只覆盖本次改动的关键路径，不写大而全的自动化套件。

按 webapp-testing 写一段浏览器验证脚本。
启动本地页面后，走本次改动涉及的用户路径。
动态应用先等 networkidle，再查找 DOM。
只验证本次行为，不顺手改业务代码。
交付时写清每一步页面结果。

这一步的目标是把“我看代码觉得可以”改成“浏览器按路径走过”。前端代码最终给人点，验收也应该回到浏览器里。

四个 Skill 的上场顺序

我会把它们排成这张表。

阶段	用哪个 GitHub Skill	Codex 产出	人要检查什么
起步	web-artifacts-builder	工程骨架和页面起点	技术栈是否适合当前任务
写逻辑	test-driven-development	失败测试、最小实现、通过结果	测试是否真的定义了行为
修问题	systematic-debugging	根因调查、假设、修复	证据是否支撑根因结论
交付前	webapp-testing	浏览器验证脚本和页面结果	用户路径是否覆盖关键风险

这张表最重要的地方，是每个阶段都有明确产出。Codex 不能只说“已完成”，它要交骨架、测试、调查、脚本和结果。人审查时也能沿着这些产物看，不用在一大段自然语言里猜它到底做了什么。

我不会把四个 Skill 全部塞进一个提示

这里要克制。

一个简单的文案调整，不需要构建 Skill，不需要 TDD，也不需要浏览器脚本。一个已有项目里的按钮样式修正，可能只需要页面验证。一个纯函数 bug，可能只需要 TDD 和调试流程。

我会先按风险选最小组合。

任务是独立页面，从构建开始。
任务是纯逻辑，从 TDD 开始。
任务是已知 bug，从调试开始。
任务是页面验收，从 webapp-testing 开始。

Skill 多了以后，真正考验人的地方在取舍。少加载能让 Codex 聚焦，审查也干净。

写在最后

这四个 GitHub Skill 连起来，正好覆盖前端任务里最容易散掉的四个动作。起步要有骨架，写逻辑要有失败测试，修问题要有根因调查，交付前要有浏览器路径。

它们给 Codex 的价值在顺序。顺序一稳定，前端任务就少了很多来回猜的空间。

下一篇我会继续讲减法。GitHub 上的 Skill 越来越多，不能看到一个有用就往项目里放。我要把外部 Skill 进入项目前的准入表写清楚，哪些能留下，哪些只能当资料看。

本系列持续更新。后面仍围绕 Codex 和 GitHub Skills，继续把公开规则整理成前端开发能执行、能验收的流程。