Agent Skills
返回列表
💻

Git PR 优化工作流

开发编程 更新于 2026.08.30

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @org-02qudk26/git-pr-workflows-pr-enhance。

技能介绍

问题从哪来

很多 PR 在合并前卡住，不是因为代码错，而是审查者缺少上下文：改动动机说不清、影响面没写、测试是否覆盖无从判断，体积过大又难以逐行看。结果要么是来回追问，要么是「LGTM」式走过场。这个技能把「写 PR」当成可重复的工程流程，而不是临提交前补几行说明。

技能会做什么

在明确目标与约束（通过 $ARGUMENTS 等输入）后，按 PR 优化最佳实践组织输出，典型结构包括：

  • PR 摘要：用关键指标给出执行摘要，方便维护者快速决策
  • 详细描述：覆盖动机、实现要点与相关文档
  • 审查清单：与本次改动上下文绑定的检查项，而不是通用模板空打勾
  • 风险评估与测试覆盖（含前后对比），说明改了什么、测了什么
  • 大小建议：当改动过大时，给出可拆分的拆分思路
  • 审查自动化：列出可自动检查的发现项，减少人工扫漏

需要更细的写法与示例时，技能会指向 resources/implementation-playbook.md。

适用边界

仅适用于 Pull Request 创建与改进、审查辅助与 PR 工作流相关任务。若问题与 PR 无关，或需要完全脱离该范围的其它工具/领域，不应依赖本技能替代专业方案。

使用场景

  • 功能分支涉及多模块、diff 很大，提 PR 前需要执行摘要、完整描述，以及是否拆成多个 PR 的建议。
  • 契约或公共 API 变更的 PR，要在描述里写影响面、风险与缓解策略，并生成与改动绑定的审查清单。
  • 重构或行为变更的 PR，需要整理测试覆盖的前后对比，向审查者说明已测路径与仍存在的缺口。
  • 准备进入团队 review 流程，需要把可自动检查项与人工审查重点分开列出，避免审查遗漏。

适合人员

  • 负责主分支合并的仓库维护者，希望作者在 PR 中自带动机、风险与测试说明，减少 review 往返。
  • 在 monorepo 或多服务仓库中同时改多处代码的后端工程师，提交前需要评估 PR 体积并规划拆分。
  • 推动团队 PR 规范一致的 Tech Lead，需要可复用的描述结构、审查清单与风险评估写法。
  • 向不熟悉惯例的 upstream 仓库首次提 PR 的开源贡献者，需要把上下文与可审查性写全。