Streamlit 合并前 PR 收尾自动化finalizing-pr 技能全流程深度解析【免费下载链接】streamlitStreamlit — A faster way to build and share data apps.项目地址: https://gitcode.com/gh_mirrors/st/streamlit导读finalizing-pr是 Streamlit 仓库.claude/skills/finalizing-pr/SKILL.md中面向 AI 编码代理Agent的PR 收尾技能定义当开发分支上的改动准备合并进目标分支时它驱动 Agent 以完全自主的方式依次完成构建安装、文档更新、代码简化、自动修复、质量检查、变更评审、PR 创建/更新、AI 复审循环与指标上报最终产出可直接合并的 Pull Request。读完本文你将掌握 Streamlit 官方从代码完成到合并就绪的 13 步标准流水线理解make all、make autofix、make check、E2E_CHECKtrue等关键命令的职责划分并能在自己的项目中复刻这套机器人式收尾工作流。一、技能定位从改动完成到合并就绪的自动化网关该技能定义文件的元信息Frontmatter给出了明确的触发语义名称finalizing-pr描述通过简化代码、运行检查、评审变更并在需要时创建 PR最终确定用于合并的分支改动当改动准备好合并进目标分支时使用。其核心执行原则只有两条却定义了整套工作流的基调完全自主Be fully autonomous不要停下来等待人工确认。从当前状态一路推进到合并就绪的 PR中间不得有人为停顿任何悬而未决的问题或歧义以 PR 对话区Conversation tab评论的形式记录而不是阻塞流程。前台执行 同一模型所有子代理subagent必须在前台运行除非另有说明逐个等待其完成后才能进入下一步且每次启动子代理都必须使用与当前会话相同的模型model: inherit即不覆盖模型参数不得擅自切换到更快或更弱的模型除非用户明确要求。这套自主但不失控的设计正是 Streamlit 仓库为 AI 协作开发设立的纪律性约定。二、13 步工作流全景一张图看懂收尾流水线技能文档按顺序定义了 13 个步骤构成完整的收尾闭环步骤动作关键命令 / 技能1构建并安装make all2更新内部文档/updating-internal-docs技能后台3简化改动simplifying-local-changes子代理4自动修复make autofix5第一轮检查/checking-changes技能make check6评审变更reviewing-local-changes子代理7处理评审反馈逐条采纳或跳过8第二轮检查E2E_CHECKtrue make check9创建或更新 PRgh pr create/gh pr view10上传中间产物/sharing-pr-agent-artifacts技能11AI 评审与修复循环≤5 次ai-review标签 fixing-pr子代理12最终 AI 评审ai-final-review标签仅一次13上报 Agent 指标uv run python scripts/log_agent_metrics.py --post重要豁免规则对于小改动文档微调、纯测试改动、一行式修改等 mini-changes文档明确允许跳过步骤 1、2、3、6、7、8——即无需构建、无需内部文档更新、无需代码简化与人工评审直接进入自动修复、检查与 PR 环节避免为小改动付出不成比例的流程成本。三、步骤 1–3构建、文档同步与代码简化3.1 构建并安装make all第一步在子代理中执行make all确保构建与安装处于最新状态然后等待其完成再继续。从仓库根目录的 Makefile 可以看到all目标的真实组成.PHONY: all # Install all dependencies, build frontend, and install editable Streamlit. all: init frontend即all由init与frontend组成其中init又展开为python-init frontend-init protobuf见 Makefile 第 72-74 行的注释。这意味着make all实际完成Python 依赖安装uv、前端依赖安装、protobuf 生成、前端构建以及 Streamlit 的可编辑安装。这条命令保证了后续所有检查都运行在最新构建产物之上。3.2 更新内部文档/updating-internal-docs后台运行在后台子代理中运行/updating-internal-docs技能指示它针对本次本地改动自动修复内部文档问题。该技能的完整定义位于 .claude/skills/updating-internal-docs/SKILL.md其职责是将内部文档**/AGENTS.md、**/README.md、.claude/skills/*/SKILL.md、wiki/**/*.md、CONTRIBUTING.md以及随库分发的lib/streamlit/.agents/skills/下的打包技能等与当前代码库状态逐一核对修复过期OUTDATED、错误INCORRECT、版本不一致VERSION_MISMATCH、缺失MISSING、死链BROKEN_LINK与不一致INCONSISTENT六类问题。特别地当 PR 新增或变更 Streamlit 功能新 widget、API 变更、弃用、新布局/主题能力、性能相关改动时需要同步更新打包技能中的参考文档。3.3 简化改动simplifying-local-changes子代理运行simplifying-local-changes子代理清理并简化代码改动等待完成后再继续。这一步对应提交给评审者的代码应当最小、最清晰的工程纪律与仓库中 wiki/pull-requests.md 强调的只描述重要改动、省略显而易见的内容一脉相承。四、步骤 4–5自动修复与第一轮质量检查4.1 运行 autofixmake autofix在子代理中运行自动修复解决格式与 lint 问题make autofix从 Makefile 第 806 行附近的autofix目标可以看出它覆盖的修复范围相当完整Python 侧uv run ruff check --fix继续处理不可自动修复的错误make python-format前端侧make frontend-init、make frontend-format、yarn lint:fix、yarn knip --fix --allow-remove-filesKnip 负责未使用导出与未使用依赖分析依赖锁定yarn dedupe去重yarn.lock杂项make update-notices以及全量 pre-commit 手动钩子失败不阻断。4.2 第一轮检查/checking-changes→make check运行/checking-changes技能其定义见 .claude/skills/checking-changes/SKILL.md来校验改动核心命令是make checkcheck目标见 Makefile 第 653 行的设计要点通过scripts/get_changed_files.pyget_changed_files.py动态获取变更文件只对变更文件执行格式、lint、类型、单元测试检查前端检查oxfmt 格式化、oxlint lint、knip、类型、测试在后台并行运行Python pre-commit Python 测试在前台执行支持两个环境变量FAST_CHECKtrue跳过 mypy、前端类型与单元测试E2E_CHECKtrue额外运行变更相关的 e2e 测试。技能文档特别强调此步骤只运行make check不要运行其他检查发现问题后先修复再继续。只有在make check全部通过时工作才算完成。五、步骤 6–8评审反馈闭环与第二轮检查5.1 评审变更reviewing-local-changes运行reviewing-local-changes子代理评审改动等待完成并阅读评审输出。该子代理定义位于仓库.claude/agents/目录从 updating-internal-docs/SKILL.md 可知其评审清单部分由scripts/assets/code-review-instructions.md生成。5.2 处理评审反馈步骤 7对步骤 6 的每条建议执行二元决策有效且能提升代码质量→ 落实该改动不适用或会造成过度设计→ 跳过并给出简短理由。这一接受 / 拒绝并说明理由的机制既保证评审意见被认真对待又防止为迎合评审而引入不必要的复杂度。5.3 第二轮检查E2E_CHECKtrue make check再次运行/checking-changes技能但这次带上前端 e2e 覆盖E2E_CHECKtrue make check与第一轮相比增加了对变更相关 e2e 测试的运行。技能文档给出一个实用提醒快照snapshot不匹配可以忽略因为快照需要人工更新。从 checking-changes/SKILL.md 可以确认e2e 默认不包含在make check中E2E_CHECKtrue是显式开启选项。六、步骤 9创建或更新 PR——分支、模板与标签规范6.1 分支前提文档给出一个关键前置提醒如果当前在develop分支上必须先按 wiki/pull-requests.md 中的命名规范创建新分支。该 wiki 规定主分支为develop分支命名格式为{type}/{brief-description}kebab-casetype 取feature、fix、refactor、chore、docs如feature/add-height-parameter-plotly-charts命名要具体3–8 个词不要在分支名中带 issue 编号。6.2 检查是否已有 PRgh pr view --json number,title,url6.3 创建 PR若无 PR按 wiki/pull-requests.md务必阅读与/reviewing-pr-description技能的标题/描述规范创建并以.github/pull_request_template.mdpull_request_template.md为依据填写正文。仓库中的 PR 模板包含三个核心区块## Describe your changes、## GitHub Issue Link (if applicable)、## Testing Plan。关联 issue在 PR 描述中加入- Closes #12345形式的行用于关闭已知 issue。必需标签Required labels——这是技能文档给出的一张关键配置表类别选项Impactimpact:users影响用户行为或impact:internal无用户行为变化Change typechange:feature、change:bugfix、change:chore、change:refactor、change:docs、change:spec、change:other注意仅含 spec/设计文档的 PR标记change:spec豁免Impact 标签要求。技能文档给出的完整创建命令非交互模式# 先把分支推送到 origin非交互 gh pr create 的前置条件 git push -u origin HEAD # 创建 PR gh pr create --base develop --title [type] Description --body $(cat EOF ## Describe your changes - Change 1 - Change 2 ## GitHub Issue Link (if applicable) - Closes #12345 ## Testing Plan - [x] Unit Tests (JS and/or Python) EOF ) --label impact:users,change:feature若 PR 已存在则检查描述是否需要根据当前改动更新。6.4 PR 描述规范速查wiki/pull-requests.md 为标题与描述提供了配套标准PR 标题[type] Description of change≤63 字符适配 squash-merge 提交主题描述核心原则Highlight what matters. Omit the obvious.——测试、类型、验证、lint 等能从代码看出的内容一律省略只保留最有影响力和非显而易见的决策2–4 条要点为宜禁止元评论不要写 This PR...、I added... 这类无信息量的开头直接陈述改动本身测试计划Python 单测在lib/tests/**/*.py前端单测在frontend/**/*.test.ts(x)e2e 测试在e2e_playwright/**/*_test.py按实际改动的测试文件逐条说明覆盖内容。七、步骤 10上传中间产物若存在相关中间产物work-tmp/中的 spec、计划、实现笔记或specs/下未跟踪的文件运行/sharing-pr-agent-artifacts技能将它们推送到 wiki并在 PR 上评论附上链接。这一步保证了设计文档、实现计划等过程资产不会随合并而丢失可与specs/目录中的系列产品 spec 文档相互印证。八、步骤 11–12AI 评审循环与最终评审8.1 AI 评审与修复循环最多 5 轮这是整个工作流中自动化程度最高的一环伪代码逻辑如下for iteration 1 to 5: 1. 触发 AI 评审给 PR 打上 ai-review 标签 2. 前台运行 fixing-pr 子代理等待 CI、修复失败、处理评审评论 3. 检查最新 AI 评审结论 4. 若结论为 approved → 退出循环触发方式gh pr edit --add-label ai-review读取评审结论AI 评审以github-actionsbot 的 PR review 形式发布结果其中包含隐藏标记!-- streamlit-ai-review run_id... timestamp... --技能文档给出了提取最新评审结论的完整命令PR_NUM$(gh pr view --json number -q .number) # 从最新 AI 评审中获取结论 gh api --paginate repos/streamlit/streamlit/pulls/${PR_NUM}/reviews \ | jq -s [.[][] | select(.user.login github-actions[bot] and (.body | contains(!-- streamlit-ai-review)))] | sort_by(.submitted_at) | last | .body \ | grep -A2 ## Verdict结论区包含一个加粗关键词决定循环走向**APPROVED**→ 退出循环PR 就绪**CHANGES_REQUESTED**→ 继续迭代处理反馈。文档特别提醒即使fixing-pr在APPROVED之后又推送了跟进 CI 修复也不要再开启新一轮迭代——这些提交已由 CI 覆盖但未经过 AI 评审。8.2 最终 AI 评审仅一次评审循环结束后应用一次ai-final-review标签gh pr edit --add-label ai-final-review gh run list --branch $(git branch --show-current) --workflow ai-pr-review.yml --status queued gh run list --branch $(git branch --show-current) --workflow ai-pr-review.yml --status in_progress等到该分支上出现queued或in_progress状态的ai-pr-review.yml工作流运行后再启动一次/fixing-pr如果还没有队列任务它会立即返回。无论步骤 11 是已通过还是耗尽迭代次数这一步都恰好执行一次且不得重复应用ai-final-review。/fixing-pr结束后提交并推送剩余改动。九、步骤 13上报 Agent 指标工作流最后一步把本次会话的 Agent 指标发布到 PR 正文uv run python scripts/log_agent_metrics.py --post从 scripts/log_agent_metrics.py 的模块文档字符串可以看到该脚本的完整用法skill_invocation、subagent_invocation、--stats与--post四个子命令其中--post负责把以 NDJSON 格式累积在work-tmp/agent-metrics下的技能/子代理调用指标统计结果发布到 PR。这为 Streamlit 团队量化 AI 协作开发过程提供了数据支撑。十、关联技能图谱finalizing-pr 的协作网络finalizing-pr并非孤立存在它通过子代理与技能调用织成一张完整的开发协作网这些定义全部位于 .claude/skills 目录下被调用方所在位置在收尾流程中的角色updating-internal-docs.claude/skills/updating-internal-docs/SKILL.md步骤 2修复内部文档与代码库的漂移simplifying-local-changes.claude/agents/步骤 3清理简化代码改动checking-changes.claude/skills/checking-changes/SKILL.md步骤 5、8运行make check与E2E_CHECKtrue make checkreviewing-local-changes.claude/agents/步骤 6代码评审reviewing-pr-description.claude/skills/reviewing-pr-description/SKILL.md步骤 9评审 PR 标题与描述的可读性sharing-pr-agent-artifacts.claude/skills/sharing-pr-agent-artifacts/SKILL.md步骤 10上传中间产物到 wikifixing-pr.claude/agents/步骤 11、12等待 CI、修复失败、处理评审评论而 wiki/pull-requests.md 与 .github/pull_request_template.md 则是 PR 元数据的法律文本finalizing-pr在步骤 9 中强制要求先读前者再创建 PR。十一、落地实践如何在自己的仓库复刻这套收尾流水线从 Streamlit 的实现中可以抽象出可移植的四条设计原则把质量关卡做成一条命令用make check将格式、lint、类型、单测收敛到一个入口并支持E2E_CHECKtrue按需扩展——新仓库只需把对应工具链映射到自己的check目标即可。修复与检查分离make autofix负责一切可自动修复的问题lint 自动修复、格式化、依赖去重、pre-commitmake check只做校验二者职责清晰、可反复执行。用标签驱动自动化评审ai-review/ai-final-review标签触发 CI 中的 AI 评审工作流ai-pr-review.yml以机器人 review 的隐藏标记 结构化 Verdict 作为机器可读的结论配合fixing-pr子代理完成评审→修复→再评审闭环。小改动走快速通道通过明确的跳过清单文档微调、纯测试、一行式改动跳过构建/评审等步骤避免流程成本超过改动本身的价值。需要留意的是这套流程中的部分自动化环节ai-pr-review.yml工作流、github-actions bot 评审依赖 Streamlit 仓库的 CI 基础设施在自己的仓库复刻时需替换为对应的 CI 配置而make目标、标签规范、PR 模板与分支命名等约定则可以原样借鉴。结语finalizing-pr把PR 收尾这一常被忽视、却又决定合并效率的环节定义成了一条可重复、可审计、完全自主的 13 步流水线。它一端连接着make all/make autofix/make check等构建与质量基础设施另一端连接着ghCLI、标签体系与 AI 评审工作流中间由simplifying-local-changes、reviewing-local-changes、fixing-pr等子代理串联执行。理解这条流水线不仅能帮你快速上手 Streamlit 的贡献流程更能为任何AI 辅助开发项目提供一份经过实战检验的合并前质量门禁设计蓝图。【免费下载链接】streamlitStreamlit — A faster way to build and share data apps.项目地址: https://gitcode.com/gh_mirrors/st/streamlit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考