使用 awesome-codex-skills 中的 pr-review-ci-fix基于 Composio CLI 的 GitHub/GitLab PR 审查与 CI 自动修复循环【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills导读本文围绕 pr-review-ci-fix/SKILL.md 展开讲解如何在终端中借助 Composio CLI把「拉取 PR diff → 结构化审查并发表行内评论 → 读取失败 CI 日志 → 本地打补丁 → 推送修复提交 → 重跑检查」这一整套循环交给 Agent 自动完成。读完本文你将掌握 GitHub/GitLab 双平台的工具 slug 选用、composio execute的参数构造、一键式工作流脚本的写法以及常见报错的排查方法能够在浏览器、终端与聊天窗口之间零切换的情况下完成 PR 审查和 CI 故障处置。一、技能定位与适用场景在仓库中该技能被归类于「Development Code Tools」README 的描述是「Automated GitHub/GitLab PR review plus CI auto-fix loop via the Composio CLI」见 README.md 的 Skills 目录。它依托仓库内另一套通用连接技能 connect/SKILL.md 所建立的 Composio 连接体系把「真实执行动作」的能力接入 Codex Agent。适用场景非常聚焦一个 PR 需要结构化审查正确性、代码风格、潜在风险并要求以行内评论的形式输出结论CI 变红希望 Agent 读取构建日志、修复代码并重新验证希望用一条命令闭环走完fetch diff → critique → fix → push → rerun的完整循环。文档明确强调的卖点是no tab-switching——不再需要在浏览器、终端和聊天窗口之间来回切换所有操作都在 shell 中完成。二、前置准备安装、登录与连接技能的前置条件非常轻量只需要三步对应原文档 Prereqs 小节curl -fsSL https://composio.dev/install | bash composio login composio link github # or: composio link gitlabcomposio login会打开浏览器完成认证并可选择默认组织和项目在自动化流程中可加-y跳过交互提示此细节可参考 connect/SKILL.md 的 Setup 小节。composio link github/composio link gitlab各执行一次 OAuth之后连接会持久化后续调用无需重复授权。非交互式运行例如 CI 或定时任务时可设置环境变量COMPOSIO_API_KEY作为认证凭据。三、核心工具集用 search 发现 slug用 schema 确认入参Composio CLI 以「工具 slugtool slug」为调用单元。技能给出的发现方式是先搜索、后锁定复用composio search list pull request files --toolkits github composio search download workflow logs --toolkits github composio search create pr comment --toolkits gitlab--toolkits参数用于限定搜索范围避免在海量集成中大海捞针。常用 slug 清单如下原文档 Core Toolkits 小节平台slug用途GitHubGITHUB_GET_A_PULL_REQUEST拉取 PR 元数据与详情GitHubGITHUB_LIST_PULL_REQUESTS_FILES列出 PR 变更文件列表即 diff 文件清单GitHubGITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST为 PR 创建含行内评论的审查GitHubGITHUB_LIST_WORKFLOW_RUNS_FOR_A_REPOSITORY查询仓库的工作流运行记录GitHubGITHUB_DOWNLOAD_WORKFLOW_RUN_LOGS下载工作流运行日志GitLabGITLAB_GET_SINGLE_MERGE_REQUEST获取单个合并请求MRGitLabGITLAB_LIST_MERGE_REQUEST_DISCUSSIONS列出 MR 的讨论线程GitLabGITLAB_CREATE_NEW_MERGE_REQUEST_NOTE在 MR 上新建评论重要实践每次首次使用某个 slug 前务必执行composio execute SLUG --get-schema确认其输入结构。--get-schema会返回该工具期望的 JSON 入参形状是避免 Unknown input shape 报错的关键防线。这与 connect/SKILL.md 中「不清楚入参 →--get-schema或--dry-run」的工作流一脉相承。四、Review 工作流拉取 diff、汇总风险、发表行内评论这是技能的核心实操部分分为三步对应原文档 Review Workflow 小节。第 1 步拉取 PR 元数据与变更文件composio execute GITHUB_GET_A_PULL_REQUEST \ -d {owner:acme,repo:app,pull_number:482} composio execute GITHUB_LIST_PULL_REQUESTS_FILES \ -d {owner:acme,repo:app,pull_number:482}-d后面是 JSON 字符串形式的工具入参owner为仓库所属组织/用户repo为仓库名pull_number为 PR 编号。第一条返回 PR 的整体元数据标题、作者、状态、合并信息等第二条返回本次 PR 涉及的全部变更文件供 Agent 判断影响面。第 2 步汇总风险区域Agent 基于变更文件清单将注意力集中在高风险区域并归纳成审查意见技能明确点名的关注点包括认证与授权auth会话校验、令牌过期、权限边界数据库迁移migrations是否向后兼容、是否有破坏性变更公共 APIpublic APIs签名变更、语义变更对调用方的影响测试tests新逻辑是否有对应测试覆盖。第 3 步发表带行内评论的审查composio execute GITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST -d { owner:acme,repo:app,pull_number:482, event:COMMENT, body:Overall LGTM with 2 blocking notes., comments:[ {path:src/auth.ts,line:42,body:Missing null check on session}, {path:src/auth.ts,line:88,body:Token TTL is hardcoded; move to config} ] }入参要点event审查结论类型COMMENT表示一般性评论GitHub 还支持APPROVE、REQUEST_CHANGES等枚举值body审查总体意见例如 Overall LGTM with 2 blocking notes.comments行内评论数组每个元素包含path文件路径、line行号、body评论正文。这样一次调用就能把总体结论与精确到行的点评一次性提交到 PR 上。五、CI Auto-Fix 循环从红到绿的五步闭环当 CI 失败时技能给出了一条可反复执行的修复循环对应原文档 CI Auto-Fix Loop 小节。第 1 步定位失败的工作流运行composio execute GITHUB_LIST_WORKFLOW_RUNS_FOR_A_REPOSITORY \ -d {owner:acme,repo:app,branch:feat/billing,status:failure}通过branch限定到当前开发分支如feat/billing通过status过滤出failure状态的运行记录从返回结果中拿到失败运行的run_id。第 2 步拉取运行日志composio execute GITHUB_DOWNLOAD_WORKFLOW_RUN_LOGS \ -d {owner:acme,repo:app,run_id:123456}以run_id为入参下载该次运行的全部日志作为后续错误解析的原始素材。第 3 步解析失败原因并在本地打补丁Agent 阅读日志定位真正的失败原因编译错误、测试断言失败、lint 违规等直接在本地工作区修改代码。这一步是 Agent 的「思考与动手」阶段技能不预设具体修复手段而是把决策权交给 Agent。第 4 步提交、推送、重跑检查通过本地git完成 commit 与 push然后回到第 1 步重新轮询直到返回的conclusionsuccess。这是一个标准的「拉取状态 → 判定 → 循环」模式注意设置合理的轮询频率以规避 API 限流。第 5 步为每个修复提交发表说明评论修复全部落地后在 PR 上补充一条评论逐条描述每个修复 commit 做了什么让人类 reviewer 能快速理解自动修复的意图而不是面对一堆来历不明的提交。这一「读日志 → 修复 → 重跑」的心智模型与仓库中另一个技能 gh-fix-ci/SKILL.md 的inspect_pr_checks.py脚本拉取失败检查、抽取失败摘要、以非零退出码供自动化判断互为补充前者基于gh与 GitHub Actions 原生接口后者则通过 Composio 打通 GitHub/GitLab 双平台。六、一键式工作流文件composio run --file循环操作可以通过脚本固化为一条命令对应原文档 One-Shot Workflow File 小节。将以下内容保存为scripts/review-and-fix.tsconst pr process.argv.includes(--pr) ? Number(process.argv[process.argv.indexOf(--pr) 1]) : null; const meta await execute(GITHUB_GET_A_PULL_REQUEST, { owner: acme, repo: app, pull_number: pr }); const files await execute(GITHUB_LIST_PULL_REQUESTS_FILES, { owner: acme, repo: app, pull_number: pr }); console.log(JSON.stringify({ meta, files }, null, 2));运行方式composio run --file ./scripts/review-and-fix.ts -- --pr 482要点解读脚本通过process.argv解析--pr之后的参数作为 PR 编号--之后的内容会透传给工作流脚本脚本内直接使用await execute(SLUG, {...})调用工具与命令行-d传入的 JSON 一一对应输出为结构化 JSON方便后续环节如总结摘要、拼接评论继续消费。这种「用文件固化工作流」的方式也是 connect/SKILL.md 中composio run --file ./workflow.ts的通用能力在该场景下的具体应用——把多步、可复用的流程从命令行提升为版本化的脚本资产。七、GitLab 变体换 slug 与参数名同一套思路迁移到 GitLab 只需替换 slug 和参数命名对应原文档 GitLab Variant 小节composio execute GITLAB_GET_SINGLE_MERGE_REQUEST \ -d {id:acme/app,merge_request_iid:482} composio execute GITLAB_CREATE_NEW_MERGE_REQUEST_NOTE \ -d {id:acme/app,merge_request_iid:482,body:CI fix pushed as commit deadbeef}差异点明确仓库标识GitLab 使用id形如acme/app的命名空间路径而非ownerrepo两个字段请求对象GitLab 的合并请求用merge_request_iidiid 为项目内的自增编号对应 GitHub 的pull_number评论动作GitLab 对应GITLAB_CREATE_NEW_MERGE_REQUEST_NOTE评论正文同样放在body字段。其余工作流拉取讨论、解析失败日志、本地修复、推送重跑完全复用 GitHub 侧的流程。八、故障排查速查表原文档在 Troubleshooting 小节给出了四条高频问题的处置方案整理如下报错 / 场景处置方式Connection required for github执行composio link githubGitLab 同理换成composio link gitlab重新建立连接Unknown input shape执行composio execute SLUG --get-schema查看该工具期望的输入结构日志下载体积过大通过composio proxy直连原始 API 流式获取并在本地用grep过滤关键信息触发 API 限流串行化调用、降低轮询频率对同一仓库避免使用--parallel并发请求其中composio proxy是「无专用工具时的兜底通道」可携带指定 toolkit 的认证直连原始 REST 端点配合-X、-H、-d等参数完成自定义请求详见 connect/SKILL.md 的 Raw API Access 小节适合日志等大体积响应的流式处理场景。九、完整实战链路回顾将全文串起来一个端到端的典型会话是composio link github确认连接就绪composio execute GITHUB_GET_A_PULL_REQUESTGITHUB_LIST_PULL_REQUESTS_FILES拉取 PR 元数据与 diffAgent 汇总 auth / migrations / public APIs / tests 风险用GITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST发表含行内评论的审查若 CI 失败用GITHUB_LIST_WORKFLOW_RUNS_FOR_A_REPOSITORYstatus:failure定位失败运行再用GITHUB_DOWNLOAD_WORKFLOW_RUN_LOGS拉取日志Agent 解析日志、本地打补丁git commit git push后回到第 4 步轮询直至conclusionsuccess最后用GITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST或 GitLab 的GITLAB_CREATE_NEW_MERGE_REQUEST_NOTE说明每个修复提交。这套链路也正是 README.md 将 pr-review-ci-fix 列入开发工具类的依据——它把「审查」与「修复」两个高频但割裂的动作收敛成 Agent 在终端中可独立闭环的单一技能。说明本文所有命令与参数均以 pr-review-ci-fix/SKILL.md 原文为基准并结合仓库内 connect/SKILL.md、gh-fix-ci/SKILL.md 等相邻技能文档交叉印证--get-schema确认入参、composio run --file固化流程、composio proxy处理大响应等最佳实践均可在上述文档与 CLI 帮助中进一步验证。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考