尧图网站建设 
rtk pr-triage 技能详解基于 gh CLI 的三阶段 GitHub PR 自动审计、深度评审与评论发布工作流【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文以 rtk 仓库中的 Claude Code 技能定义文件 .claude/skills/pr-triage/SKILL.md 为核心完整解读其「审计 → 深度评审 → 评论发布」三阶段 PR 分诊triage工作流。读完本文你将掌握如何用ghCLI 命令并行采集 PR 元数据、按尺寸/重叠/陈旧度规则自动分类 PR、并行调度code-reviewer子代理进行深度代码评审以及如何通过强制人工校验安全地把结构化评审意见发布到 GitHub并了解该评审检查清单如何与 rtk 源码中LazyLockRegex、token 节省断言、退出码传播等真实约束一一对应。技能定位与触发方式pr-triage是 rtk 项目内嵌于 SKILL.md 中的一个 Claude Code 技能Skill。技能头部元数据声明了它的核心契约name: pr-triage description: PR triage: audit open PRs, deep review selected ones, draft and post review comments. Args: all to review all, PR numbers to focus (e.g. 42 57), en/fr for language, no arg audit only in French. allowed-tools: - Bash - Read - Grep - Glob effort: medium tags: [triage, pr, github, review, code-review, rtk]功能定位审计打开的 PR、对选定 PR 做深度评审、起草并经校验后发布评审评论。权限边界仅授予Bash、Read、Grep、Glob四类工具effort: medium意味着技能以中等推理预算运行不做无限制展开。参数语义all表示评审全部外部 PRPR 编号列表如42 57表示只聚焦指定 PRen/fr控制输出语言不带参数则仅执行审计且默认法语输出。它与仓库中另一个技能 repo-recap 的分工在文档中明确列出Skill用途输出/pr-triage分诊、评审、评论 PR行动表格 reviews 已发布的评论/repo-recap供团队分享的整体仓库回顾Markdown 摘要PRs issues releases触发条件分两类手动/pr-triage、/pr-triage all、/pr-triage 42 57主动proactive当存在超过 5 个未评审的打开 PR或检测到某个 PR 已超过 14 天无活动stale时。语言规则技能内置了一套语言约定理解它对阅读后续输出很重要检查传入技能的参数en或english→ 表格和摘要用英文fr、french或无参数 → 法语默认。关键例外Phase 3 生成的 GitHub 评论永远使用英文因为受众是国际社区。这一点在后续模板规则中再次强调。前置条件检查工作流启动前文档要求先执行两条命令验证环境git rev-parse --is-inside-work-tree gh auth status即必须处于 git 仓库工作区内且ghCLI 已完成认证。任一检查失败则立即停止并向用户解释缺少什么而不是带病继续。这与仓库内 pr-review 技能 的 Phase 0 前置条件完全同构可见这是 rtk 团队维护 PR 类技能的统一约定。Phase 1 — 审计始终执行无论传什么参数审计阶段都会执行。它由「并行数据收集 → 规则分析 → 输出分诊表格 → 自动复制」四步组成。1.1 并行数据采集Data Gathering以下命令在技能中被要求并行执行以缩短审计耗时# 仓库身份用于构造链接绝不硬编码 gh repo view --json nameWithOwner -q .nameWithOwner # 打开的 PR 及完整元数据body 用于与 issues 交叉引用 gh pr list --state open --limit 50 \ --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body # 协作者列表用于区分我们的 PR与外部 PR gh api repos/{owner}/{repo}/collaborators --jq .[].login对每条 PR 再追加两类数据gh api repos/{owner}/{repo}/pulls/{num}/reviews \ --jq [.[] | .user.login : .state] | join(, ) # 修改的文件列表overlap 检测的必要输入 gh pr view {num} --json files --jq [.files[].path] | join(,)文档在这里给出了三条非常关键的工程经验都是踩坑后的结论协作者 API 的降级路径fallback若gh api .../collaborators返回 403/404通常是 token 权限不足改用最近 10 个已合并 PR 的作者集合近似协作者gh pr list --state merged --limit 10 --json author --jq .[].author.login | sort -u若结果仍然模糊通过AskUserQuestion向用户求证。Rate limiting 提示获取每个 PR 的 files 需要 N 次 API 调用每 PR 1 次。对 20 个 PR 的仓库应优先为「疑似重叠候选」PR相同功能域、相同作者拉取 files避免无差别打满限流。JSON 结构陷阱ghJSON 输出中的author是对象{login: ...}而非字符串处理时必须取.author.login。1.2 尺寸分级与分析规则尺寸size按additions分为五级这是后续「quick wins / 风险」判断的基础标签AdditionsXS 50S50–200M200–500L500–1000XL 1000统一的尺寸展示格式为{additions}/-{deletions}, {files} files ({label})例如245/-38, 3 files (S)。在此之上审计阶段执行五类检测Overlaps重叠逐对比较 PR 的文件列表若两个 PR 有50% 的文件交集互相交叉引用cross-referenceClusters聚集同一作者有 3 个及以上打开 PR → 建议评审顺序最小的先评审或按依赖链Staleness陈旧超过 14 天无任何活动 → 打上 stale 标记CI 状态由statusCheckRollup归一为clean/unstable/dirtyReviews 状态approved / changes_requested / 无评审。此外还要扫描每条 PR 的body用大小写不敏感方式匹配fixes #N、closes #N、resolves #N在表格的 Action/Status 列展示为Fixes #42实现 PR ↔ Issue 的自动关联。1.3 三类分诊结论所有打开的 PR 最终落入三个桶Nos PRs我们的 PR作者出现在协作者列表中Externes — Prêtes外部 — 可评审同时满足additions ≤ 1000且files ≤ 10且mergeable ≠ CONFLICTING且 CI 为 clean/unstableExternes — Problématiques外部 — 有问题命中任一条件即入桶additions 1000或files 10mergeable CONFLICTING存在合并冲突CI dirtystatusCheckRollup含失败项与另一条打开 PR 文件重叠 50%。这套阈值1000 additions / 10 files与 repo-recap 技能 的分类规则保持一致是 rtk 团队对「可管理 PR 尺寸」的共识标准。1.4 输出分诊表格与自动复制审计结果以固定结构的 Markdown 表格呈现## PRs ouvertes ({count}) ### Nos PRs | PR | Titre | Taille | CI | Status | | -- | ----- | ------ | -- | ------ | ### Externes — Prêtes pour review | PR | Auteur | Titre | Taille | CI | Reviews | Action | | -- | ------ | ----- | ------ | -- | ------- | ------ | ### Externes — Problématiques | PR | Auteur | Titre | Taille | Problème | Action recommandée | | -- | ------ | ----- | ------ | -------- | ------------------ | ### Résumé - Quick wins : {PRs XS/S prêtes à merger} - Risques : {overlaps, tailles XL, CI dirty} - Clusters : {auteurs avec 3 PRs} - Stale : {PRs sans activité 14j} - Overlaps : {PRs qui touchent les mêmes fichiers}若结果为 0 条打开 PR输出Aucune PR ouverte.并终止不渲染空表。表格渲染完毕后技能会自动把完整表格复制进剪贴板方便直接粘贴到团队频道# Cross-platform clipboard clip() { if command -v pbcopy /dev/null; then pbcopy elif command -v xclip /dev/null; then xclip -selection clipboard elif command -v wl-copy /dev/null; then wl-copy else cat fi } clip EOF {tableau de triage complet} EOF该函数按 macOSpbcopy→ X11xclip→ Waylandwl-copy→ 回退cat原样打印到终端的顺序探测剪贴板工具实现跨平台无依赖复制。成功后确认输出Tableau copié dans le presse-papier.法语/Triage table copied to clipboard.英语。Phase 2 — 深度评审opt-in深度评审不是默认行为需要显式选择避免 Agent 在未授权时消耗大量算力。2.1 PR 选择逻辑带参数时all→ 全部外部 PR编号如42 57→ 仅这些 PR。无参数时通过AskUserQuestion让用户多选question: Quelles PRs voulez-vous reviewer en profondeur ? header: Deep Review multiSelect: true options: - label: Toutes les externes description: Review {N} PRs externes avec agents code-reviewer en parallèle - label: Problématiques uniquement description: Focus sur les {M} PRs à risque (CI dirty, trop large, overlaps) - label: Prêtes uniquement description: Review {K} PRs prêtes à merger - label: Passer description: Terminer ici — juste lauditDraft PR 的不对称处理是这套选择逻辑里值得注意的细节draft PR 被排除在「Toutes les externes」和「Prêtes uniquement」之外但被包含在「Problématiques uniquement」中因为 draft 往往意味着作者尚未完成需要关注若确实要评审某个 draft必须显式输入其编号如42。选择「Passer」则整个工作流到此结束。2.2 并行调度 code-reviewer 子代理对每条选定的 PR通过Task 工具并行启动一个code-reviewer子代理。提示词模板技能原文如下subagent_type: code-reviewer model: sonnet prompt: | Review PR #{num}: {title} by {author} **Metadata**: {additions}/-{deletions}, {changedFiles} files ({size_label}) **CI**: {ci_status} | **Reviews**: {existing_reviews} | **Draft**: {isDraft} **PR Body**: {body} **Diff**: {gh pr diff {num} output} Apply your security-guardian and backend-architect skills for this review. Additionally, apply the RTK-specific checklist: - LazyLockRegex for fixed patterns reused across calls - anyhow::Result .context() (no unwrap()) - Fallback to raw command on filter failure - Exit code propagation - Token savings ≥60% in tests with real fixtures - No async/tokio dependencies Return structured review: ### Critical Issues ### Important Issues ### Suggestions ### Whats Good ✅ Be specific: quote the file:line, explain why its an issue, suggest the fix.所需的 diff 与元数据通过以下命令获取gh pr diff {num} gh pr view {num} --json body,title,author -q {body: .body, title: .title, author: .author.login}所有子代理返回后技能聚合各报告并在最后展示一个总览。2.3 检查清单不是空话与 rtk 源码的对应关系上面提示词中的「RTK-specific checklist」每一条都能在仓库源码中找到落地证据这正是该技能能产生高质量评审的根源——检查项直接对应项目的硬性架构约束LazyLockRegex固定正则只编译一次。在 gh_cmd.rs 中可以真实看到这一模式的批量使用例如HTML_COMMENT_RE、BADGE_LINE_RE等均以static ...: LazyLockRegex LazyLock::new(|| Regex::new(...).unwrap());形式声明。之所以强制如此是因为 code-reviewer 代理 文档列出的「不可协商约束」包括启动时间 10ms热路径里每次调用重新编译Regex::new()会直接拖垮启动性能这是其 Red Flags 表中的头号危险项。anyhow::Result.context()禁止裸unwrap()。代理定义明确指出生产代码中的.unwrap()意味着 panic 会打断开发者工作流必须改为.context(description)?。过滤器失败时回退到原始命令fallback。rtk 作为 CLI 代理其核心价值主张是「过滤失败时用户仍能拿到原始输出」代理文档将此列为 CRITICAL 模式match parse_and_filter(input) { Ok(f) f, Err(e) { eprintln!(...); input.to_string() } }。退出码传播。若底层命令以非零码退出而rtk返回 0会误导上游 Agent 的自动化判断代理文档要求通过std::process::exit(code)传播这与 main.rs 等核心文件中的退出码处理一致。真实 fixture 的 ≥60% token 节省断言。rtk 项目定位是「为常见开发命令降低 60–90% LLM token 消耗的 CLI 代理」其测试体系普遍采用count_tokens()断言节省率。该辅助函数实现在 src/core/utils.rs按split_whitespace()计数且测试 fixture 要求使用命令的真实输出如 tests/fixtures/ 下大量*_raw.txt原始输出而非合成数据。禁止 async/tokio 依赖。单线程、同步 I/O 是满足 10ms 启动约束的前提代理文档将其列为 Cargo.toml 级别的审查项。这些规则同样写入了评审模板本身templates/review-comment.md 明确要求「RTK-specific checks to mention if relevant」并细化为 7 条可引用项含LazyLockRegex、.context(msg)、std::process::exit(code)、token 节省断言 ≥60%、真实 fixture、无 async/tokio。也就是说技能何时查、代理怎么查、模板写成什么三层文件在检查标准上保持了一致。Phase 3 — 评论生成与发布强制人工校验3.1 草稿生成规则对每条已评审 PR按 templates/review-comment.md 生成 GitHub 评论草稿。该模板的结构为**Scope**: Security, code quality, performance, test coverage, architecture### Summary1–2 句直接结论### Critical Issues 阻断性问题必须修复才能合并无则写 None found.### Important Issues ### Suggestions 可省略### Whats Good ✅必须至少 1 条具体优点结尾署名*Automated review via [rtk](https://github.com/rtk-ai/rtk) \/pr-triage*。模板还规定了严格的格式规范引用格式file.rs:42或行内code snippet严重度语义 安全漏洞 / 数据丢失风险 / 功能损坏 / 新功能缺测试 错误处理缺口、性能回退、范围蔓延、缺少 token 节省断言 命名、DRY、文档、风格语气专业、建设性、对事不对人禁止最高级形容词great、amazing、perfect与填充语as mentioned、its worth noting长度200–400 词——足够有用又短到读得完。技能层面的生成规则与之呼应语言必须英文、语气专业且事实化、至少含 1 条积极评价、引用代码行时用file.rs:42格式。3.2 展示与校验技能要求先把全部草稿完整展示给用户格式固定--- ### Draft — PR #{num}: {title} {commentaire complet} ---随后通过AskUserQuestion请求发布授权多选question: Ces commentaires sont prêts. Lesquels voulez-vous poster ? header: Poster multiSelect: true options: - label: Tous ({N} commentaires) description: Poster sur toutes les PRs reviewées - label: PR #{x} — {title_truncated} description: Poster uniquement sur cette PR - label: Aucun description: Annuler — ne rien poster即按 PR 数量动态生成「逐条」选项 「Tous」「Aucun」三类选项。3.3 发布对每条被批准的评论执行gh pr comment {num} --body-file - REVIEW_EOF {commentaire} REVIEW_EOF每条发布成功后确认✅ Commentaire posté sur PR #{num}: {title}若用户选择「Aucun」则输出Aucun commentaire posté. Workflow terminé.并结束。技能 Notes 部分对此有两条铁律永远不在用户显式校验之前发布所有草稿必须在任何gh pr comment之前可见。这是整个工作流中风险最高的动作写操作、公开可见、不可撤回因此被设计为唯一的人工门禁。边界情况处理文档以表格形式规定了七种边界情形的行为这是保证 Agent 在真实仓库中「不崩溃、不静默失败」的关键设计情形行为0 个打开 PR输出Aucune PR ouverte.后结束PR 处于 draft在表格中标注默认跳过评审除非被显式选择CI 状态未知CI 列显示?评审代理超时展示部分错误继续处理其余 PRgh pr diff返回空跳过该 PR 并通知用户PR 超大5000 additions警告「Review partielle, diff tronqué」协作者 API 403/404回退到最近 10 个已合并 PR 的作者列表实现要点与工程约定Notes技能末尾的 Notes 汇总了若干「从经验中固化下来」的实现约束owner/repo 永远通过gh repo view动态推导绝不硬编码——这使技能可以跨仓库复用不依赖任何项目特定的仓库名统一使用ghCLI 而非直接curlGitHub API唯一例外是协作者列表因为它没有对应的gh子命令statusCheckRollup可能为null→ 按?处理mergeable的取值是MERGEABLE/CONFLICTING/UNKNOWN→UNKNOWN按?处理再次强调未经用户显式校验绝不发布所有草稿必须先在聊天中可见。这些约定与仓库中其他维护技能的风格高度一致pr-review 强调「一次一条 PR、合并前必须显式 ok、绝不 override 维护者的 CHANGES_REQUESTED」issue-triage 则处理 issue 侧的分诊三者与pr-triage共同构成 rtk 的完整 PR/issue 治理闭环。小结这个工作流的设计思想从 SKILL.md 的整体结构看pr-triage的设计可以归纳为四条原则对任何想把 CI/评审流程 Agent 化的团队都有参考价值读操作全自动化写操作设门禁Phase 1 审计和 Phase 2 评审只读 GitHub 数据可放心并行唯二的写动作剪贴板复制、gh pr comment分别属于本地低风险和需校验高风险风险等级与人工介入程度成正比。把领域知识编码进提示词RTK-specific checklist 不是泛泛的「注意代码质量」而是六条与项目架构约束10ms 启动、同步 I/O、fallback、退出码、token 节省一一对应的具体检查项并在 code-reviewer 代理 中扩展为完整的 Red Flags 表、防御性代码模式和调用点分析Call-Site Analysis流程。规则先于执行尺寸分级、重叠 50%、陈旧 14 天、集群 ≥3 PR 等阈值在文档中先行定义使审计结果可复现、可解释而非依赖模型临场判断。优雅降级协作者 API 403/404、CI 未知、diff 为空、代理超时……每一种失败路径都有显式行为定义保证技能在生产权限环境下仍然可用。如果你想在自己的仓库中复刻这套流程可以直接参考 .claude/skills/ 目录下的pr-triage、issue-triage、repo-recap等技能文件以及 agents/code-reviewer.md 中定义的评审代理它们共同展示了「技能流程 代理专业知识 模板输出格式」三层解耦的 Agent 工程化写法。【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 rtk pr-triage 技能详解：基于 gh CLI 的三阶段 GitHub PR 自动审计、深度评审与评论发布工作流
rtk pr-triage 技能详解基于 gh CLI 的三阶段 GitHub PR 自动审计、深度评审与评论发布工作流【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文以 rtk 仓库中的 Claude Code 技能定义文件 .claude/skills/pr-triage/SKILL.md 为核心完整解读其「审计 → 深度评审 → 评论发布」三阶段 PR 分诊triage工作流。读完本文你将掌握如何用ghCLI 命令并行采集 PR 元数据、按尺寸/重叠/陈旧度规则自动分类 PR、并行调度code-reviewer子代理进行深度代码评审以及如何通过强制人工校验安全地把结构化评审意见发布到 GitHub并了解该评审检查清单如何与 rtk 源码中LazyLockRegex、token 节省断言、退出码传播等真实约束一一对应。技能定位与触发方式pr-triage是 rtk 项目内嵌于 SKILL.md 中的一个 Claude Code 技能Skill。技能头部元数据声明了它的核心契约name: pr-triage description: PR triage: audit open PRs, deep review selected ones, draft and post review comments. Args: all to review all, PR numbers to focus (e.g. 42 57), en/fr for language, no arg audit only in French. allowed-tools: - Bash - Read - Grep - Glob effort: medium tags: [triage, pr, github, review, code-review, rtk]功能定位审计打开的 PR、对选定 PR 做深度评审、起草并经校验后发布评审评论。权限边界仅授予Bash、Read、Grep、Glob四类工具effort: medium意味着技能以中等推理预算运行不做无限制展开。参数语义all表示评审全部外部 PRPR 编号列表如42 57表示只聚焦指定 PRen/fr控制输出语言不带参数则仅执行审计且默认法语输出。它与仓库中另一个技能 repo-recap 的分工在文档中明确列出Skill用途输出/pr-triage分诊、评审、评论 PR行动表格 reviews 已发布的评论/repo-recap供团队分享的整体仓库回顾Markdown 摘要PRs issues releases触发条件分两类手动/pr-triage、/pr-triage all、/pr-triage 42 57主动proactive当存在超过 5 个未评审的打开 PR或检测到某个 PR 已超过 14 天无活动stale时。语言规则技能内置了一套语言约定理解它对阅读后续输出很重要检查传入技能的参数en或english→ 表格和摘要用英文fr、french或无参数 → 法语默认。关键例外Phase 3 生成的 GitHub 评论永远使用英文因为受众是国际社区。这一点在后续模板规则中再次强调。前置条件检查工作流启动前文档要求先执行两条命令验证环境git rev-parse --is-inside-work-tree gh auth status即必须处于 git 仓库工作区内且ghCLI 已完成认证。任一检查失败则立即停止并向用户解释缺少什么而不是带病继续。这与仓库内 pr-review 技能 的 Phase 0 前置条件完全同构可见这是 rtk 团队维护 PR 类技能的统一约定。Phase 1 — 审计始终执行无论传什么参数审计阶段都会执行。它由「并行数据收集 → 规则分析 → 输出分诊表格 → 自动复制」四步组成。1.1 并行数据采集Data Gathering以下命令在技能中被要求并行执行以缩短审计耗时# 仓库身份用于构造链接绝不硬编码 gh repo view --json nameWithOwner -q .nameWithOwner # 打开的 PR 及完整元数据body 用于与 issues 交叉引用 gh pr list --state open --limit 50 \ --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body # 协作者列表用于区分我们的 PR与外部 PR gh api repos/{owner}/{repo}/collaborators --jq .[].login对每条 PR 再追加两类数据gh api repos/{owner}/{repo}/pulls/{num}/reviews \ --jq [.[] | .user.login : .state] | join(, ) # 修改的文件列表overlap 检测的必要输入 gh pr view {num} --json files --jq [.files[].path] | join(,)文档在这里给出了三条非常关键的工程经验都是踩坑后的结论协作者 API 的降级路径fallback若gh api .../collaborators返回 403/404通常是 token 权限不足改用最近 10 个已合并 PR 的作者集合近似协作者gh pr list --state merged --limit 10 --json author --jq .[].author.login | sort -u若结果仍然模糊通过AskUserQuestion向用户求证。Rate limiting 提示获取每个 PR 的 files 需要 N 次 API 调用每 PR 1 次。对 20 个 PR 的仓库应优先为「疑似重叠候选」PR相同功能域、相同作者拉取 files避免无差别打满限流。JSON 结构陷阱ghJSON 输出中的author是对象{login: ...}而非字符串处理时必须取.author.login。1.2 尺寸分级与分析规则尺寸size按additions分为五级这是后续「quick wins / 风险」判断的基础标签AdditionsXS 50S50–200M200–500L500–1000XL 1000统一的尺寸展示格式为{additions}/-{deletions}, {files} files ({label})例如245/-38, 3 files (S)。在此之上审计阶段执行五类检测Overlaps重叠逐对比较 PR 的文件列表若两个 PR 有50% 的文件交集互相交叉引用cross-referenceClusters聚集同一作者有 3 个及以上打开 PR → 建议评审顺序最小的先评审或按依赖链Staleness陈旧超过 14 天无任何活动 → 打上 stale 标记CI 状态由statusCheckRollup归一为clean/unstable/dirtyReviews 状态approved / changes_requested / 无评审。此外还要扫描每条 PR 的body用大小写不敏感方式匹配fixes #N、closes #N、resolves #N在表格的 Action/Status 列展示为Fixes #42实现 PR ↔ Issue 的自动关联。1.3 三类分诊结论所有打开的 PR 最终落入三个桶Nos PRs我们的 PR作者出现在协作者列表中Externes — Prêtes外部 — 可评审同时满足additions ≤ 1000且files ≤ 10且mergeable ≠ CONFLICTING且 CI 为 clean/unstableExternes — Problématiques外部 — 有问题命中任一条件即入桶additions 1000或files 10mergeable CONFLICTING存在合并冲突CI dirtystatusCheckRollup含失败项与另一条打开 PR 文件重叠 50%。这套阈值1000 additions / 10 files与 repo-recap 技能 的分类规则保持一致是 rtk 团队对「可管理 PR 尺寸」的共识标准。1.4 输出分诊表格与自动复制审计结果以固定结构的 Markdown 表格呈现## PRs ouvertes ({count}) ### Nos PRs | PR | Titre | Taille | CI | Status | | -- | ----- | ------ | -- | ------ | ### Externes — Prêtes pour review | PR | Auteur | Titre | Taille | CI | Reviews | Action | | -- | ------ | ----- | ------ | -- | ------- | ------ | ### Externes — Problématiques | PR | Auteur | Titre | Taille | Problème | Action recommandée | | -- | ------ | ----- | ------ | -------- | ------------------ | ### Résumé - Quick wins : {PRs XS/S prêtes à merger} - Risques : {overlaps, tailles XL, CI dirty} - Clusters : {auteurs avec 3 PRs} - Stale : {PRs sans activité 14j} - Overlaps : {PRs qui touchent les mêmes fichiers}若结果为 0 条打开 PR输出Aucune PR ouverte.并终止不渲染空表。表格渲染完毕后技能会自动把完整表格复制进剪贴板方便直接粘贴到团队频道# Cross-platform clipboard clip() { if command -v pbcopy /dev/null; then pbcopy elif command -v xclip /dev/null; then xclip -selection clipboard elif command -v wl-copy /dev/null; then wl-copy else cat fi } clip EOF {tableau de triage complet} EOF该函数按 macOSpbcopy→ X11xclip→ Waylandwl-copy→ 回退cat原样打印到终端的顺序探测剪贴板工具实现跨平台无依赖复制。成功后确认输出Tableau copié dans le presse-papier.法语/Triage table copied to clipboard.英语。Phase 2 — 深度评审opt-in深度评审不是默认行为需要显式选择避免 Agent 在未授权时消耗大量算力。2.1 PR 选择逻辑带参数时all→ 全部外部 PR编号如42 57→ 仅这些 PR。无参数时通过AskUserQuestion让用户多选question: Quelles PRs voulez-vous reviewer en profondeur ? header: Deep Review multiSelect: true options: - label: Toutes les externes description: Review {N} PRs externes avec agents code-reviewer en parallèle - label: Problématiques uniquement description: Focus sur les {M} PRs à risque (CI dirty, trop large, overlaps) - label: Prêtes uniquement description: Review {K} PRs prêtes à merger - label: Passer description: Terminer ici — juste lauditDraft PR 的不对称处理是这套选择逻辑里值得注意的细节draft PR 被排除在「Toutes les externes」和「Prêtes uniquement」之外但被包含在「Problématiques uniquement」中因为 draft 往往意味着作者尚未完成需要关注若确实要评审某个 draft必须显式输入其编号如42。选择「Passer」则整个工作流到此结束。2.2 并行调度 code-reviewer 子代理对每条选定的 PR通过Task 工具并行启动一个code-reviewer子代理。提示词模板技能原文如下subagent_type: code-reviewer model: sonnet prompt: | Review PR #{num}: {title} by {author} **Metadata**: {additions}/-{deletions}, {changedFiles} files ({size_label}) **CI**: {ci_status} | **Reviews**: {existing_reviews} | **Draft**: {isDraft} **PR Body**: {body} **Diff**: {gh pr diff {num} output} Apply your security-guardian and backend-architect skills for this review. Additionally, apply the RTK-specific checklist: - LazyLockRegex for fixed patterns reused across calls - anyhow::Result .context() (no unwrap()) - Fallback to raw command on filter failure - Exit code propagation - Token savings ≥60% in tests with real fixtures - No async/tokio dependencies Return structured review: ### Critical Issues ### Important Issues ### Suggestions ### Whats Good ✅ Be specific: quote the file:line, explain why its an issue, suggest the fix.所需的 diff 与元数据通过以下命令获取gh pr diff {num} gh pr view {num} --json body,title,author -q {body: .body, title: .title, author: .author.login}所有子代理返回后技能聚合各报告并在最后展示一个总览。2.3 检查清单不是空话与 rtk 源码的对应关系上面提示词中的「RTK-specific checklist」每一条都能在仓库源码中找到落地证据这正是该技能能产生高质量评审的根源——检查项直接对应项目的硬性架构约束LazyLockRegex固定正则只编译一次。在 gh_cmd.rs 中可以真实看到这一模式的批量使用例如HTML_COMMENT_RE、BADGE_LINE_RE等均以static ...: LazyLockRegex LazyLock::new(|| Regex::new(...).unwrap());形式声明。之所以强制如此是因为 code-reviewer 代理 文档列出的「不可协商约束」包括启动时间 10ms热路径里每次调用重新编译Regex::new()会直接拖垮启动性能这是其 Red Flags 表中的头号危险项。anyhow::Result.context()禁止裸unwrap()。代理定义明确指出生产代码中的.unwrap()意味着 panic 会打断开发者工作流必须改为.context(description)?。过滤器失败时回退到原始命令fallback。rtk 作为 CLI 代理其核心价值主张是「过滤失败时用户仍能拿到原始输出」代理文档将此列为 CRITICAL 模式match parse_and_filter(input) { Ok(f) f, Err(e) { eprintln!(...); input.to_string() } }。退出码传播。若底层命令以非零码退出而rtk返回 0会误导上游 Agent 的自动化判断代理文档要求通过std::process::exit(code)传播这与 main.rs 等核心文件中的退出码处理一致。真实 fixture 的 ≥60% token 节省断言。rtk 项目定位是「为常见开发命令降低 60–90% LLM token 消耗的 CLI 代理」其测试体系普遍采用count_tokens()断言节省率。该辅助函数实现在 src/core/utils.rs按split_whitespace()计数且测试 fixture 要求使用命令的真实输出如 tests/fixtures/ 下大量*_raw.txt原始输出而非合成数据。禁止 async/tokio 依赖。单线程、同步 I/O 是满足 10ms 启动约束的前提代理文档将其列为 Cargo.toml 级别的审查项。这些规则同样写入了评审模板本身templates/review-comment.md 明确要求「RTK-specific checks to mention if relevant」并细化为 7 条可引用项含LazyLockRegex、.context(msg)、std::process::exit(code)、token 节省断言 ≥60%、真实 fixture、无 async/tokio。也就是说技能何时查、代理怎么查、模板写成什么三层文件在检查标准上保持了一致。Phase 3 — 评论生成与发布强制人工校验3.1 草稿生成规则对每条已评审 PR按 templates/review-comment.md 生成 GitHub 评论草稿。该模板的结构为**Scope**: Security, code quality, performance, test coverage, architecture### Summary1–2 句直接结论### Critical Issues 阻断性问题必须修复才能合并无则写 None found.### Important Issues ### Suggestions 可省略### Whats Good ✅必须至少 1 条具体优点结尾署名*Automated review via [rtk](https://github.com/rtk-ai/rtk) \/pr-triage*。模板还规定了严格的格式规范引用格式file.rs:42或行内code snippet严重度语义 安全漏洞 / 数据丢失风险 / 功能损坏 / 新功能缺测试 错误处理缺口、性能回退、范围蔓延、缺少 token 节省断言 命名、DRY、文档、风格语气专业、建设性、对事不对人禁止最高级形容词great、amazing、perfect与填充语as mentioned、its worth noting长度200–400 词——足够有用又短到读得完。技能层面的生成规则与之呼应语言必须英文、语气专业且事实化、至少含 1 条积极评价、引用代码行时用file.rs:42格式。3.2 展示与校验技能要求先把全部草稿完整展示给用户格式固定--- ### Draft — PR #{num}: {title} {commentaire complet} ---随后通过AskUserQuestion请求发布授权多选question: Ces commentaires sont prêts. Lesquels voulez-vous poster ? header: Poster multiSelect: true options: - label: Tous ({N} commentaires) description: Poster sur toutes les PRs reviewées - label: PR #{x} — {title_truncated} description: Poster uniquement sur cette PR - label: Aucun description: Annuler — ne rien poster即按 PR 数量动态生成「逐条」选项 「Tous」「Aucun」三类选项。3.3 发布对每条被批准的评论执行gh pr comment {num} --body-file - REVIEW_EOF {commentaire} REVIEW_EOF每条发布成功后确认✅ Commentaire posté sur PR #{num}: {title}若用户选择「Aucun」则输出Aucun commentaire posté. Workflow terminé.并结束。技能 Notes 部分对此有两条铁律永远不在用户显式校验之前发布所有草稿必须在任何gh pr comment之前可见。这是整个工作流中风险最高的动作写操作、公开可见、不可撤回因此被设计为唯一的人工门禁。边界情况处理文档以表格形式规定了七种边界情形的行为这是保证 Agent 在真实仓库中「不崩溃、不静默失败」的关键设计情形行为0 个打开 PR输出Aucune PR ouverte.后结束PR 处于 draft在表格中标注默认跳过评审除非被显式选择CI 状态未知CI 列显示?评审代理超时展示部分错误继续处理其余 PRgh pr diff返回空跳过该 PR 并通知用户PR 超大5000 additions警告「Review partielle, diff tronqué」协作者 API 403/404回退到最近 10 个已合并 PR 的作者列表实现要点与工程约定Notes技能末尾的 Notes 汇总了若干「从经验中固化下来」的实现约束owner/repo 永远通过gh repo view动态推导绝不硬编码——这使技能可以跨仓库复用不依赖任何项目特定的仓库名统一使用ghCLI 而非直接curlGitHub API唯一例外是协作者列表因为它没有对应的gh子命令statusCheckRollup可能为null→ 按?处理mergeable的取值是MERGEABLE/CONFLICTING/UNKNOWN→UNKNOWN按?处理再次强调未经用户显式校验绝不发布所有草稿必须先在聊天中可见。这些约定与仓库中其他维护技能的风格高度一致pr-review 强调「一次一条 PR、合并前必须显式 ok、绝不 override 维护者的 CHANGES_REQUESTED」issue-triage 则处理 issue 侧的分诊三者与pr-triage共同构成 rtk 的完整 PR/issue 治理闭环。小结这个工作流的设计思想从 SKILL.md 的整体结构看pr-triage的设计可以归纳为四条原则对任何想把 CI/评审流程 Agent 化的团队都有参考价值读操作全自动化写操作设门禁Phase 1 审计和 Phase 2 评审只读 GitHub 数据可放心并行唯二的写动作剪贴板复制、gh pr comment分别属于本地低风险和需校验高风险风险等级与人工介入程度成正比。把领域知识编码进提示词RTK-specific checklist 不是泛泛的「注意代码质量」而是六条与项目架构约束10ms 启动、同步 I/O、fallback、退出码、token 节省一一对应的具体检查项并在 code-reviewer 代理 中扩展为完整的 Red Flags 表、防御性代码模式和调用点分析Call-Site Analysis流程。规则先于执行尺寸分级、重叠 50%、陈旧 14 天、集群 ≥3 PR 等阈值在文档中先行定义使审计结果可复现、可解释而非依赖模型临场判断。优雅降级协作者 API 403/404、CI 未知、diff 为空、代理超时……每一种失败路径都有显式行为定义保证技能在生产权限环境下仍然可用。如果你想在自己的仓库中复刻这套流程可以直接参考 .claude/skills/ 目录下的pr-triage、issue-triage、repo-recap等技能文件以及 agents/code-reviewer.md 中定义的评审代理它们共同展示了「技能流程 代理专业知识 模板输出格式」三层解耦的 Agent 工程化写法。【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考