公开 Skill 数量已经很大，前端开发不能看到一个好用就交给 Codex。本文给出一张 GitHub Skill 准入表，从来源、许可、触发场景、项目冲突、可验证性和维护成本六处筛选，帮助读者把外部 Skill 留在该留的位置。

前几篇分别写了构建、TDD、调试和浏览器验证四类 GitHub Skill。本文把它们串成一条前端任务顺序：先立骨架，再写失败测试，再按根因修问题，最后让浏览器走关键路径。读者可以直接拿这套顺序约束 Codex，减少重复返工。

Codex 说前端页面改完了，只看代码 diff 和构建通过不算验收。我从 GitHub 官方仓库拉来 webapp-testing，用 Playwright 让浏览器按真实路径点一遍。本文讲这个测试 skill 的用法、怎么接进 Codex 的页面验收，以及静态页和动态应用两条路径的区别。

Codex 修前端 bug 时最常见的坏动作，是看到报错就猜原因，改一下看行不行，不行再改，最后症状修好根因没动。我从 GitHub 的 superpowers 仓库拉来 systematic-debugging，用它的四阶段约束 Codex，先找根因再动手。本文讲这个方法怎么接进 Codex，和生成类 skill 怎么分工。

Codex 从空白开始写前端页面，容易每个页面各写一套、技术栈自己定、组件库自己造。我从 GitHub 官方仓库拉来 web-artifacts-builder，让 Codex 先用初始化脚本立起 React 加 Vite 加 Tailwind 加 shadcn/ui 骨架，再在骨架里改代码，最后打包成单文件交付。本文讲这个 skill 的真实规则、接进 Codex 的方式和适用边界。

前端 Skill 不能直接当项目规范用。本文给出一份改造清单，把公开 Skill 拆成来源记录、可用规则、项目映射、任务禁区和验收动作五部分，让 Codex 写前端代码时有明确边界，也方便人来审查取舍。

前端 Skill 不能直接当项目规范用。本文给出一份改造清单，把公开 Skill 拆成来源记录、可用规则、项目映射、任务禁区和验收动作五部分，让 Codex 写前端代码时有明确边界，也方便人来审查取舍。

最近用 Codex 辅助做了一套漫画 APP 下载站 CMS（comicStrip）：后台发布文章，前台自动生成静态页，配套深度 SEO 和 AI 写作。本文简述 Codex 在哪几块出力最多、哪几块必须人把关，落成一个可用、可推广的下载站。

最近用 Codex 辅助做了一套漫画 APP 下载站 CMS（comicStrip）：后台发布文章，前台自动生成静态页，配套深度 SEO 和 AI 写作。本文简述 Codex 在哪几块出力最多、哪几块必须人把关，落成一个可用、可推广的下载站。

本文摘要：项目特定编码规则应聚焦3-5条核心约束，每条需具备"Codex无法推测"的特性，如统一列表查询入口、禁止直接修改props等。规则需包含：1）具体文件定位；2）正反代码示例（反例尤为关键）；3）可操作的验收标准（静态检查/运行时验证）。Skill内容应精简，通过任务声明或文档常驻方式加载，仅规范"怎么写"而非业务逻辑。有效规则需包含方向指引、边界反