awesome-python PR 评审自动化review-prs 技能的五步 Agent 工作流解析【免费下载链接】awesome-pythonThe definitive list that answers I want to do X in Python, which tool should I use?项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-pythonawesome-python 是一个刻意做成精选清单shortlist而非目录catalog的开源项目每个用例Use Case只保留最显然的 3 个选择和至多 2 个挑战者条目上限硬性卡在 5 个。这意味着绝大多数 PR 会被拒绝而评审流程必须同时做到机械化格式、重复、活跃度与编辑化是否配得上这个 slot。本仓库在 .claude/skills/review-prs/SKILL.md 中把整套 PR 评审流程沉淀为一个 Claude Code 技能Skill给定 PR 队列Agent 按 Fetch → Screen → Judge → Act → Report 五个步骤把开放队列中的每个 PR 收敛到三种终态之一——合并merged、关闭closed或明确搁置parked/kept open。读完后你能掌握如何把规则文档 Agent 工作流解耦设计成一个可复用的维护型 Agent 技能以及其中每一步的gh命令、委托调用和人工确认点是怎么落地的。技能定位规则与工作流的解耦技能文件采用标准的 SKILL.md 结构YAML frontmatter 定义了三个字段namereview-prs技能标识description说明触发条件——维护者要求评审 PR、处理 PR 队列、或判断某个特定 PR 是否该合并时激活并明确了工作流骨架从 diff 筛查 → 委托 audit-the-list 做准入判断 → 在 GitHub 上合并或关闭argument-hint[PR numbers]即技能可接收具体 PR 编号作为参数不传则处理整个队列。文档开头一句话点出了整个设计的核心原则规则住在 CONTRIBUTING.mdQuality Requirements、Admission、Review Process、Automatic Rejection里——这个技能是应用这些规则的工作流不是规则的第二份拷贝。这是一种典型的单一事实源设计准入规则只维护在 CONTRIBUTING.md 中技能文件只描述执行过程避免规则在两个地方漂移。这也与 CLAUDE.md 的入口规则呼应——每次增删条目包括直接提交不只是 PR 评审都要应用 CONTRIBUTING.md 的规则。理解这个工作流之前需要先理解它所执行的那套规则这也是后续每一步筛查和判断的依据。前置知识工作流依赖的规则底座CONTRIBUTING.md 定义了三块核心规则review-prs 的每个步骤都在消费它们质量要求Quality Requirements——所有提交必须同时满足五条Serves Python DevelopersPython 开发者在 Python 工作中实际使用它。实现语言和打包方式无关——uv 和 ty 是 Rust 写的agent 技能包是 markdown都属于清单范围一个没人用于 Python 工作的纯 Python 项目则不属于。Active最近 12 个月内有提交Stable生产可用非 alpha/beta/experimentalDocumented有清晰的 README含示例和用例Established仓库至少存在 1 个月。准入规则Admission——定义用例与容量上限**Use Case用例**是清单结构定义的每个 Subcategory子分类是一个用例没有子分类的 Section 整体是一个用例。结构变更新 section、新 subcategory、拆分过大的用例只能由维护者执行——条目 PR 永远不能创建它所需要的子分类每个用例至多3 个 Obvious Choices资深开发者脱口而出的选择2 个 Challengers尚非显然但可信的继任者准入需要采纳趋势证据而非单纯人气硬性上限5 个条目/用例Displacement置换用例满员后唯一的进入方式——PR 必须点名它要替换的条目并论证新项目做得更糟的那位的活儿更好。一进一出Evidence证据准入由维护者编辑判断拍板主要参考 PyPI 下载量而非 GitHub star维护者判断最终生效。自动拒绝规则Automatic Rejection——以下情况 PR 会被直接关闭一个 PR 添加多个项目用例已满员且 PR 没有 Displacement 论证PR 自建 section/subcategory 并填充它同一组织/作者跨一或多个 PR 的协调式自我推广与现有条目或近期已关闭 PR 重复PR 描述为空或占位分类不当项目已归档/废弃12 个月以上无提交无文档或用例不清晰仓库存在不足 1 个月。这套规则的由来背景可以参见 docs/adr/0001-shortlist-not-catalog.md清单从三车道模型Industry Standard / Rising Star / Hidden Gem改造为明显选项精选清单术语体系Use Case、Obvious Choice、Challenger、Displacement、Split 等定义在 CONTEXT.md 中。步骤一 Fetch拉取队列与 diff技能的参数指定具体 PR 时只处理这些 PR否则取整个队列gh pr list --repo vinta/awesome-python --limit 10 \ --json number,title,author,url,body,files,mergeable,mergeStateStatus字段选择很讲究mergeable和mergeStateStatus直接决定后续走哪条合并路径见步骤四files用于判断 PR 性质body用于空描述检查。随后并行拉取所有 diffgh pr diff number --repo vinta/awesome-python拉到 diff 后要做的第一件事是分拣sort the batch规则是新增条目的 PR 继续走流程其他一切typo 修复、website 改动、文档改动超出技能范围——不动它们只报告到 needs human需人工处理清单。这里有一个刻意的设计needs-human 的 PR 每次运行都会再次冒出来resurface直到有人类动手处理。Done when every PR is sorted and has its diff——完成标准是每个 PR 都已分拣且都有 diff。步骤二 Screen无判断力的机械筛查筛查阶段应用 Automatic Rejection 规则中那些 diff 和 PR 元数据能直接回答、不需要编辑判断的部分。其中一条规则需要额外查询——近期已关闭的重复 PRgh pr list --repo vinta/awesome-python --state closed \ --search project name --limit 10即按项目名搜索最近关闭的 PR命中则按重复关闭。被筛掉的 PR 直接跳到步骤四作为一次 close 处理理由就是它违反的那条规则。对每个存活 PR技能还要求把目标用例对照当前 README 重新解析一遍理由很实际diff 的上下文行显示的是 PR 写作时的基线代码而从提交到评审README 可能已经变了——PR 作者写入时用例没满评审时可能已经满员。这里有一个衔接设计存在合并冲突的 PR 被标记后带入 Merge 分支由步骤四就地吸收解决而不是在筛查阶段就丢弃。完成标准每个存活 PR 都能说出自己的目标用例section — subcategory。步骤三 Judge按用例分组并委托准入判断机械筛查无法回答这个项目配不配得上这个 slot这一步把工作委托给另一个技能。首先按目标用例分组为同一用例提出条目的多个 PR 竞争的是同一批 slot所以它们必须一起评审ride one invocation避免各自判断时互相 unaware。对每个分组以如下形状的参数调用audit-the-list技能定义见 .claude/skills/audit-the-list/SKILL.mdJudge proposed entries names, each with its PR number for the section — subcategory use case. Evidence and Verdicts steps only; report the verdicts back. No preview page, no README changes, no commits.注意参数中的三重约束只执行 audit-the-list 的Evidence 和 Verdicts 两个阶段拉取下载量、仓库状态、PyPI 元数据等证据然后逐条给裁决不要预览页面、不改 README、不提交——因为 PR 评审场景下裁决对象是拟议条目而非现有 README 内容把裁决报告回来。每个 PR 的裁决是 merge 或 close必须基于拉取到的证据。当用例已满员时一个 merge 裁决必须点名被挤出的条目。还有一种第三种结果没有当前用例能容纳的条目是结构问题——它带着证据被带入 Act 阶段由维护者决定新建子分类并合并、关闭、还是继续挂着。完成标准每个存活 PR 都持有带理由的裁决。步骤四 Act关闭与合并两条执行臂裁决由维护者逐条确认后执行分为两条臂Close 臂带草案评论的人工确认对每个要关闭的 PR技能通过AskUserQuestion呈现起草好的关闭评论——评论写明理由并链接 CONTRIBUTING.md。交互细节有两点值得注意每次调用最多批量 4 个 PR并维护一个哪些裁决已问过的清单维护者的回答经常是自定义文本而那段文本本身就是决定可能改评论措辞也可能改变裁决。AskUserQuestion 提供三个选项用这条评论关闭 / 不带评论关闭 / 保持开放。确认后的命令gh pr close number --repo vinta/awesome-python --comment comment # 或无评论直接关闭 gh pr close number --repo vinta/awesome-pythonMerge 臂干净合并与本地冲突解决无冲突的 PR 直接gh pr merge number --repo vinta/awesome-python --merge有冲突的 PR 走本地合并保留贡献者署名GitHub 仍会标记 PR 为已合并git fetch origin pull/number/head git merge FETCH_HEAD # 使用标准信息 Merge pull request #number from owner/headRef解决冲突的原则是把条目放到正确的位置——这本身就是一次编辑判断而非机械解冲突。无论哪条路径push 前都要按 CONTRIBUTING 规则对账reconcile目标 section然后跑测试并提交移除裁决中被挤出的条目修正新条目的显示名应为 PyPI 包名便于pip install直接复制和 Entry Ordering 位置obvious choices 在前按 PyPI 月下载量降序challengers 在后stdlib 模块在用例内最前无下载信号的条目在其层级内按字母序垫底——位置即标记条目文本里没有 tier 标记运行make test对应 Makefile 中的uv run pytest website/tests/ -v提交。这里有一条明确的责任划分add-only diff 却需要挤出旧条目是正常情况——移除是评审这一步的职责不是贡献者的职责。贡献者只提交自己的条目评审侧负责一进一出中的出一。步骤五 Report终态核对与汇报最后产出一张汇总表PR 编号、裁决、已执行的动作外加 needs-human 清单。完成标准是一条封闭性检查每个拉取到的 PR 都恰好结束于一种状态——已合并且 section 已对账、已关闭、或保持开放kept open、needs-human、或结构问题待决。kept open 的 PR 会在下一次运行时再次冒出来——这正是它的目的。技能不追求一次性清空队列而追求每个 PR 状态可追踪被搁置的 PR 是显式状态而非遗漏。设计要点这个工作流做对了什么从技能文件与配套规则文档的结构看这套设计有几个可迁移到任何维护型 Agent 技能的要点规则与过程解耦SKILL.md 只写做什么、按什么顺序、何时委托、何时停下来问人什么算合格、什么算重复全部指向 CONTRIBUTING.md。改规则不需要改技能技能升级也不会产生第二份规则拷贝。机械判断与编辑判断分层Screen 阶段只做元数据可回答的检查空描述、重复、多条目 PRJudge 阶段才引入需要证据拉取的编辑判断且通过委托复用 audit-the-list 技能已有的证据管线ClickPy 下载量扫描、gh api仓库状态、PyPI 元数据校验而不是重写一遍。委托时收紧作用域调用 audit-the-list 的参数明确限定Evidence and Verdicts steps only并用三个否定句封住副作用no preview page, no README changes, no commits——跨技能调用时显式裁剪对方流程避免审计技能默认的维护者预览 提交路径被误触发。人工是裁决点而非橡皮图章Close 臂的评论由人确认且人的自定义文本即决定Merge 臂的冲突解决、结构问题新建子分类都留给人维护者的裁决最终生效与 audit-the-list 中their verdicts are final一致。幂等的失败重放needs-human 与 kept-open 的 PR 每轮重跑都会重新出现队列永远可重入——Agent 运行中断或人类拖延都不导致 PR 丢失。相关文件与运行方式这个技能是.claude/skills/下三个技能之一围绕同一套规则文档协作文件职责.claude/skills/review-prs/SKILL.md本文主题PR 队列的评审工作流.claude/skills/audit-the-list/SKILL.md对 README 现有条目做周期性审计被 review-prs 委托做证据与裁决.claude/skills/preview-verdicts/SKILL.md生成维护者交互式 keep/drop 预览页review-prs 场景下明确不调用它配套的事实源CONTRIBUTING.md规则、CONTEXT.md术语表、CLAUDE.md 与 AGENTS.md保持同步的 Agent 入口规则、docs/adr/0001-shortlist-not-catalog.md精选清单定位的决策记录。运行前提仓库内已安装 Claude Code技能通过.claude/skills/目录自动发现并已配置ghCLI含 PR 读写权限与git。技能在维护者要求review PRs / process the PR queue / 判断某 PR 是否该合并时触发可传 PR 编号参数指定范围。仓库本地测试入口为make test等价于uv run pytest website/tests/ -v合并路径在 push 前依赖它通过。需要说明的适用边界本文描述的是仓库当前.claude/skills/review-prs/SKILL.md的内容技能中的--repo vinta/awesome-python是上游仓库标识fork 使用时应替换为对应仓库技能本身不改动 README.md 的条目规则——若准入规则上限数值、tier 定义等调整以 CONTRIBUTING.md 为准技能流程无需变更。【免费下载链接】awesome-pythonThe definitive list that answers I want to do X in Python, which tool should I use?项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考