把「合并请求描述」交给智能体,难点不在模型能力,而在流程是否说清楚:输入是什么(分支差异),按什么顺序处理,交付什么(PR 描述),哪些事不能做。Skill 就是把这些写下来的载体。

一句话说明

「合并请求描述」技能让智能体为合并请求生成描述、测试说明与截图提示。你提供分支差异,它按固定步骤处理,交付PR 描述。

项目说明
技能合并请求描述(pr-description)
作用为合并请求生成描述、测试说明与截图提示
输入分支差异
输出PR 描述
形态带脚本
风险低
适用人群开发团队

它解决什么问题

没有技能时,开发团队每次都要重新描述要求,智能体的输出时详时略、格式不一,关键的检查步骤也经常被跳过。把流程写成技能后:

  • 每次都按同样的顺序执行:总结改动目的→列出主要变更→写测试方法→提示评审关注点
  • 输出结构固定,便于复核和归档
  • 领域规矩(如「改写历史、删除分支类操作只给建议,不直接执行」)写在技能里,不靠临时提醒

适合与不适合

适合:经常处理分支差异、希望结果格式统一、愿意花十分钟把流程写清楚的开发团队。

不适合:一次性的临时任务;需要大量现场判断、无法写成步骤的工作;以及没有人复核就要直接对外使用的场景。

可以在哪些平台实现

同一个技能的思路可以落在不同平台上,常见选择有:

怎么开始

建议先用纯提示词版本在日常对话助手里试几次,确认步骤合理;再按SKILL.md 写法封装成技能;最后用测试用例验收。

这个技能需要运行本地脚本(解析文件、调用命令行工具等),要求运行环境允许执行代码;风险较低,但输出仍需快速过目再使用。

每一步要产出什么

把每一步的中间产出写清楚,智能体就不容易跳步,人也方便定位问题:

  1. 总结改动目的:产出一段简短的中间结果,并注明依据来自分支差异的哪一部分
  2. 列出主要变更:产出一段简短的中间结果,并注明依据来自分支差异的哪一部分
  3. 写测试方法:产出一段简短的中间结果,并注明依据来自分支差异的哪一部分
  4. 提示评审关注点:产出一段简短的中间结果,并注明依据来自分支差异的哪一部分

最后一步之后,再把这些中间结果汇总成PR 描述。中间结果可以折叠或省略展示,但在技能指令中要求智能体“先完成再汇总”,能明显减少遗漏。

领域注意事项

「合并请求描述」属于Git 与协作领域,使用者多是开发团队,工作环境通常是Git 仓库与代码托管平台。这个领域最重要的一条底线是:改写历史、删除分支类操作只给建议,不直接执行。

建议把这条底线原样写进技能的约束部分,而不是指望智能体自己意识到。同时,在团队内部明确:智能体给出的PR 描述只是初稿或建议,最终由谁签字确认、出了问题由谁负责。

延伸阅读

说明:文中的配置、代码与目录结构均为示意,用于说明思路;各平台的入口、字段名与能力会更新,落地前请以对应官方文档为准。示例中的数据与场景为虚构,不代表真实案例。