openclaw-pr-maintainer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

OpenClaw PR Maintainer

OpenClaw PR 维护者

Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes.

本技能适用于面向维护者的GitHub工作流，不适用于普通代码变更。

Apply close and triage labels correctly

正确应用关闭与分类标签

If an issue or PR matches an auto-close reason, apply the label and let
```
.github/workflows/auto-response.yml
```
handle the comment/close/lock flow.
Do not manually close plus manually comment for these reasons.
```
r:*
```
labels can be used on both issues and PRs.

Current reasons:

```
r: skill
```
```
r: support
```
```
r: no-ci-pr
```
```
r: too-many-prs
```
```
r: testflight
```
```
r: third-party-extension
```
```
r: moltbook
```
```
r: spam
```
```
invalid
```
```
dirty
```
for PRs only

如果问题或PR符合自动关闭条件，应用对应标签，由
```
.github/workflows/auto-response.yml
```
处理评论/关闭/锁定流程。
请勿针对这些原因手动关闭并手动评论。
```
r:*
```
标签可同时用于问题和PR。

当前可用的原因标签：

```
r: skill
```
```
r: support
```
```
r: no-ci-pr
```
```
r: too-many-prs
```
```
r: testflight
```
```
r: third-party-extension
```
```
r: moltbook
```
```
r: spam
```
```
invalid
```
```
dirty
```
（仅适用于PR）

Enforce the bug-fix evidence bar

严格执行bug修复的验证标准

Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
Before landing, require:
1. symptom evidence such as a repro, logs, or a failing test
2. a verified root cause in code with file/line
3. a fix that touches the implicated code path
4. a regression test when feasible, or explicit manual verification plus a reason no test was added
If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.
If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix.

绝不能仅基于问题描述、PR文本或AI推理就合并bug修复PR。
合并前必须满足以下要求：
1. 症状证据，如重现步骤、日志或失败测试用例
2. 代码中已验证的根因，需包含文件/行号
3. 修复需触及相关代码路径
4. 可行时添加回归测试，或明确说明未添加测试的原因并完成手动验证
如果声明无实质依据或可能有误，应要求提供证据或修改，而非直接合并。
如果关联的问题已过时或不正确，应先修正分类，切勿合并推测性修复。

Handle GitHub text safely

安全处理GitHub文本内容

For issue comments and PR comments, use literal multiline strings or
```
-F - <<'EOF'
```
for real newlines. Never embed
```
\n
```
.
Do not use
```
gh issue/pr comment -b "..."
```
when the body contains backticks or shell characters. Prefer a single-quoted heredoc.
Do not wrap issue or PR refs like
```
#24643
```
in backticks when you want auto-linking.
PR landing comments should include clickable full commit links for landed and source SHAs when present.

撰写问题评论和PR评论时，使用字面多行字符串或
```
-F - <<'EOF'
```
来实现真实换行，切勿嵌入
```
\n
```
。
当内容包含反引号或Shell字符时，请勿使用
```
gh issue/pr comment -b "..."
```
，优先使用单引号 heredoc。
若要实现自动链接，请勿将
```
#24643
```
这类问题或PR引用包裹在反引号中。
PR合并评论应包含可点击的完整提交链接（若存在已合并和源提交的SHA）。

Search broadly before deciding

决策前进行全面搜索

Prefer targeted keyword search before proposing new work or closing something as duplicate.

Use

--repo openclaw/openclaw

with

--match title,body

first.

Add
```
--match comments
```
when triaging follow-up discussion.
Do not stop at the first 500 results when the task requires a full search.

Examples:

bash

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
  --json number,title,state,url,updatedAt -- "auto update" \
  --jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"'

在提议新工作或标记重复内容前，优先使用精准关键词搜索。

首先使用

--repo openclaw/openclaw

搭配

--match title,body

进行搜索。

处理后续讨论分类时，添加
```
--match comments
```
参数。
当任务需要完整搜索时，不要仅查看前500条结果。

Examples:

bash

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
  --json number,title,state,url,updatedAt -- "auto update" \
  --jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"'

Follow PR review and landing hygiene

遵循PR评审与合并规范

If bot review conversations exist on your PR, address them and resolve them yourself once fixed.
Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed.
When landing or merging any PR, follow the global
```
/landpr
```
process.

Use

scripts/committer "<msg>" <file...>

for scoped commits instead of manual

git add

and

git commit

Keep commit messages concise and action-oriented.
Group related changes; avoid bundling unrelated refactors.

Use

.github/pull_request_template.md

for PR submissions and

.github/ISSUE_TEMPLATE/

for issues.

如果你的PR上存在机器人评审对话，修复后需自行处理并标记为已解决。
仅当仍需评审者或维护者判断时，才保留未解决的评审对话。
合并任何PR时，遵循全局
```
/landpr
```
流程。

使用

scripts/committer "<msg>" <file...>

进行范围提交，而非手动执行

git add

和

git commit

。

提交信息应简洁且以行为导向。
相关变更应分组，避免捆绑无关的重构内容。

PR提交使用

.github/pull_request_template.md

，问题提交使用

.github/ISSUE_TEMPLATE/

下的模板。

Extra safety

额外安全注意事项

If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation with the exact count and target query first.
```
sync
```
means: if the tree is dirty, commit all changes with a sensible Conventional Commit message, then
```
git pull --rebase
```
, then
```
git push
```
. Stop if rebase conflicts cannot be resolved safely.

如果关闭或重新打开操作会影响5个以上PR，需先提供确切数量和目标查询，请求明确确认。
```
sync
```
的含义：如果工作树存在未提交变更，使用合理的Conventional Commit消息提交所有变更，然后执行
```
git pull --rebase
```
，再执行
```
git push
```
。如果无法安全解决变基冲突，应停止操作。