ZeroClaw GitHub PR 技能实战：从模板驱动的 PR 创建到智能更新与作者卫生检查

ZeroClaw GitHub PR 技能实战从模板驱动的 PR 创建到智能更新与作者卫生检查【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw本篇技术指南围绕 ZeroClaw 仓库中的github-pr技能.claude/skills/github-pr/SKILL.md展开系统讲解如何用一条自然语言指令完成创建新 PR与更新既有 PR两类任务包括以.github/pull_request_template.md为唯一事实来源的模板解析与预填、基于变更面的验证证据收集cargo fmt/cargo clippy/cargo test/ 文档链接门禁、以及禁止机器人署名bot/AI attribution的作者卫生检查。读完本文你将掌握 ZeroClaw 中一套可复现的 PR 自动化工作流并理解其与仓库内 CI 门禁、路径/大小标签自动机、评审会话与 squash-merge 技能如何协同构成从分支到合入的完整闭环。技能定位与触发场景github-pr技能是 ZeroClaw 为 AI 助手编写的 Agent 技能skill核心职责只有两件事创建带着完整模板正文的 PR以及更新既有 PR 的标题、正文章节、标签与评论。技能的触发非常宽泛——用户说submit this for review、push and open for merge甚至没有明确出现 PR 字样时只要意图是提交变更供评审都应命中本技能而当用户说出 open a new PR 这类明确创建意图时则进入创建模式。从源码结构看该技能与同目录下的 github-issue、github-issue-triage、github-pr-review-session、squash-merge 共同构成 ZeroClaw 的 GitHub 协作技能族。其中 squash-merge 技能中有一张完整的端到端协作链路表明确标注了各技能的分工边界选单/分诊用github-issue-triage建 issue 用github-issue分支就绪后开 PR / 更新 PR 用github-pr合入前评审用github-pr-review-session最后落地 master 用 squash-merge。这说明github-pr是整条流水线中提交环节的标准入口。双模式识别Open 与 Update技能支持两种模式模式判定完全依赖上下文Open创建当前分支没有已打开的 PR或用户明确要求新建。Update更新当前分支已存在打开的 PR且用户没有说 open a new PR此时默认进入更新模式。这一设计避免了重复建 PR 的常见事故只要分支上已有 PR助手应当接力而不是另起炉灶。共享步骤一PR 模板是唯一事实来源无论创建还是更新技能的第一步永远是读取并解析.github/pull_request_template.md绝不硬编码章节名、字段或顺序——因为模板会随时间演进技能必须始终反映其当前状态。解析时需提取四类信息##顶级章节标题PR 正文的一级结构每个章节内的要点、字段与提示语哪些章节标记为(required)必填vs 可选/推荐内联格式约定反引号选项、Yes/No 字段等。对照仓库中的 .github/pull_request_template.mdZeroClaw 的 PR 模板由以下必填/条件章节构成这正是技能需要解析并逐节填充的对象章节必填性关键字段## Summary必填Base branch固定master、What changed and why2~5 条 bulletsdiff 说明 what正文解释 why、Scope boundary、Blast radius、Linked issue(s)、Labels## Testing (required)必填### How you can testA/B 验证master 旧行为 vs 本分支新行为、### How I testedCI 依据、本地命令输出尾段、视觉界面证据## Security Privacy Impact (required)必填6 个 Yes/No 字段权限、外网调用、密钥、PII、提示注入等任一 Yes 需附风险与缓解说明## Compatibility (required)必填Backward compatible、Config/env/CLI surface、Rust/MSRV/toolchain floor## Rollback (required for medium/high-risk PRs)条件必填低风险默认git revert sha中高风险须填快速回滚命令、功能开关、可观测失败症状## Supersede Attribution仅当使用Supersedes #被取代 PR 与作者、承继范围、是否追加人工Co-authored-by模板末尾还有两条贯穿全文的硬约束Labels 只存在于 GitHub 标签 UI不写在正文里路径标签由.github/labeler.yml驱动的 PR path labeler 负责size:*标签由 PR size labeler 负责以及禁止在 PR 正文或提交信息尾部添加 bot/AI 署名页脚人工 co-author trailer 仅在取代supersede他人贡献场景下按隐私契约允许。共享步骤二作者卫生检查Authorship HygieneZeroClaw 的 PR 正文与最终合入的提交信息尾部不得包含任何 bot/AI 署名例如Co-authored-by: Claude ...、Co-authored-by: Codex ...或Created with Claude Code/Generated with Claude Code这类生成工具页脚。技能在开 PR 前必须扫描本地提交信息与草拟的 PR 正文git log origin/master..HEAD --format%B | rg -i (^[[:space:]]*(Co-authored-by|Co-Authored-By):.*(Claude|Codex|ChatGPT|Copilot|GitHub Copilot|Gemini|\[bot\]|dependabot|github-actions|web-flow|blacksmith|noreply(anthropic|openai)\.com)|^[[:space:]]*(Created with Claude Code|Generated with Claude Code)[[:space:]]*$)若命中则从展示或提交的 PR 文本中移除这些 trailer 与页脚。这里有一条重要的边界如果尚未推送的本地提交包含这些页脚必须先告知用户并征得同意才能重写提交历史绝不允许仅为清理署名而擅自改写已推送分支或贡献者分支。这条卫生检查会同时约束创建 PR和更新 PR两个模式与模板末尾的禁令、squash-merge 技能中合入前对$COMMITS的清洗逻辑构成三处一致的防线。模式一创建新 PR 的完整流程Step 1收集上下文并行执行以下命令为预填 PR 正文收集证据# 分支与提交上下文 git branch --show-current git log master..HEAD --oneline git diff master...HEAD --stat # 检查分支是否已推送 git rev-parse --abbrev-ref --symbolic-full-name {u} 2/dev/null # 环境信息用于验证证据 rustc --version 2/dev/null同时审阅变更文件与提交信息判断变更性质bug fix / feature / refactor / docs / chore以及受影响的子系统。这一判断将决定后续如何填写 Summary、Security 与 Compatibility 章节。Step 1a收集验证证据起草前必做起草 PR 正文之前必须确定覆盖变更面的证据。原则是新鲜的必要 CI 即可作为有效证据只要它运行在当前 head 上、覆盖相同的目标、功能集与行为边界就不必为了重复覆盖而再跑一遍本地 Cargo只为真实缺口补充本地检查例如只做过编译检查的平台、lint 任务覆盖不到的路径、未触发的桌面端覆盖、PR 矩阵之外的发布目标或 CI 过期/不可用的情况。Rust/代码变更的常用本地验证命令cargo fmt --all -- --check cargo clippy --all-targets -- -D warnings cargo test纯文档变更运行scripts/ci/docs_quality_gate.sh与scripts/ci/docs_links_gate.sh这两个门禁脚本均存在于仓库的 scripts/ci 目录docs_links_gate 负责校验文档内部链接完整性改动引导类脚本追加bash -n install.sh做语法检查仓库根目录的 install.sh 即为此类目标。证据记录要求写明依赖了哪些必要 CI 及其覆盖原因、已知缺口本地跑过的命令要粘贴相关输出尾段、失败与警告若某条命令故意跳过如平台受限必须用一行理由显式注明Skipped 而不解释是不可接受的。验证输出若出现任何WARN/ERROR/warning:行必须以评审者视角追查确认是 master 上已存在的根因或标记为开 PR 前必须处理的问题——不允许带着自己无法解释的警告去发 PR。若必要检查或本地命令失败应先修复再起草绝不在破损的树broken tree上写 PR。Step 2预填模板基于解析出的模板结构 收集到的上下文起草完整 PR 正文为模板中每个##章节依据提交、diff 与变更文件填写 bullet 与字段用字段描述与占位文本作为填写指引对 Yes/No 字段从 diff 推断例如没有改动src/security/下的文件安全影响大概率全为 No必填章节必须给出实质性回答可选章节若有足够上下文则填否则保留模板提示语按 Conventional Commits 风格起草 PR 标题例如feat(provider): add retry budget override、fix(channel): handle disconnect gracefully、chore(ci): update workflow targets展示或提交前应用共享的作者卫生检查。值得一提的是How I tested的填写必须诚实只写实际运行过的检查贴上真实输出尾段说明覆盖范围与剩余缺口或跳过的理由。不要把 pending 状态的 CI 当作证据也不要把没跑过的本地命令描述成通过。关于标题格式仓库有硬性 CI 门禁支撑.github/workflows/pr-title.yml会在 PR opened/reopened/edited/synchronize 时调用 scripts/check-pr-title.sh其校验正则要求type(scope): description且 type 限定为build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test之一、scope 必填。因此技能草拟的标题若不符合该格式即使助手放行CI 也会拒绝——预填时按此规范生成标题是从源头规避返工。Step 3展示草稿供评审向用户完整展示草稿格式固定为## PR Draft: title **Branch**: head - master **Labels**: suggested labels full body with all sections filled并请用户确认Heres the pre-filled PR. Review and let me know what to change, or say submit to open it. 之后迭代修改直到用户批准。Step 4推送并创建若分支尚未推送先推分支并设置上游跟踪git push -u origin branch用 HEREDOC 承载正文创建 PR避免引号与特殊字符转义问题gh pr create --title title --base master --body $(cat PR_BODY_EOF full body PR_BODY_EOF )若已商定标签添加标签gh pr edit number --add-label label1,label2将 PR URL 返回给用户。注意 base 固定为master这与模板中 Base branch:master(all contributions) 的约定一致也符合仓库所有 PR 工作流均以 master 为目标分支的事实参见.github/workflows/master-branch-flow.md。模式二更新既有 PR 的完整流程Step 1识别目标 PR优先级依次为用户显式给出 PR 编号/URL → 当前分支自动检测gh pr view --json number,title,body,labels,state,author,url,headRefName 2/dev/null→ 都失败则询问用户 PR 编号。识别后必须校验作者身份CURRENT_USER$(gh api user --jq .login) PR_AUTHOR$(gh pr view number --json author --jq .author.login)若当前用户不是 PR 作者立即停止并告知用户——这从机制上防止了越权修改他人 PR。Step 2拉取当前状态gh pr view number --json number,title,body,labels,state,baseRefName,headRefName,url,author,reviewDecision,statusCheckRollup,commits并展示摘要## PR #number: title **State**: open/closed/merged **Branch**: head - base **Labels**: label list **Checks**: pass/fail/pending **URL**: urlStep 3确定要更新的内容技能支持七类更新操作全部基于gh pr edit与gh pr comment操作命令编辑标题gh pr edit number --title new title编辑完整正文gh pr edit number --body new body添加标签gh pr edit number --add-label label1,label2移除标签gh pr edit number --remove-label label1编辑指定章节按##头解析正文 → 修改目标章节 → 重新提交完整正文添加评论gh pr comment number --body comment关联 issue编辑正文中的 linked-issue 章节新提交后的智能更新重新分析并建议章节更新Step 4处理正文章节编辑编辑指定章节时遵循最小改动原则按##头把当前 PR 正文解析为章节将用户请求与模板中对应章节匹配展示该章节的当前内容与拟替换内容diff 对比确认后只修改该章节重建完整正文并提交。Step 5新提交后的智能更新当用户推送新变更后要求同步 PR 描述识别新提交gh pr view number --json commits --jq .commits[].messageHeadline git log base..head --oneline git diff base...head --stat重新读取 PR 模板基于新变更判断哪些章节已过时——用模板的章节名与字段描述定位而不是依赖硬编码假设依据 Step 1a 的标准重新评估证据只重跑证据已过时、且新鲜必要 CI 无法覆盖的本地检查。技能特别强调过时的验证证据比没有证据更糟因为它会误导评审者提交前再次应用作者卫生检查逐章节展示拟更新内容确认后再应用。Step 6应用更新标题/标签类变更直接用gh pr edit的标志位正文变更用 HEREDOCgh pr edit number --body $(cat PR_BODY_EOF full updated body PR_BODY_EOF )评论变更用 HEREDOCgh pr comment number --body $(cat COMMENT_EOF comment text COMMENT_EOF )Step 7确认拉取并展示更新后的状态gh pr view number --json number,title,labels,url返回 PR URL 收尾。重要规则十条红线技能结尾明确了十条必须遵守的红线其中几条尤其值得注意每次填充或编辑 PR 正文前都必须读.github/pull_request_template.md绝不假设章节名、字段或结构——它是事实来源且可能变化更新时只修改请求的章节其余内容原样保留应用正文编辑前必须展示 diff逐章节对比当前 vs 拟改绝不在 PR 内容中包含个人/敏感数据——这是 ZeroClaw 的隐私契约merge gate绝不包含 bot/AI 署名页脚提交任何 PR 文本前执行作者卫生检查标签变更只用仓库中真实存在的标签不确定时先gh label list核实编辑前必须拉取最新正文避免覆盖并发变更clobber新 PR 必须先推送分支-u设置上游跟踪再创建。与仓库协作体系的协同关系从仓库源码与工作流配置看github-pr技能并非孤立存在其预填行为与 CI 自动机、评审与合入技能环环相扣标签自动化技能建议的标签仅作为参考实际由自动机接管——.github/workflows/pr-path-labeler.yml依据 .github/labeler.yml 中按路径映射的标签规则如channel:telegram命中src/channels/telegram.rs与crates/zeroclaw-channels/src/telegram.rsprovider:gemini命中 provider 相关源文件自动打路径/范围标签.github/workflows/pr-size-labeler.yml则运行 scripts/github/pr_size_label.py 依据 PR 元数据打size:*标签risk:*等人工标签由具备权限的维护者在侧栏设置。因此正文的 Labels 字段只做快照记录不承载标签管理职责标题门禁pr-title.yml工作流强制 Conventional Commits 带 scope 格式技能按同一规范草拟标题两者标准一致评审侧github-pr-review-session 会以.github/pull_request_template.md核对 PR 模板完整性template completeness check并遵循docs/book/src/contributing/pr-review-protocol.md中的评审协议——这意味着技能预填的质量直接决定评审能否顺利通过合入侧squash-merge 技能在合入时会再次执行与本文相同的 bot 署名清洗正则并把 PR 标题加工为PR_TITLE (#NUMBER)形式的 squash 提交主题强制要求 Conventional Commits 格式——技能预填的标题质量会沿用到最终落地 master 的提交上。适用前提与限制本技能面向 ZeroClaw 仓库的协作流程设计PR 目标分支固定为master标签体系、路径映射与模板结构均以仓库现状为准技能的指令以 bash/ghCLI 为基础执行环境需具备可用的ghCLI、git、rgripgrep以及 Rust 工具链cargo/rustc——其中rg用于作者卫生扫描cargo系列命令用于验证证据收集仓库为只读镜像形态时上述命令用于本地查看、验证与配置说明实际执行推送、建 PR、加标签等写操作需在具备相应权限的仓库副本上由用户触发。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考