Streamlit 仓库 Pull Request 创建实战指南：分支命名、PR 描述与 gh 工作流全解析

数据可视化后端前端【免费下载链接】streamlitStreamlit — A faster way to build and share data apps.项目地址https://gitcode.com/gh_mirrors/st/streamlit点击查看免费下载本文基于 Streamlit 官方仓库内为 AI Agent 设计的creating-pull-requests技能文档.claude/skills/creating-pull-requests/SKILL.md完整还原向streamlit/streamlit仓库提交 Pull Request 的标准流程从选择自动化模式、执行 git 分支与提交工作流到撰写符合社区规范的标签、标题、描述最终调用 GitHub CLI 创建 Draft PR。读完本文你将掌握一套可直接照做的 PR 提交流程以及 Streamlit 团队对 PR 可读性、标签约束与测试计划的全部硬性要求。技能文档定位Agent 如何被引导创建 PR.claude/skills/creating-pull-requests/SKILL.md是 Streamlit 仓库为 AI 编码助手如 Claude Code 等提供的 Agent Skill其 frontmatter 明确描述了使用场景--- name: creating-pull-requests description: Creates a draft pull request on GitHub with proper labels, branch naming, and description formatting. Use when changes are ready to be submitted as a PR to the streamlit/streamlit repository. ---该技能的适用前提是代码改动已经完成并通过本地校验可参考配套技能checking-changes/SKILL.md中make check的流程此时 Agent 应引导用户将改动正式提交为 PR。文档给出了三条不可逾越的核心约束必须等待用户批准后才能运行gh pr create必须在创建前向用户完整展示PR 内容必须遵循下文详述的写作与标签规则。也就是说这是一个人机协作的流程Agent 负责执行繁琐的 git 操作与文案起草用户保留最终审核与触发创建的权利。Step 1选择工作模式先询问再行动技能文档要求 Agent 在动手之前先向用户确认采用哪种模式并提供两个选项Already Ready已就绪用户已有功能分支所有改动已提交并推送Agent 只需验证就绪状态后直接起草 PRAutomated全自动由 Agent 负责完成分支创建、提交与推送的完整流程。这一步的意义在于尊重用户对 git 操作的控制权跳过询问直接操作可能覆盖用户的分支状态因此等待用户响应后再进入 Step 2 是强制动作。Step 2执行 git 工作流Mode A改动已就绪——仅验证当用户选择Already Ready时Agent 只做三项就绪性检查git branch --show-current git status git branch -r | grep $(git branch --show-current)第一条确认当前分支名第二条确认工作区状态无未提交改动第三条确认该分支已推送到远端git branch -r列出远程分支后按当前分支名过滤。三项全部符合预期后与用户确认即可进入 Step 3。Mode B全自动——创建分支并推送当用户选择Automated时假设用户已通过git add暂存了改动Agent 依次执行git status git checkout develop git checkout -b {type}/{descriptive-name} git commit -m {imperative-verb} {what} {where} git push --set-upstream origin $(git branch --show-current)流程从developStreamlit 的主分支见 wiki/pull-requests.md拉出新的功能分支提交后使用--set-upstream建立本地分支与远程分支的关联。仓库的.github/repo_meta.yaml也将develop列为主发布分支模式release_branches: develop, release/*印证了分支策略。分支命名规范分支名必须采用 kebab-case全小写、连字符分隔格式为{type}/{brief-description}类型含义示例feature新功能feature/add-height-plotly-chartsfix缺陷修复fix/dataframe-memory-leak-scrollingrefactor重构refactor/element-width-height-logicchore杂务依赖升级等chore/update-react-dependenciesdocs文档变更docs/update-contributing-guidewiki/pull-requests.md 进一步补充描述部分应具体且具有辨识度3-8 个词并避免在分支名中夹带 issue/ticket 编号——编号信息应放在 PR 描述中。提交信息规范提交信息采用imperative verb what where三要素结构首行 ≤ 50 字符使用祈使语气写Add而非Added末尾不加句号可选正文每行 ≤ 72 字符。示例Add height parameter to plotly charts、Fix memory leak in dataframe scrolling。这一约束同时服务于 PR 标题与 squash-merge 后的提交历史可读性。Step 3起草并创建 PR在起草标题与描述时文档要求参考reviewing-pr-description技能 的标题/描述评审原则从一开始就做到清晰简洁。3.1 确定标签Labels所有 PR 都必须携带两个标签分类如下类别可选值影响Impactimpact:users影响用户行为或impact:internal不改变用户行为变更类型Change typechange:feature·change:bugfix·change:chore·change:refactor·change:docs·change:spec·change:other特例仅包含 spec/设计文档的 PR 可打change:spec标签并豁免impact:*要求但不允许为含代码改动的 PR 使用change:spec。这套约束并非纸面规范而是有 CI 强制执行的。仓库中的.github/workflows/require-labels.yml定义了一个 GitHub Action 工作流在任何 PR 的opened / labeled / unlabeled / synchronize事件上运行校验三组规则do-not-merge不允许出现该标签恰好 0 个change-descriptionchange:*系列中恰好命中 1 个impact-definedimpact:users/impact:internal中恰好命中 1 个。工作流脚本中还实现了与技能文档一致的豁免逻辑当检测到change:spec标签时impact-defined检查被跳过否则任一规则不满足都会通过core.setFailed让 CI 失败。因此标签不是可选项而是 PR 合并前的硬门槛。3.2 生成 PR 标题标题格式为[type] Description of change长度 ≤ 63 字符以便适配 squash-merge 的提交主题。示例[feature] Add height parameter to plotly charts [fix] Extra padding on button [refactor] Layout config validation logic标题应能脱离正文独立表达变更内容——正如reviewing-pr-description技能所述它会在 commit 列表和 changelog 中被单独阅读。3.3 编写 PR 描述Agent 需要先读取.github/pull_request_template.md获取必需章节再逐一填写。该模板包含以下部分Describe your changes描述你的变更GitHub Issue Link (if applicable)关联 issue可选Testing Plan测试计划为何无需额外测试、单元测试JS/Python、E2E 测试、是否需要手动测试Contribution License AgreementApache 2.0 贡献许可声明写作规则突出重点省略显而易见变更要点用2-4 条 bullet概括宁少勿滥禁止元评论如 This PR...、We have...、I added...直接陈述变更内容不要罗列新增测试、更新类型、补充校验、修复 lint 这类代码里一眼可见的内容必须解释非显然的决策弃用deprecation、单位选择、回退fallback行为、权衡取舍。好的示例Addsheightparameter tost.plotly_chart()usingHeighttype system.Deprecatesuse_container_height(removed after 2025-12-31)糟糕的示例逐条罗列每个改动Addedheightparameter to signatureUpdated layout config dataclassAdded validation for height valuesAdded unit testsreviewing-pr-description技能补充了九条评审原则可供自查核心包括首句直接点明变更及其目的、解释意图而非逐行复述 diff、用主动语态点出行为主体Deprecatesuse_container_width 优于被动句式、避免无上下文的内部术语或缩写。仓库 wiki 中则用三个自问句概括取舍标准代码里是否显而易见是则省略是否最具影响力是则保留是否涉及非显然决策是则附上解释。测试计划Testing section按变更文件自动检测根据本次变更涉及的文件路径在 PR 模板中勾选对应的测试类型变更文件模式测试类型lib/tests/**/*.pyPython 单元测试frontend/**/*.test.{ts,tsx}前端单元测试e2e_playwright/**/*_test.pyE2E 测试若没有测试文件变更需在模板中说明原因例如 Documentation-only changes, no behavior modifications。Manual testing手动测试保持不勾选留给用户自行填写。同时建议在描述中列出测试文件及其覆盖内容例如- lib/tests/streamlit/elements/plotly_chart_test.py — Tests height parameter - e2e_playwright/st_plotly_chart_test.py — Visual regression tests for height这些路径模式与仓库实际结构完全吻合Python 单元测试位于 lib/tests/streamlit/elements/plotly_chart_test.py其中包含test_use_container_width_deprecation、test_plotly_chart_width_combinations等参数化用例E2E 测试位于 e2e_playwright/st_plotly_chart_test.py使用 Playwright 的快照对比函数assert_snapshot做视觉回归。若改动还涉及格式化、lint、类型检查可先运行make check或E2E_CHECKtrue make check连带变更的 e2e 测试自证质量。3.4 写盘并交用户审核Agent 将完整的 PR 内容frontmatter 描述写入work-tmp/pr_description.md--- title: [PR title from 3.2] labels: impact:{users|internal}, change:{type} --- [PR description from 3.3]随后向用户发出如下确认原文措辞Ive written the PR details towork-tmp/pr_description.md. You can edit the title, labels, or description directly in that file. Reply yes when ready to create the PR, or provide feedback for changes.这一步与核心约束创建前必须展示完整 PR 内容呼应用户可以直接编辑文件中的标题、标签或描述Agent 不得在用户确认前越权创建。3.5 创建 PR仅在用户批准后读取用户可能已编辑过的work-tmp/pr_description.md解析 frontmatter 与正文然后调用 GitHub CLI# Parse frontmatter from the reviewed file title$(grep ^title: work-tmp/pr_description.md | sed s/^title: //) labels$(grep ^labels: work-tmp/pr_description.md | sed s/^labels: // | sed s/, /,/g) # Extract body (everything after the closing --- of frontmatter) awk /^---$/{if(count2) flag1; next} flag work-tmp/pr_description.md work-tmp/pr_body.md # Create PR using parsed values gh pr create \ --title $title \ --body-file work-tmp/pr_body.md \ --base develop \ --label $labels \ --draft # Clean up temporary files rm work-tmp/pr_description.md work-tmp/pr_body.md关键参数说明--base developPR 的目标分支固定为 Streamlit 主分支develop--draft以Draft草稿状态创建便于在正式请求评审前继续完善--label $labels一次传入多个标签逗号分隔故先用sed把,归一为,--body-file从解析出的正文文件读取描述避免 shell 转义问题。创建成功后删除两个临时文件流程结束。配套参考完整的 PR 规范体系技能文档的 Reference 指向仓库内的 Pull requests wiki那里汇总了本文涉及的全部规范的快速参考包括主分支为develop、分支/提交/标题的格式与长度约束、变更描述原则、双标签体系、以及按文件路径识别测试类型的对照表。此外本技能与仓库内其他 Agent Skills 形成了完整的 PR 生命周期闭环.claude/skills/reviewing-pr-description/SKILL.md创建前用其原则自审标题与描述的可读性.claude/skills/checking-changes/SKILL.md提交前运行make check完成格式化、lint、类型检查与单元测试.github/pull_request_template.mdPR 描述必须覆盖的官方模板章节.github/workflows/require-labels.yml标签合规的 CI 强制校验实现。理解这套流程后无论是人工提交还是借助 AI Agent 自动提交向streamlit/streamlit贡献代码时都能一次通过标签校验并产出让 reviewer 一眼读懂的高质量 PR。赞分享数据可视化后端前端【免费下载链接】streamlitStreamlit — A faster way to build and share data apps.项目地址https://gitcode.com/gh_mirrors/st/streamlit点击查看免费下载相关推荐vLLM-Omni TTS 模型集成实战从参考实现到生产级流式服务的完整路径vLLM Omni TTS 模型集成实战从参考实现到生产级流式服务的完整路径 本文面向在 vLLM Omni全模态推理框架中接入全新 TTS 模型的开发者人工智能大模型模型推理服务多模态语音音频媒体生成本地部署tldraw 仓库 Pull Request 创建与更新完整工作流从分支准备到评审提交pr / write-pr 技能指南tldraw 仓库 Pull Request 创建与更新完整工作流从分支准备到评审提交pr / write pr 技能指南 导读 本文基于 tldraw前端UI组件LoopmacOS 径向菜单窗口管理从入门到熟练的完整指南LoopmacOS 径向菜单窗口管理从入门到熟练的完整指南 Loop 是一款免费开源GPLv3 协议的 macOS 窗口管理工具核心是径向菜单按住触发桌面应用上一篇终极指南Pandoc复杂表格处理引擎的架构解析与技术实现下一篇深入理解Magpie的缩放算法Bilinear、Bicubic与Lanczos对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考