用途：把当前工作整理成人类可一次审查通过的 PR，在开 PR 前检查范围与质量，并给出标题、描述结构与评审者视角的注意事项。
主要能力与检查项：
- 开 PR 前：分支只含一个逻辑改动（或明确标注的堆叠提交）；无残留 console.log、debugger、TODO: temp、自己加的被注释代码块；无无关的纯格式化改动；密钥、.env 和仅本地文件未被暂存；diff 与所述目标一致，没有“额外顺手”的改动。
描述模板（按托管平台调整章节名，如 GitHub/GitLab）：
Summary
<1–3 条要点：做了什么、为什么>
Test plan
Notes
<风险、后续事项、UI 截图如有>
提交/PR 标题：用祈使句且具体，如 fix checkout: reject expired discount codes；不要用 update stuff、fix、WIP、address comments。
评审者同理心：指出看起来吓人但属机械改动的文件（重命名、生成物）；对调用方/API 消费者有变化的行 为；你不确定的地方。
反模式：除非必要，绝不在一个 PR 混入重构+功能+依赖升级；不在未警告时强推共享分支；不以“测试待定”且无计划开 PR；不把破坏性变更埋在描述中间。
若被要求开 PR：先用自己话总结 diff；按模板起草标题与正文；用一小节列出遗留风险。
限制：资料未提供具体命令、安装方式、平台支持范围或收费信息。