create-pr

推送分支并创建拉取请求／合并请求。

规则概览

规则	影响	文件
PR 标题	HIGH	rules/pr-title.md
迁移漂移	HIGH	rules/migration-drift.md
PR 描述	MEDIUM	rules/pr-description.md

工作流

1. 检查当前 git 状态和分支，并确定基准分支：用户指定的分支（例如热修复对应的发布分支）；否则使用默认分支
   • 如果当前位于基准分支，先通过 create-branch 技能创建分支
   • 如果有未提交的更改，通过 commit 技能提交，切勿在此处直接使用原始 git commit。只有在某些更改看起来与其余更改无关时，才先询问
2. 按照 rules/migration-drift.md 执行迁移漂移预检。如果架构发生变化但没有对应迁移，则停止并在推送前询问
3. 将当前分支推送到远程（必要时使用 -u 标志）
4. 分析近期提交，生成 PR 标题和描述
5. 通过 git remote get-url origin 检测远程主机（github.com → gh；gitlab.com → glab；默认使用 GitHub），并使用相应 CLI 创建 PR/MR。正文仅使用简洁的项目符号（不要使用 ## Summary、## Test Plan、检查清单或其他标题段落）：
   • GitHub：gh pr create --assignee @me（@me 会解析为已通过身份验证的用户）。
     • 基准分支选择：使用第 1 步确定的基准分支。如果该分支是从一个非默认分支切出的，且该分支本身有未关闭的 PR（检查 merge base，然后运行 gh pr list --head <parent>），则使用 --base <parent-branch> 创建 PR——这样差异范围仅限于当前层，GitHub 也会自动将 PR 链接成堆叠结构（公开预览）。堆叠结构仅适用于同一仓库；对于尚未推出该预览功能的仓库，这会退化为普通的依赖 PR，而这仍是正确的基准分支。
     • 如果已安装 gh stack 扩展（gh extension list），可用它进行堆叠导航和本地级联变基。不要安装该扩展；堆叠管理（变基顺序、合并各层）应交由它处理，不要手动重新指定分支目标——较低层合并后，GitHub 会自行变基并重新指定较高层的目标。
     • gh stack submit 创建的 PR 带有自动生成的标题和正文，不符合规则。提交后，仅使用 gh pr edit <number> --title "..." --body "..." 重写本次提交刚创建的 PR，并遵循 rules/pr-title.md 和 rules/pr-description.md；每个标题和描述都应仅针对该层的差异（该层相对于其基准分支的提交），而不是整个堆叠结构。不要改动已有层——submit 不会重新生成它们的内容，而且它们可能已在审查中被修改。
   • GitLab：@me 是列表筛选器，不能用于创建 MR——先通过 glab api user --jq .username 获取用户名，然后使用第 1 步确定的基准分支运行 glab mr create --assignee <username> --target-branch <base>。

自动分配给当前用户。如果分配失败（用户不是协作者／成员），仍会创建 PR/MR，但不分配负责人。