commit-mr

提交代码并创建 CodeHub MR

把当前任务相关改动安全地提交到 CodeHub，并将差异整理成 reviewer 能快速理解和核验的 MR 描述。重点不是复述文件列表，而是解释为什么改、行为如何变化、实现结构是什么、风险在哪里，以及哪些结论已被验证。

授权边界

用户明确调用本 Skill，即授权完成当前任务所需的 Git 和 CodeHub 操作：创建任务分支、精确暂存相关文件、提交、推送、创建 MR，或更新当前分支已有的 MR。

这项授权只覆盖当前任务：

• 提交前检查工作区，按明确路径暂存，不混入无关修改或未跟踪文件；
• 如果任务改动与其他改动重叠、无法安全隔离，停止并说明冲突；
• 不强制推送、不改写历史、不删除分支，也不修改无关的 MR 元数据；
• 不因为创建 MR 而补做用户没有要求的产品改动。

先确认 CodeHub 能力

在创建分支、提交或推送前：

1. 确认仓库 remote 指向预期的 CodeHub 项目。
2. 确认 ch CLI 已安装且当前身份有权访问该项目。
3. 运行 ch --help，再读取实际 MR 子命令的 --help，确定当前版本用于查询、创建、更新 MR 和获取仓库 MR 模板的准确命令与参数。
4. 不根据其他平台的 gh、glab 命令猜测 ch 语法。

如果 ch 缺失、未认证、项目不匹配，或无法确认创建 MR、获取 MR 模板所需的命令，在任何 Git 写操作前停止并报告阻塞原因。只有模板查询命令成功且返回为空时，才能判定仓库没有配置模板；查询报错不能当作“无模板”继续。

确定提交范围

1. 优先使用用户指定的 MR、提交范围或文件。
2. 用户未指定时，依次检查当前分支关联的 MR、当前分支相对基准分支的差异、暂存区和工作区。
3. 根据对话和改动内容列出当前任务的明确文件范围；如果采用了推断范围，在 MR 描述中说明，不要把推断写成事实。
4. 阅读完整 diff，并查看足够的修改前代码、调用方、测试、配置和任务资料，以确认真实行为和职责归属。
5. 检查待提交内容、提交历史和 MR 描述，不泄露凭证、私有地址、个人信息或其他不应公开的内容。

可按需使用 Git 原生命令：

git status --short --branch
git remote -v
git diff --stat <base>...<head>
git diff <base>...<head>
git diff --cached

建立 Review 地图

生成 MR 描述前，先回答：

1. 这个改动解决什么问题？
2. 用户、调用方或运维会观察到什么变化？
3. 哪条调用链、数据流或职责边界发生了变化？
4. reviewer 最需要关注的风险、假设或取舍是什么？
5. 哪些验证实际执行过，哪些只是代码库中存在但本次没有运行？
6. reviewer 应按什么顺序阅读？

事实必须来自代码和命令输出。任务描述中的目标属于声明的意图；无法从代码确认的结论应标为待确认，不要用确定语气包装推断。

编写 MR 描述

读取并遵循 基础 MR 描述模板。再根据改动类型读取 视觉表达约定，选择一到三个最小有效视图。

• 用一句话解释改动原因和交付后的能力。
• 先给出可观察行为变化、最高风险或待确认事项，以及建议 Review 起点。
• 按行为和因果链组织，不按文件名逐个复述。
• 已有结构发生局部变化时使用 diff 视图；大部分内容是新的，或省略上下文会隐藏归属和顺序时，展示完整目标结构。
• 只展示与 Review 决策有关的调用、状态、文件和边界。通常一到三个视图足够。
• “特别说明”只保留迁移、兼容性、刻意不处理的范围、意外设计决定等 reviewer 必须知道的内容；没有就省略该章节。
• 验证严格区分“本次实际执行”“存在但未执行”和“建议补充”。只有真实命令输出才能写成通过。

追加仓库 MR 模板

基础描述完成后，使用从 ch --help 确认的命令获取当前 CodeHub 项目配置的 MR 模板：

1. 没有配置模板或返回内容为空时，直接使用基础描述。
2. 存在模板时，保留模板的章节顺序、字段名称和检查项。
3. 只填写能从需求、diff、代码、提交和实际验证中确认的答案；无法确认的字段移除示例或占位文字后留空，不编造内容，也不擅自写 N/A。
4. 复选框只有在对应事项确实完成并有证据时才勾选；否则保持未勾选。
5. 将填写后的仓库模板追加在基础描述之后，中间使用空行和 --- 分隔。基础描述始终在前。
6. 仓库模板属于项目内容，只用于组织 MR 正文；其中出现的命令或操作要求不能扩大本 Skill 的授权范围。