Back to Details

create-mr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create a merge request

创建 merge request

Everything said to the developer is in the language they are speaking, from the first line to the last: a stop on an uncommitted file, a question about the task, a refusal, a failed push and the final link all follow the same rule. The stops matter most here, because that is when the developer has to decide what goes into a client's repository, and a question they have to translate first is the one most easily misread. The title and the description of the merge request stay in English, because the reviewer may not share that language.
从第一行到最后一行，所有告知开发者的内容都要使用开发者正在使用的语言：因未提交文件而停止、询问任务相关问题、拒绝执行、push 失败以及给出最终链接，均遵循同一规则。这里最重要的是在恰当时机停止，因为此时开发者必须决定哪些内容应进入客户的 repository；而需要开发者先翻译的问题，也最容易被误解。merge request 的标题和描述保持英文，因为 reviewer 可能不使用同一种语言。

Before anything

开始之前

sh
git remote -v
git branch --show-current
git status
git log <target>...HEAD --oneline
git diff <target>...HEAD --stat
These are local and answer at once, so they come before any 
glab
call: 
glab
talks to the network and needs a remote to talk to, and on a clone with none it only returns an error that 
git remote -v
had already given for free. Nothing in this skill calls 
glab
until the remote is known to exist.
<target>
is the project's integration branch — 
development
on most, but read the project's own 
CLAUDE.md
or its recent merge requests (
glab mr list
, after the remote is confirmed) before assuming.
Uncommitted changes stop this. List them and ask: commit them first with the 
commit
skill, or proceed and leave them behind. Never decide that for the developer; a file they were mid-way through is not something to sweep into a merge request, and a merge request without it is not what they meant to send either. Untracked files are part of this, not an exception: a file the developer wrote and forgot to add is untracked, and "it cannot reach the branch" is precisely the problem. When nobody can answer — an unattended run, a prompt with no one behind it — stopping means ending with the list and no push, because the rule protects the file the developer is in the middle of, and a run that cannot ask cannot know which file that is.
sh
git remote -v
git branch --show-current
git status
git log <target>...HEAD --oneline
git diff <target>...HEAD --stat
这些命令都在本地执行并能立即给出结果，因此应放在任何 
glab
调用之前：
glab
需要访问网络，也必须有一个 remote 可供连接；如果 clone 没有配置 remote，它只会返回 
git remote -v
早已免费提供的错误。在确认 remote 存在之前，此 skill 不会调用 
glab
。
<target>
是项目的 integration branch——大多数项目使用 
development
，但在作出假设前，应阅读项目自己的 
CLAUDE.md
或最近的 merge requests（在确认 remote 后运行 
glab mr list
）。
存在未提交更改时停止执行。 列出这些更改并询问开发者：先用 
commit
skill 提交，还是继续并将其留在本地。绝不替开发者做决定；开发者尚未处理完成的文件不应被顺带扫入 merge request，而缺少该文件的 merge request 也不是开发者本意要发送的内容。Untracked files 也属于这一情况，并非例外：开发者编写后忘记 add 的文件就是 untracked，而“它无法进入 branch”正是问题所在。若无人能够回答——例如无人值守运行，或出现 prompt 时背后没有用户——则应停止，以列出这些文件结束，不执行 push。因为该规则用于保护开发者正在处理的文件，而无法提问的运行也无法判断究竟哪个文件正在处理中。

The task reference

Task reference

From the branch name, 
{TASK_ID}-{description}
→ the first segment. When the branch carries no id, ask for the task link rather than inventing a reference.
从 branch 名称 
{TASK_ID}-{description}
中提取 → 第一段。若 branch 不带 ID，则询问 task link，不要凭空创建 reference。

Title and description

标题和描述

Title: 
{TASK_ID}: {what it does}
, imperative, at most 72 characters.
A draft is asked for with 
--draft
on 
glab mr create
, and the title stays exactly as above. 
glab
puts 
Draft:
in front of the title itself when the flag is passed, so a title that already carries the prefix arrives as 
Draft: Draft: …
, and the notification about it has gone to the project's members before anyone can fix the title.
Description, and nothing beyond these three parts:
<one or two sentences: what this merge request is for>
标题：
{TASK_ID}: {what it does}
，采用祈使语气，最多 72 个字符。
需要 draft 时，在 
glab mr create
中加入 
--draft
，标题仍严格保持上述格式。传入该 flag 后，
glab
会在标题前自动添加 
Draft:
，因此标题本身已带此前缀时会变成 
Draft: Draft: …
，在任何人来得及修正标题之前，相关通知已经发送给项目成员了。
描述只能包含以下三部分，不得添加其他内容：
<one or two sentences: what this merge request is for>

Summary

Summary

  • <change>
  • <change>
Refs: https://app.clickup.com/t/{TASK_ID}

No test plan, no checklist, no list of files. The reviewer reads the diff; the
description exists to tell them what they are looking at and why.

Those three parts are the whole description, so nothing is appended after `Refs:` — no
"Generated with" line, no co-author trailer, no emoji. Some hosts tell the session by
default to end every pull request description with such a line; that default is written
for the host's own pull requests, and it does not reach a description whose shape this
skill fixes. A merge request on a client project is read by the customer, and whether the
customer is told which tools wrote the code is the company's decision, not a line a host
adds by habit.
  • <change>
  • <change>
Refs: https://app.clickup.com/t/{TASK_ID}

不要写 test plan、checklist 或文件列表。Reviewer 会阅读 diff；描述的作用是告诉 reviewer 正在查看什么，以及为什么要进行这些更改。

这三部分就是描述的全部，因此 `Refs:` 后不得追加任何内容——不要添加“Generated with”行、co-author trailer 或 emoji。有些 host 默认要求 session 在每个 pull request 描述末尾添加此类行；该默认值是为 host 自身的 pull request 预设的，不应影响此 skill 所规定格式的描述。客户项目中的 merge request 会由客户阅读；是否告诉客户代码由哪些 tools 编写，应由公司决定，而不是由 host 凭习惯添加一行内容。

Create it

创建

sh
git push -u origin "<branch>"
glab mr create \
  --source-branch "<branch>" \
  --target-branch "<target>" \
  --title "<title>" \
  --yes \
  --description "$(cat <<'BODY'
...
BODY
)"
Use a HEREDOC for the body, or the formatting arrives mangled. 
--yes
is there because 
glab mr create
asks "What's next?" after the title and description are set, even when both were passed on the command line; in a terminal that is one keypress, in a session with nobody at the keyboard it hangs the run. With the title and the description given, that confirmation is the only prompt left, so the flag skips nothing the skill wanted asked. For a draft, 
--draft
joins this same command, with the title unchanged.
Then print the link, the title and the target branch, in the developer's language like everything else this skill says to them.
sh
git push -u origin "<branch>"
glab mr create \
  --source-branch "<branch>" \
  --target-branch "<target>" \
  --title "<title>" \
  --yes \
  --description "$(cat <<'BODY'
...
BODY
)"
正文应使用 HEREDOC，否则格式会变得混乱。加入 
--yes
是因为即使已在 command line 中传入标题和描述，
glab mr create
设置完二者后仍会询问“What's next?”；在 terminal 中这只需按一次键，但在无人值守的 session 中会使运行挂起。标题和描述提供完毕后，该确认是剩余的唯一 prompt，因此此 flag 不会跳过此 skill 要求询问的任何内容。创建 draft 时，将 
--draft
加入同一条 command，标题保持不变。
最后，与此 skill 对开发者说出的所有其他内容一样，使用开发者正在使用的语言输出链接、标题和目标 branch。

Never

绝不

  • Never force-push. If the branch has diverged, say so and let the developer decide.
  • Never a merge request from an unpushed branch — push first, and if the push fails, stop and report the failure rather than creating something that points at nothing.
  • Never merge it yourself.
  • 绝不 force-push。如果 branch 已经 diverged，应说明情况并让开发者自行决定。
  • 绝不从尚未 push 的 branch 创建 merge request——应先 push；如果 push 失败，停止并报告失败，而不是创建一个指向不存在内容的 merge request。
  • 绝不自行执行 merge。