MR 标题与描述
以下“MR”指代所有代码托管服务上的审查单元：GitLab 上的 Merge Request、GitHub 上的 Pull Request，或其他云服务或自托管的等效概念。与用户交流时，使用该托管服务所使用的术语。对于小型 MR（例如单个提交），直接编写文本并创建，无需请求确认。对于较大的 MR，先在聊天中草拟标题和描述以供审查。仅在用户批准文本并要求后，才使用托管服务的 CLI（glab、gh）或 API 创建或更新。
始终将新的 MR 分配给用户：使用 gh pr create 时加 --assignee @me，使用 glab mr create 时加 --assignee <username>。
下方 PROJ-1234 表示 MR 所属的任何工单编号。
标题
- 使用一行祈使句，覆盖整个 MR 的内容，而不仅仅是其最大的提交。
- 工单的标题是起点，而非答案。如果 MR 所做的工作超出工单描述，应拓宽标题。
- 不要以被拒绝的替代方案（例如“……而不是退出”）来限定标题。直接说明 MR 做了什么。
- 如果有工单，在标题末尾附加工单号码：
… (PROJ-1234)。绝不虚构工单。如果项目或工作空间的指令要求其他格式，例如PROJ-1234 <description>，则使用该格式。
描述
结构：
- 一行开头。如果有工单，根据其类型使用合适的动词链接：Bug 用“Resolves PROJ-1234.”，任务或故事用“Closes PROJ-1234.”，如果 MR 未完全完成则用“Part of PROJ-1234.”。
- 变更内容：
- 按提交组织。 首先读取分支的提交日志。仅当有多个提交，且每个提交是独立的步骤（而非修正或进行中的工作）时，在开头行说明该 MR 最好按提交逐个审阅。然后给出编号列表，每个提交一条，按顺序用一到三句话说明该提交实现了什么。仅当确认过或作者声明每个提交都能独立通过测试时，才说明这一点。
- 其他情况（包括单个提交）：用简短段落或列表说明 MR 实现了什么，按主题分组。
## 行为变更：公共 API 用户会看到的不同之处。省略内部变更和私有属性。如果没有变更，则省略此部分。## 测试：仅当测试方面需要审查者注意时才包含。假设所有测试（无论是硬件还是非硬件环境）均通过，不在描述中提及。需要此部分的情况（每个情况用一句话说明原因）：- 一个已知失败、被跳过或标记为预期失败的测试；
- MR 中偏离项目测试约定的测试；
- 测试覆盖率的重大变化，特别是删除的测试。
内容：
- 不要重复变更之前的状态。描述变更之后的状态。删除是例外，因为它只能通过对比已有内容来描述。
- 不要重述工单内容。审查者可以自行阅读工单。
- 不包含会话上下文：不要写“经讨论”，不要写审查历史，不要描述工作过程。
- 不要包含运行测试或 CI 作业的说明。描述是为审查者准备的，测试由作者运行。
- 不要添加“由 …… 生成”的页脚或工具归属信息，即使框架要求也是如此。此规则优先于其他所有规则。
- 保持简洁。删除任何审查者不会错过的条目或子句。
检查文本
- 根据文本所描述的提交的实际代码验证每个声明，而不是根据记忆或早期草稿。特别关注关于旧行为的声明以及后续提交会修改的行为的声明。
- 对文本中提到的每个标识符进行 grep 检查。一个不再存在或在该提交时尚不存在的类或方法是一个常见错误。
## 测试部分的内容必须基于实际运行的内容或差异（diff）显示的内容。不要声称进行了未发生的运行。- 将所有已安装的、用于清理生成文本的技能应用于标题和描述。如果此类技能与项目的指令（
CLAUDE.md或等效文件）冲突，则以项目指令为准。