list-open-work

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/list-open-work

Answer one question: what of mine is open in this repo, and which ticket does each carry? Lead with the list. Anything else goes after it, in prose.

回答一个问题：在当前仓库中，我有哪些待处理的MR/PR，以及每个对应的工单是什么？先列出清单，其他说明放在清单之后的段落中。

This repo only

仅限当前仓库

Scope is the git checkout you are in (worktree or primary). Read its

origin

. List my open MRs/PRs against that remote. Stop there.

Not a git repo → say so and stop. Do not hunt another project.
Do not list another origin, org, forge, or tracker from memory, another session, or another worktree.
Infer the ticket key from this repo's branches/titles (e.g.
```
PROJ-123
```
in
```
feat/PROJ-123-slug
```
). Never reuse a prefix you saw somewhere else.

bash

git rev-parse --show-toplevel
git remote get-url origin

范围为你所在的Git检出目录（工作区或主目录）。读取其

origin

地址，列出我针对该远程仓库发起的所有开放MR/PR，到此为止。

若当前目录不是Git仓库 → 告知用户并停止操作，不要查找其他项目。
不要从记忆、其他会话或其他工作区中列出其他origin、组织、代码托管平台或追踪系统的内容。
从当前仓库的分支/标题中推断工单标识（例如
```
feat/PROJ-123-slug
```
中的
```
PROJ-123
```
）。绝不要使用在其他地方看到的前缀。

bash

git rev-parse --show-toplevel
git remote get-url origin

Output format

输出格式

Write it straight into the chat as ordinary rendered markdown. Never wrap it in a code fence — the links have to be clickable.

Blank line between every item. Markdown treats a single newline as a space, so adjacent lines become one paragraph. That is a failure. Each MR is its own paragraph: newline, blank line, next line.

Exactly this shape. Header is

Open MRs:

Open PRs:

. No bullets, no emoji. The number and the ticket key are both links. Ticket sits in trailing

[KEY]

Open MRs:

!42 - shorten the save path [PROJ-101]

!41 - default the new flag on [PROJ-99]

!30 - expose status history on the public API

Descending by number.
```
!N
```
on GitLab,
```
#N
```
on GitHub. "MRs" vs "PRs" likewise.
One paragraph each:
```
<!|#><N> - <title> [<KEY>]
```
. No bold.
Ticket in trailing
```
[KEY]
```
. Move it there if the author buried it mid-title:
```
perf: PROJ-77 — cut over-fetch
```
becomes
```
perf: cut over-fetch [PROJ-77]
```
.
No ticket → omit the
```
[KEY]
```
. Don't invent one, don't write
```
(no ticket)
```
.
Keep the MR/PR title as-is (minus the relocated key). Don't rewrite it.

Wrong (renders as one wrapped line):

Open MRs:
!42 - shorten the save path [PROJ-101]
!41 - default the new flag on [PROJ-99]

Pasting into Slack is a separate ask. Forge/tracker integrations linkify

!42

and

PROJ-101

on their own, so that version is the same lines with the link syntax stripped — still one item per line.

直接以普通渲染的Markdown格式写入聊天框。绝不要用代码块包裹——链接需要可点击。

每个条目之间空一行。Markdown会将单个换行视为空格，相邻行会合并成一个段落，这是不允许的。每个MR都是独立的段落：换行、空行、下一行。

严格遵循以下格式。标题为

Open MRs:

或

Open PRs:

。不要使用项目符号或表情符号。MR/PR编号和工单标识均为链接。工单标识放在末尾的

[KEY]

中。

Open MRs:

!42 - shorten the save path [PROJ-101]

!41 - default the new flag on [PROJ-99]

!30 - expose status history on the public API

按编号降序排列。GitLab使用
```
!N
```
，GitHub使用
```
#N
```
。对应使用"MRs"或"PRs"。
每个条目为一个段落：
```
<!|#><N> - <标题> [<KEY>]
```
。不要加粗。
工单标识放在末尾的
```
[KEY]
```
中。如果作者将标识埋在标题中间，将其移至末尾：例如
```
perf: PROJ-77 — cut over-fetch
```
改为
```
perf: cut over-fetch [PROJ-77]
```
。
若无工单 → 省略
```
[KEY]
```
。不要凭空编造，也不要写
```
(no ticket)
```
。
保留MR/PR标题原样（移除移走的标识后）。不要重写标题。

错误示例（会渲染成一行）：

Open MRs:
!42 - shorten the save path [PROJ-101]
!41 - default the new flag on [PROJ-99]

粘贴到Slack是单独的需求。代码托管平台/追踪系统的集成会自动将

!42

和

PROJ-101

转换为链接，因此该场景下只需去掉链接语法，仍然保持每行一个条目。

Collect

收集信息

Mine means authored by me. Resolve my username from the API — never guess it.

GitLab origin:

bash

glab api user
glab api "projects/<url-encoded-path>/merge_requests?state=opened&scope=all&per_page=100"

Filter to author = me.

<url-encoded-path>

is this origin's path, not a path from another repo.

GitHub origin:

gh pr list --author @me --state open --json number,title,headRefName,body

Ticket = first

\b[A-Z][A-Z0-9]+-\d+\b

in the title, then the branch, then the description. Use that key's tracker host as this repo uses it — don't guess a site from another company.

“我的”指由我发起的MR/PR。通过API获取我的用户名——绝不要猜测。

GitLab origin：

bash

glab api user
glab api "projects/<url-encoded-path>/merge_requests?state=opened&scope=all&per_page=100"

筛选出作者为我的条目。

<url-encoded-path>

是当前origin的路径，而非其他仓库的路径。

GitHub origin:

gh pr list --author @me --state open --json number,title,headRefName,body

工单标识的查找顺序：首先从标题中匹配第一个

\b[A-Z][A-Z0-9]+-\d+\b

格式的内容，然后是分支名，最后是描述。使用当前仓库对应的追踪系统域名——不要猜测其他公司的站点。

Then, in prose

后续说明（段落形式）

Only the things that change what I'd do next:

Conflicts with the default branch — blocked, not in review. GitLab recomputes mergeability lazily, so a plain MR GET happily returns a stale
```
has_conflicts: false
```
. Force it and read
```
merge_status
```
:

bash

glab api "projects/<path>/merge_requests/<iid>?include_diverged_commits_count=true"

仅说明会影响后续操作的内容：

与默认分支存在冲突——处于阻塞状态，无法进入审核。GitLab会延迟重新计算合并可行性，因此普通的MR GET请求可能会返回过时的
```
has_conflicts: false
```
。需要强制获取并查看
```
merge_status
```
：

bash

glab api "projects/<path>/merge_requests/<iid>?include_diverged_commits_count=true"

cannot_be_merged + has_conflicts → needs a rebase; diverged_commits_count = how far behind

cannot_be_merged + has_conflicts → 需要变基；diverged_commits_count表示落后的提交数


- Red pipelines (`head_pipeline.status`).
- Ticket status that contradicts the MR: green with every thread resolved but the
  ticket still says In Progress.
- No ticket plus months of age — give the age, offer to close.

Skip approvals unless asked. Don't narrate fields that changed nothing.


- 失败的流水线（`head_pipeline.status`为红色）。
- 工单状态与MR状态矛盾：例如MR已通过所有审核，但工单仍显示“In Progress”。
- 无工单且已存在数月——告知时长，并提议关闭。

除非被询问，否则不要提及审批情况。不要描述不会影响后续操作的字段变化。