这 10 个 Skill 都是我自己开发并且已经开源的。它们对应我日常反复执行的具体动作：提交代码、拆分任务、剪视频、生成封面、准备发布、整理成稿和检查交付物。在实际使用里，它们连接成开发、视频和内容三条流程。
开发任务里的提交和分工
开发任务结束后，我会调用 git-ship。它把高频的提交步骤固定下来：先在当前分支同步主分支，然后切分支、提交代码、合并分支，再切回主分支拉取最新代码。
我在频繁迭代代码时用它快速完成一次分支提交。仓库在 oil-oil/git-ship。
任务还没有进入提交阶段时，我会用 team-mode 拆分工作。它会在 Codex 里创建四个自定义子 Agent：Explorer、Executor、Complex Executor 和 Reviewer，并为不同职责配置对应的模型，例如 Explorer 和 Executor 使用 Luna。
这些子 Agent 的使用成本较低，繁琐任务可以并行派发，也能减少主 Agent 的额度消耗。Skill 记录了各个角色的使用条件，并提供初始化流程，不需要逐个创建配置。仓库在 oil-oil/codex-team-mode。
一条视频从剪辑到发布
视频工作流从 screen-studio-editor 开始。它负责剪辑和添加字幕，我录制这组内容时也使用它处理字幕。
仓库在 oil-oil/screen-studio-editor。字幕完成以后，下一步进入封面。
oil-cover 负责生成我日常视频的封面，3:4 和 4:3 两个比例会同时生成。我通常在字幕完成后调用它。
仓库在 oil-oil/oil-cover。封面完成后，视频才进入各个平台的发布准备。
我的视频会同步到多个平台，重复上传和填写表单很繁琐。video-publisher 会在封面完成后并行准备各个平台的草稿，并停在最终发布之前。
仓库在 oil-oil/video-publisher-skill。screen-studio-editor、oil-cover 和 video-publisher 连起来以后，视频从成片、封面到发布草稿形成了一条连续流程。
文章和演示材料的生成
处理文档、文案、PPT 或 PRD 时，我先用 oil-tone 约束成稿。模型直接输出的内容容易出现模板化表达、句子不通顺或判断过度，oil-tone 把我接受的表达方式固定成了规则。
除了一份完整的规范，它还带有语法检查。稿子出现我明确不接受的表达时，需要先修改再交付。规则要求减少口号和模板转场，同时保留具体技术概念与完整因果。仓库在 oil-oil/oil-tone。
文字确定以后，需要概念插图时我会调用 oil-visual。它生成火柴人和一只小狗组成的插图，小狗的形象来自我家的狗。
图片会处理成透明背景，放进 PPT 时不需要额外适配底色。仓库在 oil-oil/oil-visual。
如果要讲的概念较短，我不会制作整套 PPT，而是使用 oil-html 生成一张单页 HTML。页面使用网格背景，也会生成对应插图，它本身组合了几个 Skill。
录制视频前，我会用它完成一份可演示的 HTML，再对着页面讲清楚视频内容。仓库在 oil-oil/oil-html。
开源项目交付前的整理
开源项目准备交付时，我会处理代码本身和仓库首页。beautify-github-readme 负责后者：它可以为 GitHub 仓库生成顶部卡片和 SVG 标题，也能整理 README 的描述。
我的一些 Skill 仓库使用它整理首页，例如 oil-ppt。beautify-github-readme 上线不到一周时，GitHub 星标已经超过 1000。仓库在 oil-oil/beautify-github-readme。
代码检查则交给 simplify。它原本是 Claude Code 的内置 Skill，我参考它的实现，把相同思路同步到了 Codex。
每次完成代码后，它会并行启动三个子 Agent：一个检查代码质量，一个检查性能问题，另一个检查冗余代码、函数化、组件化和已有实现复用。检查完成后，项目才进入前面的 git-ship 提交流程。
没有进入前十的两个项目
oil-ppt 用来生成演示文稿，配套视频里的 PPT 就是用它完成的。我平时很少需要讲长内容，所以它的使用频率没有进入前十。
最近我还上线了 VibeHub 网站（vibe-hub.org），用于整理 Vibe Coding 术语。后续我也会把自己的一些 Skill 同步到这个网站。
这 10 个 Skill 覆盖的是我反复执行、边界也比较清楚的工作。它们分别解决一个具体环节，前后能够接成开发、视频和内容三条日常流程。