如何自定义一个 Codex Skill用 myskill-global 搭建父子工作流前一篇文章已经讲过 Codex skill 的内部结构一个 skill 通常由SKILL.md、agents/openai.yaml、scripts/、references/、assets/等部分组成。其中SKILL.md是入口description决定触发场景正文负责工作流程其他目录负责补充元数据、脚本、资料和素材。理解这些配置层级之后下一个更实用的问题是如果想把自己的长期工作方式沉淀下来应该怎么自定义一个 skill举个例子如果你在开会又想语音记录又想自动写笔记乃至于还想直接根据领导指示去采购。那么父skill负责路由任务到这三个不同的子skill然后分别执行子任务。重点内容这篇文章重点讲一个更高级的用法不要只做一个单点 skill而是设计一个“父 skill 子 skill”的工作流。父 skill 负责判断任务类型和路由子 skill 负责具体执行。本文会用真实的父 skillmyskill-global作为例子同时为了避免把某个现有业务流程写死会用一个虚构的子 skillmeeting-summary-pro来演示父子 skill 如何配合。1. 自定义 skill 不是写长提示词很多人第一次写 skill会把它写成一个加强版提示词你是一个擅长整理会议纪要的助手请把内容总结得清晰、专业。这当然有用但它还不是一个真正稳定的 skill。一个可复用的 skill应该沉淀的是“工作方式”而不只是“语气要求”。它要回答这些问题什么样的用户请求会触发它它接到请求后先判断什么它应该把任务交给哪个目录或哪个子流程它需要读取哪些本地规则它最终应该产出什么哪些事情不应该做也就是说自定义 skill 的重点不是把提示词写得更长而是把你反复使用的判断逻辑、目录规则和交付标准固定下来。2. 什么是父 skill父 skill 可以理解成一个总调度器。它本身不一定直接完成具体任务而是负责判断用户的请求应该进入哪条工作流。以myskill-global为例它的定位就是全局父 skill。它的description可以这样理解name:myskill-globaldescription:Use this skill as the users global parent orchestrator. It should classify high-level requests,identify the correct workspace or content workflow,find relevant child skills or local workflow files,and route Codex into the right execution path with minimal repeated instruction from the user.这里最关键的是global parent orchestrator也就是“全局父级编排器”。它负责判断用户现在提出的是哪类任务这个任务应该进入哪个工作区有没有对应的子 skill如果子 skill 没有自动触发是否可以读取它的SKILL.md作为流程依据最终应该以什么形式交付父 skill 的价值在于减少重复沟通。用户不用每次都从头解释自己的目录规则、输出偏好和任务流程。父skill全文https://blog.csdn.net/m0_54138660/article/details/160903683?spm1001.2014.3001.55013. 什么是子 skill子 skill 是具体执行者。父 skill 解决“去哪里、找谁做”的问题子 skill 解决“怎么把这件事做好”的问题。可以用一个虚构例子来理解myskill-global └── 判断任务类型 └── 选择目标目录 └── 找到对应子 skill └── 交给具体流程执行 meeting-summary-pro └── 读取会议录音转写稿 └── 提取议题、结论和待办 └── 区分负责人和截止时间 └── 输出会议纪要 Markdown在这个例子里myskill-global是父 skillmeeting-summary-pro是虚构的子 skill。用户只需要说帮我把这份会议转写整理成纪要。父 skill 判断这是会议纪要任务然后路由到会议资料目录并交给meeting-summary-pro这类子 skill 处理。子 skill 再负责具体的纪要结构、待办提取、格式规范和最终文件生成。4. 实操父 skill 和子 skill 分别放在哪里自定义 skill 时最容易卡住的问题不是怎么写内容而是文件到底放在哪里。一般可以分成两种放法。放法一全局 skills 目录如果希望某个 skill 在不同项目中都能被 Codex 发现通常把它放到 Codex 的全局 skills 目录。在 Windows 上常见位置类似C:\Users\你的用户名\.codex\skills\父 skill 适合放在这里因为它要负责跨项目、跨任务做全局路由。例如C:\Users\你的用户名\.codex\skills\ └── myskill-global\ ├── SKILL.md └── agents\ └── openai.yaml这样myskill-global就更像一个全局入口。无论你在哪个工作区只要请求符合它的触发描述它都有机会参与判断。放法二工作区内部 skills 目录如果某个 skill 只服务于一个工作区也可以放在项目或工作区自己的skills/目录中。例如某个长期工作区是E:\workspace\my-ai-workbench\可以这样组织E:\workspace\my-ai-workbench\ ├── AGENTS.md ├── skills\ │ ├── myskill-global\ │ │ ├── SKILL.md │ │ └── agents\ │ │ └── openai.yaml │ └── meeting-summary-pro\ │ ├── SKILL.md │ ├── references\ │ │ └── meeting-format.md │ └── agents\ │ └── openai.yaml └── meeting-notes\ └── AGENTS.md这种方式适合把 skill 当成项目资产来维护。它的好处是路径清晰方便和项目规则一起版本化管理。推荐实践更推荐的组合是父 skill 放全局 skills 目录。子 skill 可以放全局 skills 目录也可以放工作区skills/目录。工作区内再用AGENTS.md补充目录规则。例如C:\Users\你的用户名\.codex\skills\ └── myskill-global\ ├── SKILL.md └── agents\ └── openai.yaml E:\workspace\my-ai-workbench\ ├── AGENTS.md ├── skills\ │ └── meeting-summary-pro\ │ ├── SKILL.md │ ├── references\ │ │ └── meeting-format.md │ └── agents\ │ └── openai.yaml └── meeting-notes\ └── AGENTS.md这样父 skill 负责全局识别和路由子 skill 负责当前工作区里的专业任务。5. 父 skill 里面应该写什么父 skill 的SKILL.md不需要特别长。它最重要的是维护一张任务路线图。一个父 skill 通常要写清楚三类内容。第一自己的角色。例如This is the users global parent skill. Its role is to help Codex recognize the type of task, find the correct custom workflow, and use child skills when available.第二路由规则。例如使用虚构的会议纪要任务When the request is about: - meeting transcript cleanup - meeting summary generation - action item extraction - decision and owner tracking route to: - target folder: E:\workspace\my-ai-workbench\meeting-notes - preferred child skill: E:\workspace\my-ai-workbench\skills\meeting-summary-pro\SKILL.md第三可靠性规则。父 skill 不应该假设所有子 skill 都一定能自动触发。更稳妥的写法是Use this priority: 1. globally available installed skill 2. target folder workflow files 3. workspace-local child skill as an instruction source这条规则很重要。即使某个子 skill 没有被系统自动注入Codex 也可以读取它的SKILL.md把它当作本地流程说明来使用。6. 子 skill 里面应该写什么子 skill 不需要关心全局路由它只需要把自己的专业任务做好。以虚构的meeting-summary-pro为例它的SKILL.md可以这样设计--- name: meeting-summary-pro description: Use this skill when the user wants to turn meeting transcripts, rough notes, or discussion records into structured meeting minutes with decisions, owners, deadlines, risks, and follow-up action items. --- # Meeting Summary Pro ## Purpose Turn messy meeting input into structured meeting minutes. ## Workflow 1. Identify meeting topic and participants. 2. Extract decisions. 3. Extract action items. 4. Attach owners and deadlines when available. 5. Separate unresolved questions from confirmed conclusions. 6. Output a clean Markdown meeting note. ## Output Rules - Do not invent owners or deadlines. - Mark missing owners as TBD. - Keep decisions separate from discussion background. - Put action items in a table.这个子 skill 很专注。它不负责判断用户的整个工作区结构也不负责判断是否应该进入其他项目。它只负责会议纪要质量。这就是子 skill 的写法领域越清晰执行越稳定。7. 父子 skill 如何协作父子 skill 的协作可以抽象成一个链路用户请求 → 父 skill 判断任务类型 → 父 skill 找到目标目录 → 父 skill 找到子 skill 或本地流程文件 → 子 skill 执行具体任务 → Codex 按目标格式交付结果用虚构的会议纪要例子用户帮我整理这份会议转写 → myskill-global 判断为 Meeting Summary → 路由到 meeting-notes → 使用 meeting-summary-pro → 输出结构化会议纪要如果后续又增加一个虚构子 skillcontract-review-pro父 skill 只需要新增一段注册规则Contract Review: - trigger: contract review, clause risk, legal summary - target folder: E:\workspace\my-ai-workbench\contracts - preferred child skill: E:\workspace\my-ai-workbench\skills\contract-review-pro\SKILL.md父 skill 不需要知道合同审查的所有细节它只需要知道什么时候把任务交给contract-review-pro。8. 为什么不要把所有规则写进一个 skill把所有规则都写进一个巨大的SKILL.md短期看起来简单长期会很难维护。常见问题包括description变得很泛触发边界不清楚。SKILL.md太长加载后带入大量无关信息。修改一个任务流程时容易影响其他任务。新增任务类型时父 skill 越来越臃肿。父子 skill 的好处是把复杂度拆开父 skill 只负责分类和路由。子 skill 只负责专业执行。工作区文件负责目录级长期规则。新增流程时只需要新增子 skill再在父 skill 注册入口。这和软件工程中的模块化很像。一个稳定系统不应该把所有逻辑塞进一个文件而应该让每个模块只负责自己最清晰的职责。9. 自定义父子 skill 的推荐步骤第一步先整理高频任务。不要一开始就写一个很大的父 skill。先观察自己最常让 Codex 做什么。例如整理会议纪要审查合同条款生成周报分析客户访谈整理课程大纲生成项目复盘第二步为每类高频任务设计一个子 skill。例如meeting-summary-pro contract-review-pro weekly-report-pro customer-interview-analyzer course-outline-builder project-retrospective-pro这些名字可以是虚构的也可以根据自己的真实工作慢慢创建。第三步再写父 skill。父 skill 只负责注册这些子流程Meeting Summary → meeting-notes → meeting-summary-pro Contract Review → contracts → contract-review-pro Weekly Report → weekly-reports → weekly-report-pro第四步把目录规则写进AGENTS.md。如果某个工作区有固定目录结构建议在工作区根目录或子目录中放AGENTS.md说明这个目录的用途、输出规则和默认行为。第五步在真实任务中迭代。观察 Codex 有没有走错目录忘记读取子 skill输出格式不稳定把不该写进正文的说明写进了结果对任务类型判断不准每发现一个重复问题就把规则补进父 skill、子 skill 或AGENTS.md。10. 一个可复用的父子 skill 模板父 skill 模板name: myskill-global role: global parent router When the user gives a high-level request: 1. classify the task 2. identify the target workspace or folder 3. identify the likely child skill 4. read local workflow files when needed 5. execute through the most reliable path子 skill 模板name: meeting-summary-pro role: specific task executor When the user gives meeting transcripts or rough notes: 1. extract agenda 2. extract decisions 3. extract action items 4. identify owners and deadlines 5. output structured Markdown工作区模板my-ai-workbench/ ├── AGENTS.md ├── skills/ │ └── meeting-summary-pro/ │ ├── SKILL.md │ └── references/ │ └── meeting-format.md └── meeting-notes/ └── AGENTS.md三者分工很清楚父 skill 决定去哪里。子 skill 决定怎么做。工作区规则决定这个目录里长期遵守什么标准。结语自定义 Codex skill 的关键不是写一个越来越长的提示词而是把自己的长期工作方式做成可复用系统。上一篇文章讲的是 skill 的配置层级SKILL.md、agents/、scripts/、references/、assets/分别负责什么。到了自定义阶段更重要的是理解这些 skill 之间如何协作。myskill-global这种父 skill 的价值在于它不急着亲自完成所有任务而是先判断任务类型、找到目标目录、选择对应子 skill 或本地流程文件。真正的执行细节可以交给meeting-summary-pro、contract-review-pro这类子 skill。它们可以是真实存在的也可以是你接下来准备创建的能力模块。当父 skill、子 skill、工作区规则配合起来后Codex 就不再只是每次重新听需求的通用助手而会逐渐变成一个熟悉你工作方式的长期协作者。你只需要提出高层需求它就能沿着预设路线找到正确流程并按你习惯的方式交付结果。