使用 awesome-codex-skills 中的 pr-review-ci-fix：基于 Composio CLI 的 GitHub/GitLab PR 审查与 CI 自动修复循环

使用 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 gitlab

• composio login会打开浏览器完成认证，并可选择默认组织和项目；在自动化流程中可加-y跳过交互提示（此细节可参考 connect/SKILL.md 的 Setup 小节）。
• composio link github/composio link gitlab各执行一次 OAuth，之后连接会持久化，后续调用无需重复授权。
• 非交互式运行（例如 CI 或定时任务）时，可设置环境变量COMPOSIO_API_KEY作为认证凭据。

三、核心工具集：用 search 发现 slug，用 schema 确认入参

Composio CLI 以「工具 slug（tool 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	用途
GitHub	GITHUB_GET_A_PULL_REQUEST	拉取 PR 元数据与详情
GitHub	GITHUB_LIST_PULL_REQUESTS_FILES	列出 PR 变更文件列表（即 diff 文件清单）
GitHub	GITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST	为 PR 创建含行内评论的审查
GitHub	GITHUB_LIST_WORKFLOW_RUNS_FOR_A_REPOSITORY	查询仓库的工作流运行记录
GitHub	GITHUB_DOWNLOAD_WORKFLOW_RUN_LOGS	下载工作流运行日志
GitLab	GITLAB_GET_SINGLE_MERGE_REQUEST	获取单个合并请求（MR）
GitLab	GITLAB_LIST_MERGE_REQUEST_DISCUSSIONS	列出 MR 的讨论线程
GitLab	GITLAB_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）：是否向后兼容、是否有破坏性变更；
• 公共 API（public 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 步重新轮询，直到返回的conclusion=success。这是一个标准的「拉取状态 → 判定 → 循环」模式，注意设置合理的轮询频率以规避 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.ts：

const 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的命名空间路径）而非owner+repo两个字段；
• 请求对象：GitLab 的合并请求用merge_request_iid（iid 为项目内的自增编号），对应 GitHub 的pull_number；
• 评论动作：GitLab 对应GITLAB_CREATE_NEW_MERGE_REQUEST_NOTE，评论正文同样放在body字段。

其余工作流（拉取讨论、解析失败日志、本地修复、推送重跑）完全复用 GitHub 侧的流程。

八、故障排查速查表

原文档在 Troubleshooting 小节给出了四条高频问题的处置方案，整理如下：

报错 / 场景	处置方式
Connection required for github	执行composio link github（GitLab 同理换成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 小节），适合日志等大体积响应的流式处理场景。

九、完整实战链路回顾

将全文串起来，一个端到端的典型会话是：

1. composio link github确认连接就绪；
2. composio execute GITHUB_GET_A_PULL_REQUEST+GITHUB_LIST_PULL_REQUESTS_FILES拉取 PR 元数据与 diff；
3. Agent 汇总 auth / migrations / public APIs / tests 风险，用GITHUB_CREATE_A_REVIEW_FOR_A_PULL_REQUEST发表含行内评论的审查；
4. 若 CI 失败，用GITHUB_LIST_WORKFLOW_RUNS_FOR_A_REPOSITORY（status:"failure"）定位失败运行，再用GITHUB_DOWNLOAD_WORKFLOW_RUN_LOGS拉取日志；
5. Agent 解析日志、本地打补丁，git commit && git push后回到第 4 步轮询，直至conclusion=success；
6. 最后用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