rtk repo-recap 技能用 Claude Code Skill 一键生成 PR/Issue/Release 团队简报的完整流水线【免费下载链接】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/skills/repo-recap/SKILL.md技能文件展开完整拆解其前置检查 → 数据采集 → 分类分析 → 格式化输出 → 复制到剪贴板七步工作流并结合仓库中 release-please 配置、GitHub Actions 工作流与rtk gh过滤器的源码实现说明该技能如何与 rtk 项目的日常维护自动化协同工作。读完本文你可以复用这套流程为自己的仓库构建可分享的 Repo Recap 简报并理解技能文件中每条规则背后的工程动机。技能定位rtk 维护工作流中的一个自动化环节repo-recap 是 rtk 项目.claude/skills/目录下的一个 Claude Code 技能Skill与同目录的pr-triage、issue-triage、ship、security-guardian等技能共同构成维护者工作流。它的职责单一而明确Generate a structured recap of the repository state: open PRs, open issues, recent releases, and executive summary. Output is formatted as Markdown with clickable GitHub links, ready to share.技能文件头部的 frontmatter 声明了它的元信息见 SKILL.md字段值含义descriptionGenerate a comprehensive repo recap (PRs, issues, releases) for sharing with team. Pass en or fr as argument for language (default fr).技能用途描述同时约定了语言参数allowed-toolsBash Read Grep技能被允许调用的工具集即只允许执行命令与读取文件不修改仓库内容从allowed-tools限制可以看出这是一个只读采集 只写剪贴板型技能它的全部副作用就是产出一份 Markdown 简报并复制到剪贴板不会触碰仓库本身。这也契合 rtk 项目对 AI 代理行为收敛的一贯取向——CLAUDE.md中专门用 Avoiding Rabbit Holes 章节约束了探索性命令数量repo-recap 则把采集步骤固化为固定的 5 条命令避免 Agent 自由发挥。语言参数双语输出默认法语技能约定通过调用参数选择输出语言传入en或english→ 用英文生成简报传入fr、french或不传参→ 用法语生成简报默认。这个默认值并非偶然从技能模板中的 Récap、Nos PRs、Contributeurs externes 等表头可以看出该仓库的维护团队以法语为主要工作语言。技能同时维护 FR 与 EN 两套完整输出模板两套模板的表格结构完全一致仅表头文案与空数据提示语不同例如 Aucune PR ouverte. vs No open PRs.保证同一份数据在两种语言下呈现相同的可读结构。前置条件检查先验证环境再采集技能要求在任何数据采集之前先执行两条检查命令# 必须位于 git 仓库内 git rev-parse --is-inside-work-tree # 必须已认证 gh CLI gh auth status规则是任一条失败就立即停止并告知用户缺少什么而不是继续执行后续步骤。这一设计避免了两类典型故障——在非仓库目录执行gh导致nameWithOwner取不到值而生成错误链接以及未认证时gh pr list报 401 后 Agent 误以为仓库没有 open PR而输出误导性的空表格。第一步数据采集5 条并行 gh 命令技能将采集固化为 5 条ghCLI 命令并通过--json参数获取结构化数据以便后续分析# 仓库标识用于生成链接 gh repo view --json nameWithOwner -q .nameWithOwner # Open PRs 及元数据 gh pr list --state open --limit 50 --json number,title,author,createdAt,changedFiles,additions,deletions,reviewDecision,isDraft # Open Issues 及元数据 gh issue list --state open --limit 50 --json number,title,author,createdAt,labels,assignees # 最近 Release版本历史 gh release list --limit 5 # 最近已合并 PR贡献者活跃度 gh pr list --state merged --limit 10 --json number,title,author,mergedAt各命令的字段选择与后续步骤一一对应这是理解整个技能数据流的关键changedFiles/additions/deletions→ 支撑第三步的 PR 尺寸分级与重叠检测reviewDecision→ 判断 CI 是否被要求修改CHANGES_REQUESTEDisDraft→ 区分草稿 PR 与待评审 PRlabels/assigneesissue→ 支撑 issue 分类merged PR 的author/mergedAt→ 作为权限不足时推断维护者的回退依据。技能还特别标注了一个ghJSON 结果的易错点authorin JSON results is an object{login: ...}— always extract.author.loginwhen processing.即author是一个对象而非字符串处理时必须取.author.login否则后续所有按作者分组的逻辑维护者判定、cluster 检测都会失败。第二步确定维护者区分我们的 PR与外部贡献为了把 PR 分为 Our PRs 和外部贡献两类技能通过 GitHub REST API 拉取协作者列表gh api repos/{owner}/{repo}/collaborators --jq .[].login其中{owner}/{repo}来自第一步的gh repo view结果不允许硬编码。若该请求因权限失败回退策略是将最近合并过 PR 的作者视为拥有 write/admin 权限的人。技能要求在此情况下拿不准时直接向用户确认而不是猜测——这是宁可问一句不可输出错误简报的取舍。第三步分析与分类技能的核心算法PR 三分类1. Our PRs作者为仓库协作者列出 PR 号带链接、标题、尺寸additions、files 数与状态。2. External — Reviewable外部贡献、可正常评审必须同时满足additions ≤ 1000且files ≤ 10无合并冲突CI 未失败。输出包含PR 链接、作者、标题、尺寸、评审状态、建议动作。3. External — Problematic满足任一即入列additions 1000或files 10CI 失败reviewDecision CHANGES_REQUESTED或 checks 失败与另一个 open PR 修改了相同文件重叠。输出额外要求写明具体问题和已采取/需采取的动作例如 Rebase requested、Split requested、Trim requested、CI broken、Waiting on author。尺寸标签快速视觉分诊标签AdditionsXS 50S50-200M200-500L500-1000XL 1000统一格式为{additions}, {files} files ({label})例如245, 2 files (S)。这套 XS–XL 分档让维护者扫一眼表格就能定位XS/S 可直接合并的 quick wins 与 XL 需要拆分的高风险项。重叠检测overlap两个 PR 若修改了相同文件即视为重叠。技能利用第一步采集的changedFiles做比对若两个 PR 的文件重叠度超过 50%双方都标记为 overlapping 并互相交叉引用。这直接对应Problematic分类中的第三类条件也解释了为何采集命令要显式请求changedFiles字段。贡献者 cluster 标记若同一作者有 3 个及以上 open PR在简报中记为一个 cluster并给出建议的评审顺序——最小的先评或按依赖链排序。这避免了维护者被同一人的批量 PR 淹没时失去优先级感。Issue 四分类In progress存在关联的 open PR通过 PR body 中的fixes #N、closes #N或同主题匹配Quick fix范围小、可立即执行bug 报告、小型增强Feature request范围大、需要设计讨论Covered by PR已有 PR 覆盖该 issue需在简报中链接该 PR。第四步近期 Release 推导含 release-please 回退从gh release list输出提取 version、date、name列出最近 5 个。关键的回退路径若仓库没有 GitHub Release则检查已合并 PR 中标题匹配chore(*): release *的 release-please 提交作为替代版本来源。这一规则与本仓库的实际发布机制严格对应仓库中存在完整的 release-please 证据链release-please-config.json 声明了release-type: rust、package-name: rtk以及bump-minor-pre-major/bump-patch-for-minor-pre-major两条版本递增策略.release-please-manifest.json 记录当前版本. : 0.42.4CHANGELOG.md 由 release-please 自动生成条目中可见**cicd:** set release-please target-branch to master等发布相关提交.github/workflows/release.yml 定义了 tag 触发的多平台构建发布流程.github/workflows/next-release.yml 在 PR 合入后按feat/fix前缀自动更新下一个 release条目——与 issue 分类中fixes #N/closes #N的关联逻辑使用同一套语义。因此对该仓库执行 repo-recap 时Release 表格通常直接来自gh release list而对没有 Release 页的仓库release-please 提交回退正好适用。第五步执行摘要Executive Summary技能要求产出 5–6 条要点覆盖固定维度open PRs 与 issues 的总数活跃贡献者谁的 PR/issue 最多主要风险超大 PR、CI 失败、合并冲突Quick winsXS/S 尺寸、无阻塞、可直接合并的小 PR需要的 bug 修复hook 缺陷、回归本方OurPR 的状态。注意Bug fixes needed (hook bugs, regressions)这一条是明确针对 rtk 项目语境写的rtk 的核心功能就是 hook 与过滤器参见 hooks/ 目录及 src/hooks/ 模块hook 回归是该仓库最高优先级的缺陷类型因此被直接写进了摘要模板。第六步输出格式规范完整简报的 Markdown 结构约束如下标题# {Repo Name} — Récap au {date}FR或# {Repo Name} — Recap {date}EN各章节之间用---分隔所有 PR/issue 号必须是可点击链接PR 用[#123](https://github.com/{owner}/{repo}/pull/123)issue 用.../issues/123所有清单一律使用 Markdown 管道表格关键动作与风险用加粗相关 PR 与 issue 之间交叉引用如 Covered by #131。空数据处理避免输出空表格0 个 open PR → 显示 Aucune PR ouverte.FR/ No open PRs.EN0 个 open issue → Aucune issue ouverte. / No open issues.0 个 release → Aucune release récente. / No recent releases.。技能提供了完整的 FR 输出模板章节依次为 Releases récentes、PRs ouvertes含 Nos PRs / Contributeurs externes — Reviewables / Contributeurs externes — Problématiques 三个子表、Issues ouvertes、Résumé exécutifEN 模板结构相同表头替换为 Recent Releases、Open PRs、Our PRs、External — Reviewable、External — Problematic、Open Issues、Executive Summary动作标签统一为 To review、Rebase requested、Split requested、Trim requested、CI broken、Waiting on author、Feature request、Quick fix、Covered by PR。第七步自动复制到剪贴板简报展示后自动复制到系统剪贴板采用跨平台降级策略# 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 } cat EOF | clip {formatted recap content} EOF依次探测 macOS 的pbcopy、X11 的xclip、Wayland 的wl-copy全部缺失时降级为cat直接输出保证不中断流程。最后以 Copié dans le presse-papier.FR或 Copied to clipboard.EN确认。源码纵深rtk gh与--json透传机制的契合点理解 repo-recap 如何嵌入 rtk 项目的维护日常需要看一个源码细节。rtk 自身就是gh命令的输出压缩代理src/cmds/git/gh_cmd.rs 中实现了pr、issue、run、repo、api等子命令的过滤器把gh的 JSON 输出压缩成紧凑文本docs/usage/FEATURES.md 中给出rtk gh pr list约 80% 的输出压缩率。但技能里所有采集命令都显式带了--json参数。这不是巧合而是与 rtk gh 过滤器的一条透传规则精确对应——gh_cmd.rs 定义了检测函数/// Check if args contain --json flag (user wants specific JSON fields, not RTK filtering) fn has_json_flag(args: [String]) - bool { args.iter().any(|a| a --json) }并在 run 入口 中pub fn run(subcommand: str, args: [String], verbose: u8, ultra_compact: bool) - Resulti32 { // When user explicitly passes --json, they want raw gh JSON output, not RTK filtering if has_json_flag(args) { return run_passthrough(gh, subcommand, args); } ... }也就是说只要参数里出现--jsonrtk 就完全透传原始 JSON不做任何压缩。repo-recap 的采集步骤依赖完整的结构化 JSON 来做尺寸分级、重叠比对和作者分组任何压缩都会破坏分析而日常人工巡检时用rtk gh pr list拿紧凑视图省 token。同一套工具链在机器消费与人眼消费两种场景下各走一条路径--json是两者之间的开关。从源码结构看这种代理优先、显式逃逸的模式正是 rtk 设计哲学的缩影CLAUDE.md建议日常开发中优先使用rtk cmd获得 token 优化输出同时保留rtk proxy command与透传机制保证永远能拿到原始输出。repo-recap 作为维护者技能恰好示范了如何在使用 rtk 的环境中正确地绕过过滤器带--json与使用过滤器人工浏览之间的边界。顺带一提该仓库 .github/workflows/stale.yml 每周一运行 stale 机器人其注释里直接提到 51 open PRs 的 triage 压力——这正是 repo-recap 类技能的现实背景当 open PR/issue 数量超过人工记忆容量时需要周期性机器化简报来维持分诊节奏。使用守则技能 Notes 全量继承技能末尾的四条 Notes 是对执行质量的最终约束始终使用ghCLI唯一例外是拉取 collaborators 列表走gh api不直接调 GitHub REST API仓库 owner/name 必须从gh repo view推导不得硬编码——保证技能可复用到任意仓库保持表格紧凑长标题截断最长约 60 字符尽可能交叉引用重叠的 PR/issue并再次强调author是对象、必须取.author.login。小结一套可移植的仓库简报流水线repo-recap 的完整链路可以概括为git/gh双前置检查 → 5 条--json采集命令 → 协作者列表界定我方边界 → PR 三分类 XS–XL 分档 50% 重叠阈值 3-PR cluster 规则 → issue 四分类 → Release 推导release-please 提交回退→ 5–6 条执行摘要 → 双语 Markdown 模板 空数据兜底 → 跨平台剪贴板复制。其中每个阈值1000 additions、10 files、50% 重叠、3 PR都是显式可调的参数意味着把该 SKILL.md 拷入其他项目后只需按团队偏好调整阈值即可复用。对 rtk 仓库本身而言它与 stale 机器人、release-please 流水线、next-release 自动更新共同构成了机器做采集与分诊、人做决策的维护自动化闭环。【免费下载链接】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），仅供参考