桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载pr-comments是 Warpagentic development environment源自终端随仓库捆绑分发的一个 Agent Skill用于把当前分支所对应 GitHub PR 上的全部评审评论PR 级评论、行内 diff 评论、Review 总结一次性拉取下来并通过insert_code_review_comments工具以结构化方式展示给用户。本文以 SKILL.md 为骨架结合其配套 Python 脚本与仓库内代码评审模块的源码实现完整讲解该 Skill 的用法、脚本处理逻辑、备用gh命令回退方案以及 Agent 在展示评论时应遵循的交互边界。读完本文你可以直接在自己的 Warp 工作流中运行该 Skill也能理解行号解析、diff 裁剪与 fork PR 归属解析等底层细节。一、Skill 定位与适用场景pr-commentsSkill 的定位在它的 frontmatter 中写得非常明确Fetch and display GitHub PR review comments for the current branch。它只做一件事——获取并展示不做任何代码改动也不替用户回复评论。它的使用前提有两个当前目录必须在某个 git 仓库内git rev-parse --show-toplevel能成功当前分支必须已有一个打开的 PRopen PR。适用场景典型如下你正在 Warp 中处理一个分支Agent 需要了解该 PR 上评审者留下的反馈从而在后续对话中围绕这些评论展开讨论。Skill 把评论从 GitHub 拉到本地上下文且通过工具调用而非直接朗读呈现保证内容不截断、结构可解析。二、快速上手两步骤调用流程SKILL.md 定义的标准 Procedure 只有两个步骤随后进入等待用户指示状态。步骤 1运行捆绑脚本获取 JSON必须位于一个有打开 PR 的 git 仓库内然后执行python3 {{skill_dir}}/scripts/fetch_github_review_comments.py其中{{skill_dir}}是 Skill 运行时注入的占位符实际对应仓库中的 scripts 目录。文档特别强调运行该 shell 命令时要带上do_not_summarize_output: true确保 JSON 输出不被摘要截断。脚本会把结构化 JSON 打印到 stdout。如果脚本获取失败则改用文末给出的gh命令回退方案见第四节。步骤 2调用insert_code_review_comments展示从 JSON 输出中取出三个顶层字段原样传入工具local_repository_pathbase_branchcomments即脚本输出的结果对象{ local_repository_path: /path/to/repo, base_branch: main, comments: [ /* 见下文各类型评论结构 */ ] }步骤 3停止并等待用户展示完每一批评论后Agent必须询问用户希望如何处理在用户给出明确指示前不得采取任何后续动作。Skill 原文的约束非常强硬不得因为拉取到的评论而擅自修改代码不得冒充用户提交 review 回复该 Skill 的角色是纯信息性的——呈现评论、等待指令。这个交互边界在仓库的遥测代码中也有印证telemetry_event.rs 专门记录了 Agent insert_code_review_comments tool call received and processed 这一事件说明该工具调用是产品内一条被显式追踪的用户可见流程。三、脚本做了什么三类评论的归一化处理fetch_github_review_comments.py 是整个 Skill 的核心执行体。它通过gh api --paginate依次拉取三类数据并把它们统一成insert_code_review_comments的评论 schema数据来源GitHub 端点元数据Issue commentsPR 级评论/repos/{owner}/{repo}/issues/{number}/comments无 location、无 reply 元数据Diff comments行内/文件级评论/repos/{owner}/{repo}/pulls/{number}/comments顶层评论带location_metadata回复评论带reply_metadataReviews代码评审总结/repos/{owner}/{repo}/pulls/{number}/reviews无 location 元数据仅保留非空 body每一条评论最终被构造成统一的字典结构见_comment函数{ comment_id: cid, author: author, # user.login用户已删除时为 [deleted] last_modified_timestamp: ts, # updated_at comment_body: body, html_url: url, # 二选一 # reply_metadata: {parent_comment_id: ...} # location_metadata: {filepath, diff_hunk, end_line, start_line?, side} }3.1 评论的分类与元数据策略PR 级评论issue comments 与 reviews既没有 location 也没有 reply 元数据。Review 还会过滤掉body为空或为 null 的条目。行内 diff 评论通过in_reply_to_id区分回复与顶层评论。回复评论只保留reply_metadataparent_comment_id不携带 diff hunks 与位置信息顶层评论则生成location_metadata包含文件路径、裁剪后的 diff hunk、行号与 side。3.2 行号解析的回退链源码级细节这是脚本里最有价值的健壮性逻辑之一。GitHub 返回的line字段在 diff 更新后可能已经过期不再落在这个 hunk 的区间内因此_resolve_line采用了一条回退链line当前 diff 位置→ original_line评论放置时的原始位置→ hunk 内最后可达行 → None对应的_resolve_comment_line还会处理起始行若start_line/original_start_line解析出的值大于end_line区间反转则把start_line置为None避免产生非法区间。side 默认取 API 返回的side缺省时按RIGHT处理。这些边界行为在 test_fetch_comments.py 中有完整的单测覆盖包括line命中 hunk → 直接使用line失效但original_line命中 → 回退到原始行两者都失效 → 回退到 hunk 内最后可达行纯删除 hunk新文件侧无行→ 返回None区间反转场景 →start_line被清空含 LEFT/RIGHT 两侧的回归用例。其中还包含一个真实回归用例PR #22932 的过期评论line2899但 hunk 在3066验证回退到 hunk 最后可达行3071的行为——这说明该逻辑是经过真实线上事故打磨过的。3.3 大 diff hunk 裁剪顶层 diff 评论会附带diff_hunk脚本会用 trim_diff_hunk.py 中的trim_diff_hunk把它裁剪到目标行附近的一个窗口避免把巨大的 diff 上下文全部塞进上下文。裁剪遵循三条原则只从开头和结尾裁剪绝不动中间内容目标行及其start_line如果存在周围的context_lines默认 0保留hunk 头部 -a,b c,d 会被重写保证裁剪后的行号依旧正确。该脚本的模块注释明确说明它mirrors the logic in diff_hunk_parser.rs即 Python 侧裁剪逻辑与 Rust 侧代码评审模块保持双端一致裁剪后的 JSON 能被 App 端直接消费。3.4 fork PR 的正确归属base repo 解析脚本通过base_repo_from_url从 PR 的url字段解析{owner}/{repo}而不是用当前 git remote 推断。注释与测试都强调了一个关键点PR 的评论存放在 base 仓库拥有 PR 的仓库上即使 PR 是从 fork 打开的也必须向 base 仓库请求否则端点会 404。# https://github.com/warpdotdev/warp/pull/9850fork 打开 # → (warpdotdev, warp)而非 fork 的 th1nkful/warptest_fetch_comments.py 中TestBaseRepoFromUrl覆盖了三种情况同仓库 PR、fork 打开的 PR、企业版 GitHubghe.example.com/acme/widgets/pull/42保证该逻辑跨环境成立。3.5 分页 JSON 的稳健解析gh api --paginate可能输出多个首尾相接的 JSON 数组run_gh_api用json.JSONDecoder从任意位置持续raw_decode把多页结果合并成一个列表——这样就不会因为只有第一页而漏掉大量评论。四、脚本失败时的备用方案直接调用 gh APISKILL.md 为脚本失败提供了完整的降级路径分 5 步定位 PR 与 base 仓库用gh pr view拿到number、url、baseRefName从 PR 的url解析{owner_login}/{repo_name}同样是 base 仓库fork 场景不 404PR 级评论GET /repos/{owner_login}/{repo_name}/issues/{pr_number}/comments行内/文件级评论GET /repos/{owner_login}/{repo_name}/pulls/{pr_number}/comments并从 thread 回复中删除 location 元数据与 diff hunksReview 评论GET /repos/{owner_login}/{repo_name}/pulls/{pr_number}/reviews过滤出有评论文本的条目调用insert_code_review_comments包含全部 PR、review、文件级、行级评论若 PR 上没有评论则传入空列表。不得跳过工具直接朗读评论内容。操作时必须清空GH_PAGER环境变量防止gh进入分页器阻塞非交互环境。SKILL.md 给出了 macOS/zsh 的完整示例Linux/bash 同理按系统 shell 适配即可$ GH_PAGER gh pr view --json number,url,baseRefName $ GH_PAGER gh api /repos/{owner_login}/{repo_name}/issues/{pr_number}/comments --jq .[] | {id, html_url, user_login: .user.login, body, created_at, updated_at} $ GH_PAGER gh api /repos/{owner_login}/{repo_name}/pulls/{pr_number}/comments --jq .[] | {id, html_url, diff_hunk, path, user_login: .user.login, body, created_at, updated_at, start_line, original_start_line, start_side, line, original_line, side, in_reply_to_id, subject_type} | if .in_reply_to_id ! null then del(.diff_hunk, .path, .line, .original_line, .start_line, .original_start_line, .side, .start_side, .subject_type) else . end $ GH_PAGER gh api /repos/{owner_login}/{repo_name}/pulls/{pr_number}/reviews --jq .[] | {id, html_url, user_login: .user.login, body, created_at, updated_at} | select(.body ! and .body ! null)注意第三条命令的 jq 技巧if .in_reply_to_id ! null then del(...)会在回复评论上删除位置相关字段与脚本中回复评论不带 location 元数据的规则完全一致。降级完成后同样回到停止并等待用户的步骤。五、输出侧insert_code_review_comments 在 App 端的落点从 App 端源码看insert_code_review_comments并非孤立存在而是与代码评审功能深度集成diff_state/local.rs 注释明确该状态是 intended for theinsert_code_review_commentsflow说明工具调用会把评论写入本地 diff 状态telemetry_event.rs 在工具调用被接收并处理时发出对应遥测事件用于追踪该流程的可用性。因此Skill 侧产出的 JSON schemalocal_repository_path、base_branch、comments及各元数据字段需要与 App 端消费逻辑精确对齐——这正是 Python 脚本中_comment函数严格按 schema 构造字段的原因也是 trim_diff_hunk.py 与 Rust 侧 diff_hunk_parser.rs 保持镜像一致的原因。六、环境要求与注意事项SKILL.md 的 Requirements 一节给出了运行该 Skill 的最少条件ghCLI 已安装并完成认证gh auth具有仓库读取权限当前分支存在打开的 PR位于 git 仓库内脚本通过git rev-parse --show-toplevel定位仓库根目录并写入local_repository_path。另外几点使用注意若gh未认证或 PR 不存在脚本会在 stderr 打印错误并以非零码退出此时应转入第四节的gh命令降级流程评论展示阶段保持只读不要在用户明确指示前基于评论改代码、回帖或执行其他动作do_not_summarize_output: true是必须项否则长 JSON 可能被摘要破坏导致后续工具调用拿到残缺数据。七、总结pr-commentsSkill 用约 70 行规则加两个 Python 模块把拉取 GitHub PR 评审评论这件高频琐事封装成了 Agent 可执行的标准化流程脚本负责分页拉取、行号回退解析、diff 裁剪与 fork 归属处理insert_code_review_comments负责结构化展示SKILL.md 则用硬性约束确保 Agent 始终停留在信息提供者的角色上。其 Python 实现与仓库 code_review 模块的 Rust 逻辑diff 解析、本地状态、遥测保持对齐既有独立可运行的脚本也有 App 端的完整承接链路是一份可直接复用的 Agent Skill 工程范本。赞分享桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载相关推荐Cline 的 PR 评论处理工作流用 address-pr-comments 规则自动化 GitHub PR 评论闭环Cline 的 PR 评论处理工作流用 address pr comments 规则自动化 GitHub PR 评论闭环 本篇技术指南聚焦 Cline 仓库中人工智能AI Agent代码智能体AI 应用开发工具MCP Clients用 ForgeCode 的 github-pr-comments 技能系统化解决 GitHub PR 评审意见用 ForgeCode 的 github pr comments 技能系统化解决 GitHub PR 评审意见 本文围绕 ForgeCodeforgecode人工智能AI Agent代码智能体AI 应用CLI开发工具大麦 App 自动抢票Appium 驱动下的部署与调优指南大麦 App 自动抢票Appium 驱动下的部署与调优指南 ticket purchase 是一款基于 Appium 的大麦网自动化购票工具可监控目标场次余GUI 自动化RPA创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考