mcpField
P
pr-description-writer

pr-description-writer

github.com/mohitagw15856开发1.5k48 次安装1 周前更新
代码仓库

关于 pr-description-writer

pr-description-writer 根据代码差异、提交列表或备注撰写结构化拉取请求说明，帮助开发者向审阅者交代变更原因、测试步骤和与风险相称的审阅提示。

主要功能

  1. 01撰写结构化 PR 说明
  2. 02概述变更及其原因
  3. 03提供可复现的测试步骤
  4. 04按风险调整审阅提示

适用场景

  1. 01根据代码差异撰写说明
  2. 02将提交汇总为 PR 内容
  3. 03为审阅者提供测试指引

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill pr-description-writer

安装后在 Claude Code 中输入/pr-description-writer确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
reviewer-empathy.md
worked-example.md
templates/
pr-template.md

详细介绍

PR 描述撰写技能

根据差异、提交列表或非正式笔记，撰写结构清晰、便于审阅的拉取请求描述。涵盖更改内容、原因和审阅方式，让审阅者可以立即开始审阅。

不太符合你的需求？ 如果你希望通过 GitHub 连接器读取真实差异，请使用 pr-description-live。

必需输入

如果未提供，请询问以下信息：

  • 更改内容（粘贴 git diff、git log --oneline，或用通俗的语言描述更改）
  • 更改原因（要解决的问题或要添加的功能）
  • 测试方法（审阅者验证功能是否正常所需的具体步骤）
  • 风险级别（低 / 中 / 高 — 影响需要提供多少审阅指导）
  • PR 类型（功能 / 错误修复 / 重构 / 依赖项升级 / 配置更改 / 热修复）
  • 目标分支（例如 main / develop / release/2.4 — 影响风险说明和审阅指导）
  • 关联的问题或工单（例如 JIRA-1234、GitHub #567 — 或“无”）

输出格式

标题

使用清晰的祈使语气，且少于 72 个字符： [type]: [concise description of what changed]

示例：

  • feat: add rate limiting to the public API
  • fix: resolve race condition in session expiry
  • refactor: extract payment logic into PaymentService
摘要

用 2–3 句话说明：

  • 此 PR 的作用（更改内容）
  • 更改的必要性（问题或目标）
  • 采用的方法（概述）
所做更改

列出具体更改，每个逻辑更改对应一条，不要按文件列出：

  • 添加 [X] 以处理 [Y]
  • 重构 [A] 以减少 [B]
  • 移除 [C]，因为它已被 [D] 替代
  • 更新 [E] 以修复 [F]
截图 / 演示

[如果更改涉及 UI：提供更改前后的截图或屏幕录制] [如果更改涉及 API：提供请求 / 响应示例] [如果没有视觉更改，也没有 API 契约更改：完全省略此部分 — 不要将其留作占位内容]

如何测试

提供审阅者可以遵循的分步说明：

  1. [如有需要，提供设置步骤]
  2. [要执行的操作]
  3. [要验证的内容]
  4. [要检查的边界情况]

请包含所需的具体命令、测试数据或环境标志。

测试清单
  • 已添加 / 更新单元测试
  • 已添加 / 更新集成测试
  • 已覆盖边界情况
  • 已完成手动测试
  • 现有测试无回归
审阅者须知

指出任何值得额外关注的事项：

  • 欢迎他人提供第二意见的不确定之处
  • 有意做出的权衡（及其原因）
  • 注意到但未处理的范围外事项
  • 对其他 PR 的依赖（请附上链接）
相关事项
  • 关闭 #[issue number]（如适用）
  • 与 #[PR/issue number] 相关

深入资料

此技能附带支持文件 — 如果这些文件可用，请使用：

  • references/reviewer-empathy.md — 将 PR 描述作为审阅导航。在生成输出时应用其中的指导；该文件包含了此处方法摘要所概括的校准原则和判断要点。
  • templates/pr-template.md — 可填写的交付内容模板，内含质量检查项。如果用户想自己填写文档，而不是让你生成，请提供此模板。

评分标准（0–40）

提交前，为此技能的任何输出评分；32 分以上即可达到交付质量。

维度0510
为何优先于做了什么描述只是在复述差异；没有说明动机做了什么很清楚，但为何要做解释得很少或流于笼统（“改进了代码”）明确说明了问题、目标和方法；描述补充了差异本身无法传达的背景
标题与结构只有一段无结构的文字；标题含糊、缺少类型前缀或超过 72 个字符有标题结构，但标题或章节使用不规范（保留了占位章节）类型前缀有效，使用祈使语气，少于 72 个字符；章节便于评审者直接找到所需内容
测试可复现性没有测试步骤有步骤，但默认读者熟悉代码库，或遗漏边界情况不熟悉代码的人员也能复现验证过程——包含命令、测试数据、标志以及至少一个边界情况
与风险相匹配的评审者指引高风险 PR 没有评审者说明，或说明纯属套话有说明，但没有指出具体权衡、不确定性或范围外事项指引与风险相符：高风险需指出具体关注点和有意为之的权衡；低风险则将说明控制在一行，或省略

质量检查

  • 标题使用祈使语气，且少于 72 个字符
  • 摘要说明了做了什么以及为何要做（不只是做了什么）
  • 变更列表描述逻辑上的变更（而非逐个文件列举变更）
  • 标题以有效的类型前缀开头（feat / fix / refactor / chore / deps / config / hotfix），且少于 72 个字符
  • 不熟悉代码的人员也能复现测试步骤
  • 对于高风险 PR，“评审者说明”至少指出一个具体关注点或有意为之的权衡；对于低风险 PR，则省略“评审者说明”或控制在一行

反模式

  • 不要只复述变更内容——解释为何进行这项变更
  • 不要跳过测试步骤——评审者需要知道如何验证变更是否有效
  • 对于高风险 PR，不要省略评审者说明——指出有意为之的权衡和需要仔细审查的领域
  • 不要描述差异中一目了然的实现细节——补充差异本身无法传达的背景
  • 不要只写一段文字——使用标题组织内容，让评审者能快速找到所需信息

使用示例

  • “为这些变更编写 PR 描述” + [粘贴差异或描述]
  • “为 [功能] 起草一个拉取请求”
  • “我需要一份 PR 描述——这是我的变更”
  • “将这些提交总结成一份 PR 描述”
  • “为这个分支编写 PR 正文”

评论

支持 Markdown