上一篇讲怎么筛 GitHub 上的前端 Skill。筛完以后还有一步更重要，把它改造成当前项目能用的任务约束。

这一点很容易被跳过。很多人看到一个 SKILL.md 写得很完整，就想整份塞给 Codex。结果 Codex 一边遵守 GitHub 上的通用规则，一边和当前项目的组件封装、目录结构、样式体系打架。最后页面可能更精致了，代码却不像这个项目。

所以我不会把 GitHub Skill 直接当项目规范。它先是一份公开参考材料，经过裁剪后，才进入 Codex 的编码任务。

第一步先记录来源，避免规则来路变糊

我会在任务卡最上面写清来源。

GitHub Skill 来源
- openai/plugins README，用来确认 Codex 插件可以包含 skills 目录
- vipulgupta2048/codex-skills 的 frontend-design，用来提取语义结构、tokens、响应式和可访问性检查
- MengTo/Skills 的 tailwindcss，用来提取动态 class 和 content 路径检查
​
使用方式
- 只作为公开材料参考
- 不安装到本地
- 不覆盖当前项目已有规范

这几行看着普通，但能挡住后面很多混乱。Codex 需要知道，这些材料的优先级排在项目现有代码、AGENTS.md、接口契约和本次需求之后。

这一步先省，后面会多花时间。

来源写清后，我审查代码时也知道某条规则从哪里来。如果它不适用，删掉就行，不用和一整份 Skill 纠缠。

第二步把规则分成三层

GitHub Skill 里的内容通常比较宽。以 frontend-design 为例，它同时讲目的、审美方向、tokens、语义结构、响应式、可访问性、性能。以 tailwindcss 为例，它同时讲工具概念、常见坑和代码片段。

我会把它们拆成三层。

层级	处理方式	前端例子
直接采用	写进本次任务硬约束	动态 Tailwind 类名用映射表，不用字符串拼接
改写后采用	转成当前项目语言	可访问性检查改成弹窗、表单、列表的焦点和标签检查
暂不采用	明确排除	新字体、新动效、新设计风格、新 UI 库

这张表能防止 Codex 把所有建议都当成命令。尤其是设计类 Skill，里面常有很多关于视觉方向的建议。当前任务只是修一个后台弹窗时，引入新的视觉手势没有必要。

第三步把通用词改成项目词

GitHub Skill 常用通用词，比如 component、layout、state、theme、content paths。交给 Codex 前，我会把这些词翻成项目里的真实对象。

通用规则
- 使用语义结构和清晰的组件拆分。
​
项目改写
- 新增筛选弹窗时，保持 pages 下页面只负责入口和组装。
- 表单字段逻辑放在现有 form 组件内，不把接口请求散到子组件。
- 状态命名沿用当前页面已有的 searchForm、queryParams、tableData、loading。

改写以后，Codex 不需要猜“语义结构”在这个仓库里意味着什么。它会先去找相近页面，然后沿用命名、目录和调用方式。

这一点对前端很关键。React、Vue、Tailwind、Element Plus 都只是技术栈，项目里的组织方式才决定代码能不能合并。

第四步给 Codex 写清禁止项

GitHub Skill 往往鼓励更完整的设计或更好的结构。放到项目里，最容易带来无关修改。

所以我会单独写禁止项。

本次禁止
- 不新增 UI 库。
- 不改全局 Tailwind 配置，除非任务明确要求。
- 不为了视觉统一重写已有组件。
- 不把 GitHub Skill 中的示例代码原样搬进项目。
- 不改变接口调用入口和路由结构。

这些禁止项听起来克制，但很有用。Codex 写前端代码时常会顺手把旁边的样式也改了，或者把页面拆成另一套它更熟悉的结构。禁止项能让它留在任务范围里。

第五步把验收动作压到最后

我会把 GitHub Skill 里的 QA 内容改成当前任务的验收动作。

交付前自查
- 列出本次采用的 GitHub Skill 规则。
- 列出没有采用的规则和原因。
- 检查新增 class 是否会被 Tailwind content 路径扫描到。
- 检查动态 class 是否使用映射表。
- 检查弹窗或表单是否有键盘焦点和标签。
- 检查小屏下按钮、表格操作和提示文案是否溢出。
- 说明哪些需要人打开页面复核。

这里我特别看重“没有采用的规则和原因”。Codex 会写出取舍，说明它在按当前项目裁剪，而非机械照抄。人审查时，也能看到它有没有把 GitHub 资料误判成项目规范。

一份可以直接交给 Codex 的任务卡

下面这份卡可以复制到前端任务里，再按项目改名。

任务
请基于当前项目已有页面，完成这个前端改动。
​
GitHub Skill 参考
- frontend-design 中的语义结构、tokens、响应式和可访问性检查
- tailwindcss 中的动态 class、content 路径和组件拆分建议
​
优先级
1. 当前项目已有代码和 AGENTS.md
2. 本次需求和接口契约
3. 从 GitHub Skill 裁剪后的可用规则
​
采用规则
- 使用项目已有组件和目录结构。
- 动态 class 使用映射表。
- 新增交互保留键盘焦点和可见 focus 样式。
- 小屏下检查按钮、表格操作和长文本。
​
禁止
- 不安装本地 Skill。
- 不新增 UI 库。
- 不重写无关组件。
- 不照搬 GitHub 示例代码。
​
交付
- 说明采用了哪些参考规则。
- 说明排除了哪些参考规则。
- 给出静态检查和页面复核建议。

这份卡的目的很明确，让 Codex 借用 GitHub Skill 的经验，但代码仍然长在当前项目里。它不会解决所有前端质量问题，也不会替我决定设计方向，可它能把一次外部资料阅读变成可审查的编码输入。对日常开发来说，这已经够实用了。

写在最后

GitHub Skill 最适合做参考材料和规则来源。它能提醒我们前端编码里容易漏掉的响应式、可访问性、动态类名、结构拆分和验收动作。

真正交给 Codex 时，要经过一轮改造。记录来源，裁剪规则，改成项目词，写清禁止项，最后加验收动作。做到这一步，GitHub Skill 才能从“别人仓库里的好文档”，变成当前前端任务里能用的编码约束。

下一篇可以继续写一个更小的实战场景，把这份清单用在具体页面上。比如让 Codex 改一个 Tailwind 表单或一个 Vue 列表操作区，看哪些规则能落地，哪些仍然要由人来判断。

本系列持续更新，后续仍会围绕 Codex、Skills 和前端代码治理，把可公开验证的工具材料转成日常开发流程。