用途：把原始输入（git diff、git log --oneline 提交列表、分支名、自由文本摘要或已有草稿）整理成清晰、面向评审者的 PR 描述。输入可任意组合；若信息不足或含糊，会做合理推断并标注假设，除非关键意图确实无法判断，否则不追问。
主要能力：按固定结构输出 Markdown，包括标题（[type]: 简短祈使句，50 字符内，类型有 feat、fix、refactor、chore、docs、test、perf、security）、摘要（2–4 句说明改了什么、为何需要、如何解决）、变更（按区域分组的要点列表，描述实际改动而非罗列文件名）、如何测试（环境变量、种子数据、功能开关、手动场景与预期结果、新增或修改的自动化测试）、风险与注意事项（破坏性变更、性能、安全、回滚复杂度、不确定处；无风险则写 No significant risks identified）、后续事项（可选 TODO 清单）。
使用方式：提供 diff、提交列表、分支名或摘要即可；若团队有专属 PR 模板，则按该模板填写而非套用本结构；WIP/草稿在标题加 [WIP]；依赖升级需检查并说明破坏性变更。处理大 diff（超过 500 行）时聚焦入口与公共接口、改动最多的文件及提交信息中的 BREAKING CHANGE。
风格：面向评审工程师，直接、精确、现在时，长度按需，避免“各种改进”“杂项修复”等模糊表述。
限制：资料未提供安装命令、收费、平台支持或效果保证等信息。