codex-pr-body 技能详解Open Interpreter 中由 Agent 自动撰写 PR 标题与正文的工程实践【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter在 Open Interpreter面向 Kimi K3、GLM 5.3 等开放模型的编码 Agent 项目仓库里.codex/skills/codex-pr-body/SKILL.md定义了一个名为codex-pr-body的 Agent 技能当用户希望更新一个或多个 Pull Request 的标题与正文时Agent 会依据该技能中沉淀的规则自动推断目标 PR、保留既有正文的关键信息并按“先讲动机、再讲改动、只讲净变更”的结构重写 PR 描述。读完本文你能掌握该技能的完整触发逻辑、PR 正文编写规范、Stacked PR 与 Sapling SCM 场景下的特殊处理方式以及项目技能Skills系统是如何发现并加载这类技能的源码级原理。技能定位与文件结构codex-pr-body是仓库内置的一组开发流程技能之一位于 .codex/skills/codex-pr-body/SKILL.md。该文件采用标准的技能文件结构YAML frontmatter 声明name: codex-pr-body与description: Update the title and body of one or more pull requests.正文则是 Agent 执行该技能时必须遵循的操作规程。按照项目官方文档 docs/skills.md 的说明一个技能就是一个包含SKILL.md的目录可选附带scripts/、references/、assets/等支持目录其中description字段决定了技能何时被选中因此必须写得具体。文档同时给出了技能目录的三种作用域路径作用域.agents/skills/仓库或目录级技能~/.agents/skills/个人技能Bundled skills内置工作流需要指出的是codex-pr-body这类项目自身的内部流程技能存放在.codex/skills/下同一目录还有 babysit-pr、code-review、codex-bug等姊妹技能与面向用户的新增技能推荐路径.agents/skills/并存。从源码结构看仓库的技能发现逻辑在 codex-rs/core-skills/src/loader/discovery.rs 中实现discover_skills会对技能根目录做受控目录遍历递归模式与直接子目录模式对应不同的扫描深度并带有最大条目数、最大目录数等截断保护随后由 injection.rs 等模块把匹配到的技能内容注入会话上下文。这意味着codex-pr-body的正文本质上是“可被检索、按需加载的规程文本”而不是可执行脚本。第一步确定要更新哪个 PR技能的第一节Determining the PRs规定了目标 PR 的确定方式显式指定调用方直接给出要更新的 PR自动推断常见情况从用户当前所在的分支 / commit 推断。对于普通 Git 使用场景而非后文讨论的 Sapling可能需要组合使用git branch gh pr view branch --repo openai/codex --json number --jq .number即先用git branch拿到当前分支名再用gh pr view按分支查询 GitHub 上对应的 PR通过--json number --jq .number只输出 PR 编号供后续编辑命令使用。这条链路对应技能 description 中 “Update the title and body of one or more pull requests” 的“one or more”——技能并不假设 PR 唯一需要按分支与 PR 的对应关系逐个处理。PR 正文内容规范技能的主体部分“PR Body Contents” 一节是该技能的核心定义了重写 PR 标题与正文时必须遵守的七条规则。下面逐条展开并结合仓库实际写作要求说明其工程意图。1. 用gh编辑且必须先保护既有正文技能要求通过gh编辑 PR 的正文与标题使其反映 PR 的实际内容并且必须先检查现有 PR 正文确认其中有否需要保留的关键信息。文档特别强调了一条“不可逆”约束绝不能删除现有正文中的图片——一旦被删除作者可能没有任何途径恢复它。这是典型的“编辑类 Agent 行为守则”写操作可能不可逆因此规程要求 Agent 在改写前先做保全性读取。2. 先讲“为什么”再讲“改了什么”技能明确规定解释why为什么做这个变更是重中之重如果触发该技能的当前会话中已经讨论过动机必须把动机写进 PR 正文。而what具体改了什么同样必须解释但必须出现在 why 之后。这个顺序约束保证了 PR 描述对评审者是最易读的结构先建立上下文与必要性再展开实现细节。3. 只描述“净变更”删掉开发过程中的弯路技能指出正文应当把讨论限制在 commit 的**净变更net change**范围内在 PR 开发过程中“尝试过后来又撤销”的改动在评审文化中是不受欢迎的。因此重写正文时需要主动剔除这类对后续读者已无意义的细节。这条规则实际是在约束 Agent重写不是把会话历史照搬进 PR而是要做一次面向读者的信息筛选。4. 避免本地绝对路径与内部机密两条“卫生”规则谈论仓库内的路径时一律使用仓库相对路径避免引用作者本地磁盘上的绝对路径这些路径对评审者毫无意义且泄露机器信息避免引用任何机密信息包括但不限于内部代号与公司内部 URL。这与仓库其他技能如 babysit-pr中同样强调的“输出面向公开 PR 场景”一脉相承说明项目把“PR 正文视为准公开文档”作为一条通用准则。5. 如何描述验证方式技能认为讨论“变更是如何被验证的”通常有帮助但给出了明确的边界不要列出 CI 会自动检查的内容例如不要写 “ranjust fmt” 之类的格式化步骤应该指出为验证新行为而特意新增的测试。从项目结构看仓库大量使用基于just的任务编排如 justfile与 Rust 集成测试套件如 codex-rs/core/tests/suite/skills.rs因此“新增测试”在这里有明确的落点而格式化、构建类检查确实由 CI 兜底无需在 PR 正文中重复声明。6. 用 Markdown 把 PR 写得专业技能对正文格式给出了具体指令行内引用“代码事物”时使用单反引号包裹引用代码或展示 shell 会话时使用围栏代码块fenced code blocks引用与本次变更相关的既有代码时使用GitHub permalinks含 commit SHA 的永久链接避免引用漂移的main分支代码。7. 引用相关 PR / Issue但不要自引用正文应引用相关的 PR 或 Issue 以建立关联但无需在 PR 自己的正文里引用它自己。8. 文档站点更新提醒技能还要求如果本次变更意味着开发者文档站点上存在需要同步更新的文档请在 PR 正文靠后的位置单列一个章节说明此事如果没有文档需要更新则省略该章节。这一条把“代码变更 → 文档债务”的联动显式化使文档更新不会淹没在 PR 讨论中。处理 Stacks按整栈净变更来写而不是按单条 commit“Working with Stacks” 一节覆盖两种常见场景场景一commit 栈。一个 PR 可能由多条相互叠加的 commit 组成。此时 PR 正文应反映整个栈引入的净变更而不是逐条描述栈中的各个 commit。这与前文“只写净变更”的规则互为补充粒度从 commit 提升到了 PR。场景二Stacked PRs。用户可能使用 Sapling 等工具实现“堆叠式 PR”——此时某个 PR 的base可能是栈中另一个 PR 的head而不是main。技能明确要求在这种情况下正文只讨论该 PR 的base与head之间的净变更而不是相对于main的变更。换言之正文的作用域必须与 PR 实际 diff 的作用域对齐。Sapling 场景下的 PR 发现sl log与sl sl最后一节Sapling处理 VCS 不再是纯 Git 的情况。Sapling SCM 是 Meta 主导的开源版本控制系统仓库内部文档称其为 Sapling SCM 管理其识别标志是.git/sl/store目录的存在若该目录存在则这个 Git 仓库实际上由 Sapling 治理。在 Sapling 下判断当前 revision 是否关联 GitHub PR 的推荐命令是sl log --template {github_pull_request_url} -r .该命令用模板字段{github_pull_request_url}直接输出当前修订关联的 PR 链接若有关联。另一种方式是运行sl sl查看当前开发分支以及其是否关联 GitHub PR。技能给出了如下示例输出并逐行解读 cb032b31cf 72 minutes ago mbolin #11412 ╭─╯ tui: show non-file layer content in /debug-config │ o fdd0cd1de9 Today at 20:09 origin/main │ ~表示当前 commit 是cb032b31cf它是一个开发分支从origin/main切出仅包含一个 commit该 commit 关联 GitHub PR #11412。把这一节与技能开头的 PR 发现逻辑对照可以看到codex-pr-body对“找到 PR”这件事做了双路径设计普通 Git 走git branchgh pr viewSapling 走sl log/sl sl。这也是该技能相比简单脚本的价值所在——它把多 VCS 工具链下的分支到 PR 的映射规则沉淀成了 Agent 可直接执行的规程。技能如何被加载与执行仓库源码视角的佐证结合项目源码可以进一步理解这类纯规程型技能的运行机制发现阶段codex-rs/core-skills/src/loader/discovery.rs 中的discover_skills遍历技能根目录区分递归与直接子目录两种SkillDiscoveryMode并收集plugin_roots、namespace_roots与告警信息扫描失败或截断时以 warning 形式暴露而不是静默跳过。仓库测试 codex-rs/analytics/src/analytics_client_tests.rs 中出现的.codex/skills/doc/SKILL.md等路径印证了.codex/skills是技能发现链路实际覆盖的目录之一且日志/引用中会被规范化为仓库相对路径——这与codex-pr-body正文中“避免本地绝对路径”的要求在理念上是一致的。选择阶段按 docs/skills.md 的说法Open Interpreter 先读取技能元数据frontmatter仅当请求与description匹配时才加载完整技能内容。codex-pr-body的 description“Update the title and body of one or more pull requests.”因此直接界定了它的触发边界只有当用户表达出更新 PR 标题/正文的意图时整套规程才会被注入。执行阶段codex-pr-body不包含脚本Agent 需自行调用gh、git或sl命令完成查询与编辑。按项目对技能脚本与工具调用的一贯约束这类命令仍会经过正常的沙箱与审批控制技能本身不能也不应依赖绕过权限。作为对照同一目录下的 babysit-pr 技能则带有scripts/gh_pr_watch.py等可执行脚本展示了“规程 脚本”的更重形态而codex-pr-body证明了纯规程型技能在“知识密集、命令简单、判断为主”的场景PR 写作中的适用性。适用前提与实践要点使用该技能需要满足以下前提环境已安装并登录ghCLI能够访问目标仓库技能示例中查询的是openai/codex仓库的 PR实际使用时以当前仓库为准若项目运行在 Sapling 之上需有sl命令可用当前工作目录处于与 PR 对应的分支或 commit 上以便自动推断。从团队实践角度codex-pr-body沉淀出的 PR 写作规范可以脱离 Agent 单独借鉴结构顺序固定为why → what → verification → 文档更新提醒只写净变更删掉过程性弯路路径一律仓库相对机密信息代号、内部 URL一律不出现在正文验证部分只提新增测试不提 CI 兜底项引用既有代码用 permalink引用相关 PR/Issue 但不自引用Stacked PR 场景下正文范围与 PR 的 base/head diff 严格对齐。这套规则把“PR 正文应该长什么样”从个人风格变成了可被 Agent 稳定执行、可被团队统一审查的工程标准也是 Open Interpreter 仓库将自身开发流程 Skill 化的一个典型样本。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
codex-pr-body 技能详解Open Interpreter 中由 Agent 自动撰写 PR 标题与正文的工程实践【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter在 Open Interpreter面向 Kimi K3、GLM 5.3 等开放模型的编码 Agent 项目仓库里.codex/skills/codex-pr-body/SKILL.md定义了一个名为codex-pr-body的 Agent 技能当用户希望更新一个或多个 Pull Request 的标题与正文时Agent 会依据该技能中沉淀的规则自动推断目标 PR、保留既有正文的关键信息并按“先讲动机、再讲改动、只讲净变更”的结构重写 PR 描述。读完本文你能掌握该技能的完整触发逻辑、PR 正文编写规范、Stacked PR 与 Sapling SCM 场景下的特殊处理方式以及项目技能Skills系统是如何发现并加载这类技能的源码级原理。技能定位与文件结构codex-pr-body是仓库内置的一组开发流程技能之一位于 .codex/skills/codex-pr-body/SKILL.md。该文件采用标准的技能文件结构YAML frontmatter 声明name: codex-pr-body与description: Update the title and body of one or more pull requests.正文则是 Agent 执行该技能时必须遵循的操作规程。按照项目官方文档 docs/skills.md 的说明一个技能就是一个包含SKILL.md的目录可选附带scripts/、references/、assets/等支持目录其中description字段决定了技能何时被选中因此必须写得具体。文档同时给出了技能目录的三种作用域路径作用域.agents/skills/仓库或目录级技能~/.agents/skills/个人技能Bundled skills内置工作流需要指出的是codex-pr-body这类项目自身的内部流程技能存放在.codex/skills/下同一目录还有 babysit-pr、code-review、codex-bug等姊妹技能与面向用户的新增技能推荐路径.agents/skills/并存。从源码结构看仓库的技能发现逻辑在 codex-rs/core-skills/src/loader/discovery.rs 中实现discover_skills会对技能根目录做受控目录遍历递归模式与直接子目录模式对应不同的扫描深度并带有最大条目数、最大目录数等截断保护随后由 injection.rs 等模块把匹配到的技能内容注入会话上下文。这意味着codex-pr-body的正文本质上是“可被检索、按需加载的规程文本”而不是可执行脚本。第一步确定要更新哪个 PR技能的第一节Determining the PRs规定了目标 PR 的确定方式显式指定调用方直接给出要更新的 PR自动推断常见情况从用户当前所在的分支 / commit 推断。对于普通 Git 使用场景而非后文讨论的 Sapling可能需要组合使用git branch gh pr view branch --repo openai/codex --json number --jq .number即先用git branch拿到当前分支名再用gh pr view按分支查询 GitHub 上对应的 PR通过--json number --jq .number只输出 PR 编号供后续编辑命令使用。这条链路对应技能 description 中 “Update the title and body of one or more pull requests” 的“one or more”——技能并不假设 PR 唯一需要按分支与 PR 的对应关系逐个处理。PR 正文内容规范技能的主体部分“PR Body Contents” 一节是该技能的核心定义了重写 PR 标题与正文时必须遵守的七条规则。下面逐条展开并结合仓库实际写作要求说明其工程意图。1. 用gh编辑且必须先保护既有正文技能要求通过gh编辑 PR 的正文与标题使其反映 PR 的实际内容并且必须先检查现有 PR 正文确认其中有否需要保留的关键信息。文档特别强调了一条“不可逆”约束绝不能删除现有正文中的图片——一旦被删除作者可能没有任何途径恢复它。这是典型的“编辑类 Agent 行为守则”写操作可能不可逆因此规程要求 Agent 在改写前先做保全性读取。2. 先讲“为什么”再讲“改了什么”技能明确规定解释why为什么做这个变更是重中之重如果触发该技能的当前会话中已经讨论过动机必须把动机写进 PR 正文。而what具体改了什么同样必须解释但必须出现在 why 之后。这个顺序约束保证了 PR 描述对评审者是最易读的结构先建立上下文与必要性再展开实现细节。3. 只描述“净变更”删掉开发过程中的弯路技能指出正文应当把讨论限制在 commit 的**净变更net change**范围内在 PR 开发过程中“尝试过后来又撤销”的改动在评审文化中是不受欢迎的。因此重写正文时需要主动剔除这类对后续读者已无意义的细节。这条规则实际是在约束 Agent重写不是把会话历史照搬进 PR而是要做一次面向读者的信息筛选。4. 避免本地绝对路径与内部机密两条“卫生”规则谈论仓库内的路径时一律使用仓库相对路径避免引用作者本地磁盘上的绝对路径这些路径对评审者毫无意义且泄露机器信息避免引用任何机密信息包括但不限于内部代号与公司内部 URL。这与仓库其他技能如 babysit-pr中同样强调的“输出面向公开 PR 场景”一脉相承说明项目把“PR 正文视为准公开文档”作为一条通用准则。5. 如何描述验证方式技能认为讨论“变更是如何被验证的”通常有帮助但给出了明确的边界不要列出 CI 会自动检查的内容例如不要写 “ranjust fmt” 之类的格式化步骤应该指出为验证新行为而特意新增的测试。从项目结构看仓库大量使用基于just的任务编排如 justfile与 Rust 集成测试套件如 codex-rs/core/tests/suite/skills.rs因此“新增测试”在这里有明确的落点而格式化、构建类检查确实由 CI 兜底无需在 PR 正文中重复声明。6. 用 Markdown 把 PR 写得专业技能对正文格式给出了具体指令行内引用“代码事物”时使用单反引号包裹引用代码或展示 shell 会话时使用围栏代码块fenced code blocks引用与本次变更相关的既有代码时使用GitHub permalinks含 commit SHA 的永久链接避免引用漂移的main分支代码。7. 引用相关 PR / Issue但不要自引用正文应引用相关的 PR 或 Issue 以建立关联但无需在 PR 自己的正文里引用它自己。8. 文档站点更新提醒技能还要求如果本次变更意味着开发者文档站点上存在需要同步更新的文档请在 PR 正文靠后的位置单列一个章节说明此事如果没有文档需要更新则省略该章节。这一条把“代码变更 → 文档债务”的联动显式化使文档更新不会淹没在 PR 讨论中。处理 Stacks按整栈净变更来写而不是按单条 commit“Working with Stacks” 一节覆盖两种常见场景场景一commit 栈。一个 PR 可能由多条相互叠加的 commit 组成。此时 PR 正文应反映整个栈引入的净变更而不是逐条描述栈中的各个 commit。这与前文“只写净变更”的规则互为补充粒度从 commit 提升到了 PR。场景二Stacked PRs。用户可能使用 Sapling 等工具实现“堆叠式 PR”——此时某个 PR 的base可能是栈中另一个 PR 的head而不是main。技能明确要求在这种情况下正文只讨论该 PR 的base与head之间的净变更而不是相对于main的变更。换言之正文的作用域必须与 PR 实际 diff 的作用域对齐。Sapling 场景下的 PR 发现sl log与sl sl最后一节Sapling处理 VCS 不再是纯 Git 的情况。Sapling SCM 是 Meta 主导的开源版本控制系统仓库内部文档称其为 Sapling SCM 管理其识别标志是.git/sl/store目录的存在若该目录存在则这个 Git 仓库实际上由 Sapling 治理。在 Sapling 下判断当前 revision 是否关联 GitHub PR 的推荐命令是sl log --template {github_pull_request_url} -r .该命令用模板字段{github_pull_request_url}直接输出当前修订关联的 PR 链接若有关联。另一种方式是运行sl sl查看当前开发分支以及其是否关联 GitHub PR。技能给出了如下示例输出并逐行解读 cb032b31cf 72 minutes ago mbolin #11412 ╭─╯ tui: show non-file layer content in /debug-config │ o fdd0cd1de9 Today at 20:09 origin/main │ ~表示当前 commit 是cb032b31cf它是一个开发分支从origin/main切出仅包含一个 commit该 commit 关联 GitHub PR #11412。把这一节与技能开头的 PR 发现逻辑对照可以看到codex-pr-body对“找到 PR”这件事做了双路径设计普通 Git 走git branchgh pr viewSapling 走sl log/sl sl。这也是该技能相比简单脚本的价值所在——它把多 VCS 工具链下的分支到 PR 的映射规则沉淀成了 Agent 可直接执行的规程。技能如何被加载与执行仓库源码视角的佐证结合项目源码可以进一步理解这类纯规程型技能的运行机制发现阶段codex-rs/core-skills/src/loader/discovery.rs 中的discover_skills遍历技能根目录区分递归与直接子目录两种SkillDiscoveryMode并收集plugin_roots、namespace_roots与告警信息扫描失败或截断时以 warning 形式暴露而不是静默跳过。仓库测试 codex-rs/analytics/src/analytics_client_tests.rs 中出现的.codex/skills/doc/SKILL.md等路径印证了.codex/skills是技能发现链路实际覆盖的目录之一且日志/引用中会被规范化为仓库相对路径——这与codex-pr-body正文中“避免本地绝对路径”的要求在理念上是一致的。选择阶段按 docs/skills.md 的说法Open Interpreter 先读取技能元数据frontmatter仅当请求与description匹配时才加载完整技能内容。codex-pr-body的 description“Update the title and body of one or more pull requests.”因此直接界定了它的触发边界只有当用户表达出更新 PR 标题/正文的意图时整套规程才会被注入。执行阶段codex-pr-body不包含脚本Agent 需自行调用gh、git或sl命令完成查询与编辑。按项目对技能脚本与工具调用的一贯约束这类命令仍会经过正常的沙箱与审批控制技能本身不能也不应依赖绕过权限。作为对照同一目录下的 babysit-pr 技能则带有scripts/gh_pr_watch.py等可执行脚本展示了“规程 脚本”的更重形态而codex-pr-body证明了纯规程型技能在“知识密集、命令简单、判断为主”的场景PR 写作中的适用性。适用前提与实践要点使用该技能需要满足以下前提环境已安装并登录ghCLI能够访问目标仓库技能示例中查询的是openai/codex仓库的 PR实际使用时以当前仓库为准若项目运行在 Sapling 之上需有sl命令可用当前工作目录处于与 PR 对应的分支或 commit 上以便自动推断。从团队实践角度codex-pr-body沉淀出的 PR 写作规范可以脱离 Agent 单独借鉴结构顺序固定为why → what → verification → 文档更新提醒只写净变更删掉过程性弯路路径一律仓库相对机密信息代号、内部 URL一律不出现在正文验证部分只提新增测试不提 CI 兜底项引用既有代码用 permalink引用相关 PR/Issue 但不自引用Stacked PR 场景下正文范围与 PR 的 base/head diff 严格对齐。这套规则把“PR 正文应该长什么样”从个人风格变成了可被 Agent 稳定执行、可被团队统一审查的工程标准也是 Open Interpreter 仓库将自身开发流程 Skill 化的一个典型样本。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
