create-pr

创建 Pull Request

为当前分支创建 GitHub pull request，并自动生成标题和摘要。

前提条件

运行 gh auth status，确认已安装并完成身份验证。如果失败，请告知用户运行 gh auth login。

工作流

1. 了解当前状态

并行运行以下命令：

• git status — 检查是否有未提交的更改
• git log --oneline -20 — 查看近期提交历史
• git rev-parse --abbrev-ref HEAD — 获取当前分支名称
• git remote show origin | grep 'HEAD branch' — 检测默认基础分支（通常为 main 或 master）

2. 处理未提交的更改

如果有已暂存或未暂存的更改，先询问用户是否要在创建 PR 之前提交。未经明确批准，不要提交或推送。

3. 处理推送

检查当前分支是否有远程跟踪分支，以及是否与远程保持同步：

git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null

如果分支尚未推送，或领先于远程分支，先询问用户是否要推送。推送时使用 -u 设置跟踪关系。

4. 分析更改

此仓库中的大部分代码由 LLM 生成，因此审阅者会更依赖 PR 描述，而不是差异内容。你的任务是收集足够的信息，填写第 5 步模板中的每个部分，而不只是列举更改内容。

查看分支上的所有提交，而不只是最新的提交：

git log <base-branch>..HEAD                 # full messages, not just --oneline
git diff <base-branch>...HEAD
git rev-parse --abbrev-ref HEAD             # branch name often carries a ticket ID

阅读时，有意识地收集以下信息：

• 原因：更改的缘由（提交消息、分支名称、关联的工单）
• 工作原理：整体实现方式（涉及哪些模块或层、数据流或控制流）
• 不显而易见的决策：审阅者可能会提出疑问的内容
• 行为、接口或架构变更：合并后系统有哪些不同
• 实际执行的测试：查找新增的测试文件，但要向用户确认或查看运行历史
• 风险：破坏性更改、迁移、影响范围

如果某个部分没有足够的信息，不要编造；在第 5 步将该部分填写为 N/A — <一行说明原因>。

5. 创建 PR

生成一个简洁的标题（少于 70 个字符），概括说明更改。

正文必须严格遵循以下模板。8 个章节标题都必须按顺序出现。如果某个部分确实不适用，请在该标题下填写 N/A — <一行说明原因>；不得省略标题，也不得将任何部分留空。

模板（在各标题下填写内容）：

## Context
Why this change exists. What problem it solves or capability it adds.
Reference the trigger (bug, feature request, incident, refactor goal).
One short paragraph — not a changelog.

## Linked Issues
Linear tickets, GitHub issues, incident IDs, or prior PRs this builds on.
`N/A — <reason>` if none.

## Design
The high-level shape of the implementation. How the pieces fit together,
which modules/layers are touched and in what role, and the data/control
flow for the main path. Aim for what a reviewer would draw on a
whiteboard. Avoid restating the diff line-by-line.

## Key Decisions
Non-obvious choices and the trade-offs behind them. Alternatives
considered and why they were rejected. Anything a reviewer might
otherwise flag as "why did you do it this way?" — answer it here
pre-emptively. `N/A — <reason>` only for trivial/mechanical changes.

## Changes
Logical/semantic changes — not a file-by-file inventory. Focus on:
- Interface changes (new/changed/removed commands, flags, public APIs)
- Schema changes (config, data model, API request/response shapes)
- Behavioral changes (what `cx` does differently now)
Skip mechanical detail (which files moved, which libs bumped) unless
it materially affects reviewers. Rollout concerns (migrations,
breaking-change handling) belong in Risks & Rollout, not here.
Bullet list.

## Testing
How the change was verified. List the exact commands run (unit,
integration, e2e, manual `cx` invocations). If a layer was skipped,
say why. Aspirational tests don't count — only what was actually
executed.

## Risks & Rollout
Backwards compatibility, breaking changes, migrations, feature flags,
performance impact, blast radius if this goes wrong. How to roll back.
`N/A — <reason>` for low-risk changes (e.g. pure docs, isolated
refactor).

## Out of Scope / Follow-ups
What this PR deliberately does *not* do, and any follow-up work that
should land separately. `N/A — <reason>` if the PR is fully
self-contained.

使用以下命令创建：

gh pr create --title "the title" --body "$(cat <<'EOF'
## Context
...

## Linked Issues
...

## Design
...

## Key Decisions
...

## Changes
- ...

## Testing
- ...

## Risks & Rollout
...

## Out of Scope / Follow-ups
...
EOF
)"

如果基础分支不是默认分支，请传入 --base <branch>。

6. 提交前检查清单

运行 gh pr create 前，检查已整理的正文：

• 按顺序包含全部 8 个章节标题：Context、Linked Issues、Design、Key Decisions、Changes、Testing、Risks & Rollout、Out of Scope / Follow-ups
• 每个章节都不为空；均包含实际内容或 N/A — <reason>
• Testing 列出此分支上实际运行过的命令，而不是通用建议
• Changes 描述逻辑或语义上的差异，而不是文件清单
• Design 说明更改的工作原理，且描述层次高于差异内容

如果有任何一项未通过，请先修正正文再提交。

7. 返回结果

输出 PR URL，方便用户点击查看。