尧图网站建设 
PX4-Autopilot 的 PR 提交流程技能从 Conventional Title 到 Summary/Problem/Solution 的工程化实践【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址: https://gitcode.com/gh_mirrors/px/PX4-Autopilot本指南围绕 PX4-Autopilot 仓库中的.agents/skills/pr/SKILL.md技能文件系统讲解该仓库 Pull Request 的规范化提交流程如何用type(scope): description撰写 PR 标题、如何用## Summary / ## Problem / ## Solution三段式组织 PR 描述、何时需要做 sanity build、以及 AI 助手在 PR 中的署名边界。读完你不仅能按 PX4 的规范提交 PR还能理解其背后的 CI 校验逻辑Tools/ci/check_pr_title.py与仓库约定CONTRIBUTING.md让提交一次通过审查。技能文件的定位一个薄适配层.agents/skills/pr/SKILL.md是 PX4-Autopilot 为 GPT 系编码助手如 OpenAI Codex准备的技能入口之一。仓库采用“薄适配层 共享工作流”的组织方式.agents/skills/下的技能文件负责调用方式的适配工具命名、输入来源、署名策略真正的完整工作流存放在.claude/skills/下的同名文件中如 .claude/skills/pr/SKILL.md被.agents/适配层直接引用这一设计在 .agents/README.md 中有明确说明四个适配器加载已有的受版本管理工作流而不是各自维护一份拷贝避免两处漂移。因此理解pr技能需要把适配层与其引用的.claude/skills/pr/SKILL.md工作流一起阅读。该技能的使用场景非常明确开发者向仓库提交一个符合 PX4 工程规范的 Pull RequestAI 助手负责执行分支创建、上下文收集、标题与正文撰写、CI 构建验证、推送与创建 PR 的全流程并最终返回 PR 链接。第 1 步分支准备技能要求在任何提交动作之前先检查当前分支若当前位于main必须创建功能分支命名格式为username/description其中username通过gh api user --jq .login获取当前 GitHub 账号登录名收集提交上下文依次执行git status确认工作区状态git log --oneline main..HEAD查看本分支相对main的提交git diff main...HEAD --stat查看改动规模注意使用三点...比较的是main与 HEAD 的合并基而非直接两点差检查远端跟踪分支是否已存在决定后续是否需要git push -u。这一步保证了任何 PR 都从干净、可追踪的分支基线出发避免误在main上直接提交。第 2 步Sanity Build只构建改动真正影响的目标技能要求“只做一个 sanity build”且目标选择有严格规则改动类型应构建的目标说明固件firmware改动受影响的某个板级目标如px4_fmu-v6xrt_default板级代码改动需要真实编译验证POSIX 或仿真改动px4_sitlSITL 目标覆盖 POSIX 层与仿真代码子模块指针更新、纯文档、ROMFS 改动跳过构建改动无法到达任何目标构建无意义两个关键边界不得因为“文档改了”就声称构建通过以证明什么更不得暗示一次构建能证明飞行安全——这符合技能中“不要暗示构建能证明飞行安全”的要求构建失败必须修复后才能开 PR。对于需要真实固件构建的场景技能明确指向 .agents/skills/build-px4/SKILL.md在px4io/px4-devDocker 容器中构建板级固件、支持 git worktree并产出带提交标签的工件而不烧录硬件。该构建技能是自包含的不依赖本地的 Claude 配置构建产生的 worktree 统一放在被忽略的.agents/worktrees/目录下。第 3 步PR 标题type(scope): descriptionPR 标题是技能的核心约束之一格式为type(scope): description长度72 字符以内语义必须覆盖整个 PR 在所有提交之上的整体改动不只是某一个 commit重要性PR 标题会成为 squash-merge 时的提交信息因此它的质量直接决定主分支提交历史的质量。这一格式与仓库的整体约定完全一致。仓库根目录的 AGENTS.md 明确要求“使用$commit技能采用带模块作用域的 Conventional Commit 格式”CONTRIBUTING.md 的第 29 行指出 PX4 对所有 commit message 和 PR title 均使用 conventional commits第 125 行特别强调“PR 标题遵循相同的type(scope): description格式由 CI 强制执行并且在 PR 被 squash-merge 时标题会变成 commit message”。CI 侧的校验逻辑可以在 Tools/ci/conventional_commits.py 和 Tools/ci/check_pr_title.py 中看到实现细节合法 type 集合固定为feat、fix、refactor、perf、docs、style、test、build、ci、chore、revert正则HEADER_PATTERN要求type(scope)[!]: description其中 scope 仅允许字母、数字及_、/、.、-描述至少 5 个字符可选断点变更标记!放在)之后、:之前例如feat(boards/px4_fmu-v6x)!: remove deprecated driver API以Merge开头的标题merge commit豁免校验check_pr_title.py还实现了“建议修复”功能对不符合格式的标题尝试从描述文本中推断 type 与 scope如出现ekf、estimator、imu关键词建议 scopeekf2出现mavlink建议 scopemavlink并可输出 Markdown 格式的 PR 评论--markdown/--markdown-file参数。scope 的推导规则仓库在 .claude/skills/commit/SKILL.md 中给出了 scope 的推导原则从改动文件所在目录路径推导。例如src/modules/ekf2/→ekf2src/drivers/imu/invensense/icm42688p/→drivers/icm42688p.github/workflows/→ciCI 侧conventional_commits.py中的KNOWN_SCOPES列表ekf2、mavlink、commander、navigator、mc_att_control、mc_pos_control、fw_att_control、vtol、actuators、battery、param、logger、uorb、drivers、boards、simulation、sitl、gps、rc、safety、can、serial、mixer、land_detector、airspeed、gyroscope、accelerometer、magnetometer、barometer等可作为手工选择 scope 的参考字典。第 4 步PR 正文精简的三段式技能对 PR 正文的要求是“在能表达清楚观点的前提下尽可能短”——审查者应当一眼看懂过长的描述反而没人读。正文必须且只能包含三个 section按顺序排列## Summary ## Problem ## Solution每个 section 一两句话即可并遵循以下硬性约束不重复 diff不列改动文件清单、不贴代码片段不提 CI正文不讨论 CI 状态或结果不重复标题标题已表达的内容不再复述无## Test plansection、无 boilerplate、无 AI 归属声明诚实报告测试绝不陈述未发生的测试应询问用户实际运行了什么如实报告并明确说明哪些内容未经过测试。若 PR 用于关闭某个 issue则## Summary的第一行必须是fixes #N空一行后再写摘要。例如## Summary fixes #1234 修复了 ekf2 在 baro 数据缺失时的高度融合超时问题。 ## Problem 当 baro 长时间无数据时高度通道持续使用过期观测导致估计漂移。 ## Solution 在高度融合中加入超时判定超时后将该观测源退出融合并记录事件。为什么是“作者即用户”技能在正文部分有一句醒目的原则“The user is the author”——PR 的署名人是用户本人因此不得添加Co-Authored-By或 “Generated with Claude” 之类的 footerAI 参与的披露应放在commit trailersAssisted-by:中而不是 PR 正文里.agents/skills/pr/SKILL.md进一步将这一规则泛化为“任何 assistant 都不得在 generated-by footer 中署名”并要求“将披露保留在 commit trailer而非 PR body”。仓库根目录 AGENTS.md 的 “Attribution” 条目也印证了这一约定使用其他客户端运行时应使用实际的助手身份而不是 Claude 的且 PR 正文中不得出现 generated-by footer。第 5 步推送并创建 PR工作流最后一步若远端无跟踪分支使用git push -u推送执行gh pr create默认 base 分支为main除非用户另行指定返回创建的 PR URL。ghCLI 需要已认证的 GitHub 账号.agents/README.md 也明确指出“GitHub 工作流需要已认证的ghCLI”。整个技能链中的 GitHub 操作获取用户名、创建 PR、查询 issue都依赖gh因此在运行该技能前应先确认gh auth status。技能生态pr 与相邻技能的分工pr技能并非孤立存在它与仓库内其他技能组成完整的开发闭环这在 .agents/README.md 的“Shared guidance”表中给出了映射技能入口工作流来源skills/commit/SKILL.md.claude/skills/commit/SKILL.mdskills/pr/SKILL.md.claude/skills/pr/SKILL.mdskills/review-pr/SKILL.md.claude/skills/review-pr/SKILL.mdskills/rebase-onto-main/SKILL.md.claude/skills/rebase-onto-main/SKILL.mdskills/build-px4/SKILL.md自包含的容器构建工作流日常开发路径大致是$commit按 Conventional Commit 规范提交 →$build-px4做 sanity build →$pr创建规范 PR →$review-pr在合并前做实质性审查 →$rebase-onto-main处理 squash-merge 后的分支重基。这套技能链把 PX4 的工程约定CONTRIBUTING.md 中“审查者会在批准前验证测试或测试证据存在”的规则固化成了可重复执行的流程。常见错误与自检清单结合 CI 校验实现Tools/ci/check_pr_title.py 内置的 bad examples与技能约束提交 PR 前建议逐项自检标题是否为type(scope): description且 ≤72 字符fix stuff、Update file、缺少 type 前缀的ekf2: fix something都会被 CI 拒绝描述是否 ≥5 字符scope 是否来自改动目录路径而非随意取名正文是否只有## Summary / ## Problem / ## Solution三段正文是否包含 diff 清单、CI 讨论、测试声明或 AI 归属 footer是否如实报告了实际运行的测试是否在改动影响固件时至少做了一次对应目标的 sanity build是否确认gh已认证、推送的分支与 PR base默认main正确标题是否覆盖了所有 commit 的整体改动它会成为 squash-merge 的提交信息总结.agents/skills/pr/SKILL.md虽然只有短短十几行但它是对 PX4-Autopilot 完整 PR 工作流的关键入口分支准备与上下文收集、针对改动范围的 sanity build 选择、type(scope): description的标题规范由 CI 用 Tools/ci/check_pr_title.py 强制校验、极简三段式正文、诚实的测试报告以及“用户是作者、披露留在 commit trailer”的署名原则。掌握这套流程就是掌握了该仓库从代码到合入主分支的完整质量门槛——它不仅是给 AI 助手的指令更是每一位 PX4 贡献者都值得遵循的工程规范。【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址: https://gitcode.com/gh_mirrors/px/PX4-Autopilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PX4-Autopilot 的 PR 提交流程技能：从 Conventional Title 到 Summary/Problem/Solution 的工程化实践
PX4-Autopilot 的 PR 提交流程技能从 Conventional Title 到 Summary/Problem/Solution 的工程化实践【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址: https://gitcode.com/gh_mirrors/px/PX4-Autopilot本指南围绕 PX4-Autopilot 仓库中的.agents/skills/pr/SKILL.md技能文件系统讲解该仓库 Pull Request 的规范化提交流程如何用type(scope): description撰写 PR 标题、如何用## Summary / ## Problem / ## Solution三段式组织 PR 描述、何时需要做 sanity build、以及 AI 助手在 PR 中的署名边界。读完你不仅能按 PX4 的规范提交 PR还能理解其背后的 CI 校验逻辑Tools/ci/check_pr_title.py与仓库约定CONTRIBUTING.md让提交一次通过审查。技能文件的定位一个薄适配层.agents/skills/pr/SKILL.md是 PX4-Autopilot 为 GPT 系编码助手如 OpenAI Codex准备的技能入口之一。仓库采用“薄适配层 共享工作流”的组织方式.agents/skills/下的技能文件负责调用方式的适配工具命名、输入来源、署名策略真正的完整工作流存放在.claude/skills/下的同名文件中如 .claude/skills/pr/SKILL.md被.agents/适配层直接引用这一设计在 .agents/README.md 中有明确说明四个适配器加载已有的受版本管理工作流而不是各自维护一份拷贝避免两处漂移。因此理解pr技能需要把适配层与其引用的.claude/skills/pr/SKILL.md工作流一起阅读。该技能的使用场景非常明确开发者向仓库提交一个符合 PX4 工程规范的 Pull RequestAI 助手负责执行分支创建、上下文收集、标题与正文撰写、CI 构建验证、推送与创建 PR 的全流程并最终返回 PR 链接。第 1 步分支准备技能要求在任何提交动作之前先检查当前分支若当前位于main必须创建功能分支命名格式为username/description其中username通过gh api user --jq .login获取当前 GitHub 账号登录名收集提交上下文依次执行git status确认工作区状态git log --oneline main..HEAD查看本分支相对main的提交git diff main...HEAD --stat查看改动规模注意使用三点...比较的是main与 HEAD 的合并基而非直接两点差检查远端跟踪分支是否已存在决定后续是否需要git push -u。这一步保证了任何 PR 都从干净、可追踪的分支基线出发避免误在main上直接提交。第 2 步Sanity Build只构建改动真正影响的目标技能要求“只做一个 sanity build”且目标选择有严格规则改动类型应构建的目标说明固件firmware改动受影响的某个板级目标如px4_fmu-v6xrt_default板级代码改动需要真实编译验证POSIX 或仿真改动px4_sitlSITL 目标覆盖 POSIX 层与仿真代码子模块指针更新、纯文档、ROMFS 改动跳过构建改动无法到达任何目标构建无意义两个关键边界不得因为“文档改了”就声称构建通过以证明什么更不得暗示一次构建能证明飞行安全——这符合技能中“不要暗示构建能证明飞行安全”的要求构建失败必须修复后才能开 PR。对于需要真实固件构建的场景技能明确指向 .agents/skills/build-px4/SKILL.md在px4io/px4-devDocker 容器中构建板级固件、支持 git worktree并产出带提交标签的工件而不烧录硬件。该构建技能是自包含的不依赖本地的 Claude 配置构建产生的 worktree 统一放在被忽略的.agents/worktrees/目录下。第 3 步PR 标题type(scope): descriptionPR 标题是技能的核心约束之一格式为type(scope): description长度72 字符以内语义必须覆盖整个 PR 在所有提交之上的整体改动不只是某一个 commit重要性PR 标题会成为 squash-merge 时的提交信息因此它的质量直接决定主分支提交历史的质量。这一格式与仓库的整体约定完全一致。仓库根目录的 AGENTS.md 明确要求“使用$commit技能采用带模块作用域的 Conventional Commit 格式”CONTRIBUTING.md 的第 29 行指出 PX4 对所有 commit message 和 PR title 均使用 conventional commits第 125 行特别强调“PR 标题遵循相同的type(scope): description格式由 CI 强制执行并且在 PR 被 squash-merge 时标题会变成 commit message”。CI 侧的校验逻辑可以在 Tools/ci/conventional_commits.py 和 Tools/ci/check_pr_title.py 中看到实现细节合法 type 集合固定为feat、fix、refactor、perf、docs、style、test、build、ci、chore、revert正则HEADER_PATTERN要求type(scope)[!]: description其中 scope 仅允许字母、数字及_、/、.、-描述至少 5 个字符可选断点变更标记!放在)之后、:之前例如feat(boards/px4_fmu-v6x)!: remove deprecated driver API以Merge开头的标题merge commit豁免校验check_pr_title.py还实现了“建议修复”功能对不符合格式的标题尝试从描述文本中推断 type 与 scope如出现ekf、estimator、imu关键词建议 scopeekf2出现mavlink建议 scopemavlink并可输出 Markdown 格式的 PR 评论--markdown/--markdown-file参数。scope 的推导规则仓库在 .claude/skills/commit/SKILL.md 中给出了 scope 的推导原则从改动文件所在目录路径推导。例如src/modules/ekf2/→ekf2src/drivers/imu/invensense/icm42688p/→drivers/icm42688p.github/workflows/→ciCI 侧conventional_commits.py中的KNOWN_SCOPES列表ekf2、mavlink、commander、navigator、mc_att_control、mc_pos_control、fw_att_control、vtol、actuators、battery、param、logger、uorb、drivers、boards、simulation、sitl、gps、rc、safety、can、serial、mixer、land_detector、airspeed、gyroscope、accelerometer、magnetometer、barometer等可作为手工选择 scope 的参考字典。第 4 步PR 正文精简的三段式技能对 PR 正文的要求是“在能表达清楚观点的前提下尽可能短”——审查者应当一眼看懂过长的描述反而没人读。正文必须且只能包含三个 section按顺序排列## Summary ## Problem ## Solution每个 section 一两句话即可并遵循以下硬性约束不重复 diff不列改动文件清单、不贴代码片段不提 CI正文不讨论 CI 状态或结果不重复标题标题已表达的内容不再复述无## Test plansection、无 boilerplate、无 AI 归属声明诚实报告测试绝不陈述未发生的测试应询问用户实际运行了什么如实报告并明确说明哪些内容未经过测试。若 PR 用于关闭某个 issue则## Summary的第一行必须是fixes #N空一行后再写摘要。例如## Summary fixes #1234 修复了 ekf2 在 baro 数据缺失时的高度融合超时问题。 ## Problem 当 baro 长时间无数据时高度通道持续使用过期观测导致估计漂移。 ## Solution 在高度融合中加入超时判定超时后将该观测源退出融合并记录事件。为什么是“作者即用户”技能在正文部分有一句醒目的原则“The user is the author”——PR 的署名人是用户本人因此不得添加Co-Authored-By或 “Generated with Claude” 之类的 footerAI 参与的披露应放在commit trailersAssisted-by:中而不是 PR 正文里.agents/skills/pr/SKILL.md进一步将这一规则泛化为“任何 assistant 都不得在 generated-by footer 中署名”并要求“将披露保留在 commit trailer而非 PR body”。仓库根目录 AGENTS.md 的 “Attribution” 条目也印证了这一约定使用其他客户端运行时应使用实际的助手身份而不是 Claude 的且 PR 正文中不得出现 generated-by footer。第 5 步推送并创建 PR工作流最后一步若远端无跟踪分支使用git push -u推送执行gh pr create默认 base 分支为main除非用户另行指定返回创建的 PR URL。ghCLI 需要已认证的 GitHub 账号.agents/README.md 也明确指出“GitHub 工作流需要已认证的ghCLI”。整个技能链中的 GitHub 操作获取用户名、创建 PR、查询 issue都依赖gh因此在运行该技能前应先确认gh auth status。技能生态pr 与相邻技能的分工pr技能并非孤立存在它与仓库内其他技能组成完整的开发闭环这在 .agents/README.md 的“Shared guidance”表中给出了映射技能入口工作流来源skills/commit/SKILL.md.claude/skills/commit/SKILL.mdskills/pr/SKILL.md.claude/skills/pr/SKILL.mdskills/review-pr/SKILL.md.claude/skills/review-pr/SKILL.mdskills/rebase-onto-main/SKILL.md.claude/skills/rebase-onto-main/SKILL.mdskills/build-px4/SKILL.md自包含的容器构建工作流日常开发路径大致是$commit按 Conventional Commit 规范提交 →$build-px4做 sanity build →$pr创建规范 PR →$review-pr在合并前做实质性审查 →$rebase-onto-main处理 squash-merge 后的分支重基。这套技能链把 PX4 的工程约定CONTRIBUTING.md 中“审查者会在批准前验证测试或测试证据存在”的规则固化成了可重复执行的流程。常见错误与自检清单结合 CI 校验实现Tools/ci/check_pr_title.py 内置的 bad examples与技能约束提交 PR 前建议逐项自检标题是否为type(scope): description且 ≤72 字符fix stuff、Update file、缺少 type 前缀的ekf2: fix something都会被 CI 拒绝描述是否 ≥5 字符scope 是否来自改动目录路径而非随意取名正文是否只有## Summary / ## Problem / ## Solution三段正文是否包含 diff 清单、CI 讨论、测试声明或 AI 归属 footer是否如实报告了实际运行的测试是否在改动影响固件时至少做了一次对应目标的 sanity build是否确认gh已认证、推送的分支与 PR base默认main正确标题是否覆盖了所有 commit 的整体改动它会成为 squash-merge 的提交信息总结.agents/skills/pr/SKILL.md虽然只有短短十几行但它是对 PX4-Autopilot 完整 PR 工作流的关键入口分支准备与上下文收集、针对改动范围的 sanity build 选择、type(scope): description的标题规范由 CI 用 Tools/ci/check_pr_title.py 强制校验、极简三段式正文、诚实的测试报告以及“用户是作者、披露留在 commit trailer”的署名原则。掌握这套流程就是掌握了该仓库从代码到合入主分支的完整质量门槛——它不仅是给 AI 助手的指令更是每一位 PX4 贡献者都值得遵循的工程规范。【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址: https://gitcode.com/gh_mirrors/px/PX4-Autopilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考