用途：为 GitHub Pull Request 生成或改进结构化描述，重点说明变更为何存在，而不只是列出被改动的文件。
适用场景：用户提供 PR URL 并要求撰写或改进其描述；用户要求为当前分支起草 PR 描述；智能体需要开 PR 并希望获得高质量描述。
工作流程分四个阶段。第一阶段收集上下文：读取 PR 元数据（标题、当前描述、作者、分支名）；阅读完整 diff，理解每个改动文件、新增或删除的函数、签名变化，不要跳过文件；必要时阅读周边代码，例如 diff 修改了接口或结构体时，阅读完整文件以理解变更如何融入现有架构；检查关联 issue 或文档，PR 或提交信息可能引用解释动机的 issue、设计文档或 RFC。
第二阶段分析变更，在写作前内部回答：此 PR 之前的状态是什么、存在什么限制、缺陷或缺失能力；为何现在需要此变更、解决什么具体问题、谁受益；关键设计决策是什么、为何选择此方案而非替代方案；新的 API 表面是什么、有无新的公开类型、函数或配置项；架构变化是什么、内部结构如何改变、什么移动到哪里、什么被重构；是否有行为变化，若没有应明确说明以让审查者放心。
第三阶段撰写描述：使用 .github/PULL_REQUEST_TEMPLATE.md 中定义的结构作为模板，语气直接且技术化，面向熟悉代码库但未见过此变更的审查者。关键原则：以“为什么”开头而非“是什么”，diff 已展示改动内容，描述应解释代码中不可见的推理；要具体，例如不要写“improves extensibility”，而写“allows internal tools to compose their own auth chain from individual credential strategies”；点名具体事物，引用实际类型、函数、文件和配置字段，代码引用使用反引号；明确说明未发生的变化，若 PR 是无行为变化的重构，写明“No behavioral changes. Existing users are unaffected.”；摘要保持一到两句，便于快速浏览；用动机部分讲故事：问题是什么、为何以前无法解决、此 PR 解锁了什么。
第四阶段更新 PR：使用 GitHub MCP 工具或 gh CLI 将新描述更新到 PR body，如不确定，推送前与用户确认。
限制：资料未提供该技能的具体安装命令、依赖要求、支持平台或收费信息。