Gemini CLI 的 pr-address-comments 技能解析把 GitHub PR 评论处理流程变成可复用的 Agent 工作流【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli本文以 Gemini CLI 仓库自带的pr-address-comments工作区技能workspace skill为核心完整还原其“获取 PR 上下文 → 汇总评论状态 → 交由用户决策”的三步处理流程并深入解析其配套脚本 fetch-pr-info.js 的实现细节。读完本文你将理解 Gemini CLI 如何通过 Agent Skills 机制把一个团队协作流程固化为可发现、可激活、可执行的标准工作流并掌握复刻同类“PR 协作技能”的方法。技能定位它解决什么问题pr-address-comments是 Gemini CLI 开发团队放在仓库内部.gemini/skills/pr-address-comments/的一个技能用于帮助用户处理当前分支 Pull Request 上的评论——这些评论可能来自自动化评审机器人也可能来自团队成员。技能的完整定义见 SKILL.md其 YAML frontmatter 声明了触发条件--- name: pr-address-comments description: Use this skill if the user asks you to help them address GitHub PR comments for their current branch of the Gemini CLI. Requires gh CLI tool. ---从描述可以确认两个关键前提作用域针对“当前分支”的 Gemini CLI PR而不是任意仓库的任意分支外部依赖需要本机已安装并登录ghCLIGitHub 官方命令行工具脚本中的所有 GitHub 数据均通过gh获取。技能的目录结构非常精简是一个典型的“指令 确定性脚本”组合.gemini/skills/pr-address-comments/ ├── SKILL.md # 技能说明与处理流程注入给模型的正文 └── scripts/ └── fetch-pr-info.js # 拉取 PR 信息的 Node.js 脚本这种结构的意义在于把“从 GitHub 拉取数据”这类需要确定性结果的操作交给脚本把“理解、归纳、与用户沟通”这类需要推理的操作交给模型各取所长。Agent Skills 机制技能如何被发现与激活理解这个技能之前先了解 Gemini CLI 的 Agent Skills 生命周期详见 docs/cli/skills.md发现Discovery会话开始时CLI 扫描各发现层级把所有已启用技能的name和description注入系统提示词。.gemini/skills/下的技能属于Workspace 层级优先级最高档之一随版本库共享给团队——pr-address-comments正是靠这一机制被仓库内所有协作者自动发现。激活Activation当用户请求匹配技能描述时例如“帮我处理一下这个 PR 的评论”模型调用activate_skill工具。确认ConsentUI 展示技能名称、用途及其将获得访问权限的目录路径等待用户批准。从 activate-skill.ts 的源码可以看到该工具通过getConfirmationDetails返回确认细节getDescription会拼出技能名: 描述供用户判断确认逻辑由消息总线MessageBus驱动。注入Injection批准后SKILL.md正文与目录结构被追加到对话历史技能目录被加入 Agent 的允许文件路径模型因此有权读取scripts/下的脚本。执行Execution模型按照注入的流程指导继续工作。也就是说用户只需要说一句“帮我处理 PR 评论”模型即可在用户授权后获得这份 13 行流程指令 配套脚本的全部权限而无需在每次对话中手工粘贴说明。核心流程三步处理 PR 评论SKILL.md 的正文是写给模型的操作规程目标明确“Help the user review and address comments on their PR.”帮助用户评审并处理 PR 上的评论。其流程共三步每一步都有严格的约束第 1 步运行 fetch-pr-info.js 获取 PR 全量上下文原文要求运行scripts/fetch-pr-info.js获取 PR 信息与状态即使输出被截断也必须完整读取整个输出。这条约束是实战经验的直接体现脚本一次性输出 diff、提交日志、全部评论信息量可能超出单次工具调用的展示上限如果模型只看了截断后的前段就开始分析会漏掉后半段的评论线程。因此指令强制要求模型分页/滚动读完整输出才能进入归纳环节。第 2 步交叉比对归纳评论状态模型需要同时分析 diff、提交日志和评论判断每条评论是否已经在新提交的代码中被解决例如评审人指出第 40 行有问题而 diff 显示该行已修改并按统一格式输出汇总已解决resolved的线程压缩为一行以 ✅ 标记未解决open的线程赋予引用编号如[1]并附上评论内容方便用户后续指代。特别注意指令中要求的“Pay attention to the current users comments”——即优先关注当前用户本人的评论比如自己在 PR 上留下的待办性评论这决定了汇总的重点排序。第 3 步呈现汇总等待用户决策原文要求呈现反馈与当前状态的汇总由用户决定“修哪些 / 处理哪些 / 跳过哪些”。不要自动开始修复DO NOT begin fixing issues automatically。这是整个技能最重要的安全护栏技能的价值止于“信息整理与决策支持”实际改代码的启动权交还给人。这种 human-in-the-loop 设计避免了 Agent 在未确认的情况下批量改动评审意见对应的代码。脚本深度解析fetch-pr-info.js 如何一次性喂饱模型fetch-pr-info.js 是整个技能的数据底座全文约 160 行纯 Node.js 实现仅依赖node:child_process与node:util无第三方包值得逐段拆解。统一封装的 shell 调用run()脚本顶部封装了一个容错的run()函数第 16–26 行async function run(cmd) { try { const { stdout } await execAsync(cmd, { encoding: utf8, stdio: [pipe, pipe, ignore], // 丢弃 stderr }); return stdout.trim(); } catch { return null; // 命令失败时返回 null由调用方判空 } }两个设计点stdio第三个位置设为ignore避免各命令的 stderr 噪声污染输出失败时返回null而非抛错把“哪个数据源失败”的决策留给上层逻辑。四路并发数据采集main()首先确认当前 git 分支拿不到直接以退出码 1 结束随后用Promise.all并发执行四个数据源第 48–55 行数据源命令用途GitHub 身份gh auth status -a确认当前操作者“current users comments”的判定基准PR diffgh pr diff判断评论是否已被最新代码修复提交历史git fetch git log origin/main..origin/branch了解分支上已有哪些提交辅助判断评论状态PR 元数据gh api graphql -F branch... -f query...拉取评论、评审、线程结构注意提交历史用的是origin/main..origin/branch区间并先git fetch保证比较基准是远端最新的 main而不是本地可能落后的引用。若gh pr diff返回空脚本判定当前分支没有活跃 PR 并退出——这与技能“面向当前分支 PR”的定位一致。GraphQL 查询精确圈定要哪些字段脚本内嵌的 GraphQL 查询第 46 行结构如下repository(name: gemini-cli, owner: google-gemini) └── pullRequests(headRefName: $branch, first: 100) ├── state ├── comments(first: 100) # PR 级通用评论 │ └── createdAt, isMinimized, minimizedReason, author, body, url, authorAssociation └── reviews(first: 100) # 评审及行内评论 ├── state, author, createdAt, body └── comments(first: 30) └── replyTo{id}, path, line, startLine, originalLine, originalStartLine几个值得注意的点按 head 分支反查 PRheadRefName: $branch让脚本无需用户提供 PR 编号即可定位 PR分页上限显式化PR、通用评论各取 100 条每个 review 的行内评论取 30 条——对单条 PR 足够且避免无界拉取replyTo{id}是关键行内评论的replyTo字段是后续构建“线程树”的依据originalLine/originalStartLineGitHub 在代码行被后续 push 修改后会让line失效originalLine提供定位兜底脚本在输出行号时做了c.startLine || c.originalStartLine的降级处理。需要说明的限制查询中owner: google-gemini、name: gemini-cli是硬编码的因此这个脚本只适用于 Gemini CLI 仓库本身。这是它与技能描述中“for their current branch of the Gemini CLI”完全对应的——它是一个仓库专属的工作区技能而非通用 PR 工具。噪声过滤IGNORE_MESSAGES 白名单评审机器人会产生大量模板化留言脚本用一个精确匹配表把它们从输出中剔除第 28–37 行const IGNORE_MESSAGES [ thank you so much for your contribution to Gemini CLI!, Im currently reviewing this pull request and will post my feedback shortly., This pull request is being closed because it is not currently linked to an issue., ];被过滤的是致谢、评审进度提示、关闭通知这类“流程性”留言。用body.includes(msg)做包含匹配而非全等匹配可以容忍模板前后附加内容。这个过滤对模型侧同样重要减少无信息量的输入降低“把机器人寒暄当成待处理评论”的概率。输出结构为 LLM 阅读优化的分段排版脚本的最终输出分为四个 Markdown 式区块顺序即模型消费顺序# Current GitHub user infogh auth status -a的结果用于识别“当前用户是谁”# PR diff for current branch: branch完整 diff包在代码围栏内# Commit history (origin/main..origin/branch)提交日志# PR Feedback分三个子块——General Comments过滤后的 PR 级评论每条标注[时间] [作者]被最小化minimized的评论会附(Minimized: 原因)Review 摘要每个有正文的评审一行呈现APPROVED状态用 ✅ 前缀其余用 Code Reviews Inline Threads先输出所有评审摘要再重建行内评论线程。线程重建逻辑是脚本的精华第 120–152 行const topLevelThreads filteredInlines.filter((c) !c.replyTo); const printThread (parentId, depth 1) { const indent .repeat(depth); filteredInlines .filter((c) c.replyTo?.id parentId) .forEach((reply) { console.log(${indent}↳ [${reply.createdAt}] ${reply.author.login}${minimized}: ${reply.body}); printThread(reply.id, depth 1); // 递归打印更深层回复 }); };以replyTo为边把扁平的评论列表还原成带缩进的树形线程顶层评论打印作者 | 时间 | (文件路径:行号范围)定位信息其下所有回复以↳加两格递增缩进递归展开。行号范围按startLine/line计算起止不同则输出start-end区间否则只输出单行号。这样模型和用户看到的不再是离散的评论碎片而是“某个文件某几行处的一整段讨论”与 SKILL.md 第 2 步“按线程归纳状态”的要求严丝合缝。失败路径一览脚本对三种失败情形都有显式出口全部process.exit(1)并在 stderr 给出可读原因无法确定当前 git 分支detached HEAD 等非分支状态gh pr diff为空当前分支无活跃 PR或未登录ghGraphQL 结果中找不到 PR 节点。这些“快速失败”很重要技能第 1 步之后的一切归纳都建立在完整数据之上数据缺失时直接终止比让模型基于残缺输出猜测要安全得多。流程设计哲学值得借鉴的三点这个技能虽然只有 13 行指令但体现了三条在 Agent 技能设计中普遍适用的原则确定性数据交给脚本模糊判断交给模型。拉 diff、解析 GraphQL、重建线程树这些用代码做是稳定且可重复的而“这条评论是否已被新提交解决”需要理解代码语义交给模型交叉比对。脚本输出的排版分段标题、线程缩进、行号定位本身就是为下游 LLM 消费设计的。强制完整性读取。第 1 步的“即使截断也要读完整个输出”是对长工具输出的显式防御属于把已知失败模式写进规程的典型案例。决策权留在人手里。“DO NOT begin fixing issues automatically”把 Agent 的角色锚定在“分析与建议”执行动作必须经用户逐条确认——这与仓库中其他协作技能形成呼应pr-creator 负责按模板创建 PR并强调“绝不 push 到 main”async-pr-review 处理异步评审pr-address-comments则专注“收到反馈之后”的环节三者覆盖了 PR 生命周期中可自动化的不同切面。如何复刻一个类似的协作技能如果你想在自己的团队仓库中做一个“PR 协作”类技能可以参照本技能的结构与 创建技能指南mkdir -p .gemini/skills/my-skill/scripts建立工作区技能目录在SKILL.md中写清 frontmattername 描述触发场景和分步流程用明确的 MUST/DO NOT 句式划定模型行为边界例如“先汇总、后等指令、不自动修改”把需要确定性结果的部分数据拉取、格式化写成scripts/下的自包含脚本失败时显式exit(1)提交到仓库后技能即随.gemini/skills/工作区层级对全团队生效用/skills list或gemini skills list --all验证是否被发现见 skills 文档。最后再次强调适用前提pr-address-comments的脚本硬编码了google-gemini/gemini-cli仓库并依赖已登录的ghCLI 与可用的git fetch直接复用其流程模板是合理的直接运行其脚本则仅在本仓库内有效。【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考