tag-duplicate-prs-issues

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Tag Duplicate PRs and Issues

标记重复的PR和Issue

Use this skill when a maintainer needs to decide whether a pull request or issue is a duplicate of existing work.

This skill is for maintainer triage and grouping. It is not for reviewing the implementation quality of a PR.

当维护者需要判断某个拉取请求（PR）或Issue是否与现有工作重复时，可使用本技能。

本技能适用于维护者的分类筛选与分组工作，不用于评审PR的实现质量。

Required Setup

必要设置

Do not write duplicate groups or annotations until this setup is complete. Read-only discovery can still proceed with

gitcrawl

and live

gh

完成以下设置前，请勿创建重复分组或添加注释。不过仍可通过

gitcrawl

和在线

gh

工具进行只读式的重复项探索。

Companion Skills

配套技能

Use

$gitcrawl

first for local candidate discovery. Use the

prtags

skill from the

prtags

repo at

skills/prtags/SKILL.md

when it is available.

首先使用

$gitcrawl

进行本地候选重复项的发现。当

prtags

技能可用时，请使用

prtags

仓库中

skills/prtags/SKILL.md

文档内的对应技能。

Install the CLIs

安装CLI工具

Install

prtags

from its latest GitHub release. Do not rely on an old local build unless the maintainer explicitly wants to test unreleased behavior.

prtags

CLI install path:

bash

curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"

从

prtags

的最新GitHub版本中安装该工具。除非维护者明确要求测试未发布的功能，否则请勿依赖旧的本地构建版本。

prtags

CLI安装命令：

bash

curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"

Authenticate prtags

验证prtags身份

prtags

should be logged in with the maintainer's own GitHub account through OAuth device flow. Do not use a shared maintainer token for interactive triage.

bash

prtags auth login
prtags auth status

The expected outcome is that

prtags

stores the logged-in maintainer identity locally and uses that account for authenticated writes.

prtags

需通过OAuth设备流使用维护者个人的GitHub账号登录。交互式分类筛选工作请勿使用共享的维护者令牌。

bash

prtags auth login
prtags auth status

预期结果：

prtags

会在本地存储已登录的维护者身份，并使用该账号进行需认证的写入操作。

Missing-Setup Rule

缺失设置规则

Do not require an up-front preflight before starting the workflow. Proceed with the normal steps until you actually need a tool or account state.

As soon as you discover that

prtags

is missing or not logged in at the write step, stop immediately. Do not continue in a partial write mode after that point.

prtags

is missing, ask the user to run:

bash

curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"

prtags auth status

shows that the user is not logged in, ask the user to run:

bash

prtags auth login

Resume only after the missing tool or login state has been fixed.

无需在开始工作流前进行预先检查。按正常步骤推进，直到实际需要某工具或特定账号状态时再处理。

一旦在写入步骤发现

prtags

未安装或未登录，请立即停止操作。此后请勿继续进行部分写入操作。

若缺少

prtags

，请要求用户执行以下命令：

bash

curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"

若

prtags auth status

显示用户未登录，请要求用户执行以下命令：

bash

prtags auth login

仅在缺失的工具或登录状态修复后，才可恢复工作。

Read-Path Default

只读路径默认规则

For candidate discovery in this workflow, use

gitcrawl

first. Treat it as the local history and clustering layer for related issues, duplicate attempts, and closed threads.

Use live

gh

gh api

for the target thread and for any candidate before making an actionable judgment. Use live GitHub when

gitcrawl

is missing or stale for a concrete reason, such as:

the target or candidate is not present yet
the local data is clearly stale or incomplete for the decision you need to make
```
gitcrawl
```
errors, times out, or lacks the needed neighbor/search data

When you fall back to live GitHub search, note that you did so and why.

If a later

prtags

target-level write fails because its own mirror has not caught up, stop and report that the curation backend is missing the target object instead of forcing a fallback write.

在本工作流中寻找候选重复项时，优先使用

gitcrawl

。将其视为相关Issue、重复尝试及已关闭线程的本地历史与聚类层。

在做出可执行的判断前，请使用在线

gh

或

gh api

查看目标线程及所有候选重复项。仅当

gitcrawl

因以下明确原因缺失数据或数据过时，才使用在线GitHub：

目标或候选项尚未存在于本地
本地数据明显过时或不完整，无法支撑你需要做出的决策
```
gitcrawl
```
出现错误、超时，或缺少所需的关联/搜索数据

当你回退到在线GitHub搜索时，请记录该操作及原因。

若后续

prtags

的目标级写入操作因自身镜像未同步而失败，请停止操作并报告：分类筛选后端缺少目标对象，请勿强制使用回退写入路径。

Goal

目标

For each target PR or issue:

gather duplicate evidence
decide whether it is a real duplicate
create or reuse one
```
prtags
```
group for that duplicate cluster
save the maintainer judgment in
```
prtags
```
rely on normal
```
prtags
```
group writes to drive GitHub comment sync when that integration is configured

针对每个目标PR或Issue，完成以下步骤：

收集重复项证据
判断其是否为真正的重复项
为该重复项集群创建或复用一个
```
prtags
```
分组
将维护者的判断保存到
```
prtags
```
中
当配置好集成后，依赖
```
prtags
```
的分组写入操作自动同步GitHub评论

Tool Roles

工具角色

Use the tools with these boundaries:

```
gitcrawl
```
is candidate generation and historical context
- use it first for local title/body search, neighbors, clusters, and closed-thread discovery
- treat every candidate as a lead until live GitHub confirms it
```
gh
```
is live GitHub truth
- use it for target state, body, comments, reviews, files, linked issues, and current open/closed/merged status
- use
```
gh search
```
  only when
```
gitcrawl
```
  is stale, missing data, or cannot express the needed query
```
prtags
```
is the maintainer curation layer
- use it to create or reuse one duplicate group
- use it to save the duplicate status, confidence, rationale, and group summary
- use it as the source of truth for the GitHub-facing group comment

请按以下边界使用工具：

```
gitcrawl
```
：候选重复项生成与历史上下文提供
- 优先使用它进行本地标题/正文搜索、关联项查找、聚类分析及已关闭线程发现
- 在在线GitHub确认前，将每个候选项视为潜在重复线索
```
gh
```
：在线GitHub的真实数据源
- 使用它查看目标状态、正文、评论、评审内容、文件、关联Issue及当前的开启/关闭/合并状态
- 仅当
```
gitcrawl
```
  数据过时、缺失或无法表达所需查询条件时，才使用
```
gh search
```
```
prtags
```
：维护者分类筛选层
- 使用它创建或复用重复项分组
- 使用它保存重复项状态、置信度、理由及分组摘要
- 将其作为面向GitHub的分组评论的数据源

Working Rules

工作规则

Do not call something a duplicate only because the titles are similar.
Do not call something a duplicate only because the same files changed.
A duplicate cluster should be based on the same user-facing problem, the same intent, and substantially overlapping implementation or investigation context.

请勿仅因标题相似就判定为重复项
请勿仅因修改了相同文件就判定为重复项
重复项集群应基于相同的用户侧问题、相同的意图，以及高度重叠的实现或调研上下文

One-Group Rule

单一分组规则

Treat duplicate groups as exclusive. A PR or issue should belong to at most one duplicate group at a time.

That means:

before creating a new group, search for an existing group that already represents the same duplicate story
if the target already appears to belong to a different duplicate group, stop and resolve that conflict first
do not create a second group for the same target just because the wording is slightly different
if two plausible existing groups overlap and you cannot safely merge the judgment, stop and ask the maintainer

This rule matters more than speed. The skill should keep one coherent duplicate cluster per problem, not many near-duplicate clusters.

重复项分组具有排他性。一个PR或Issue同一时间最多只能属于一个重复项分组。

这意味着：

创建新分组前，请搜索是否已有代表相同重复场景的现有分组
若目标似乎已属于另一个不同的重复项分组，请先停止操作并解决该冲突
请勿仅因表述略有不同就为同一目标创建第二个分组
若两个看似合理的现有分组存在重叠，且你无法安全合并判断，请停止操作并咨询维护者

本规则比工作速度更重要。技能应确保每个问题对应一个清晰的重复项集群，而非多个近似重复的集群。

What A Good Duplicate Group Represents

优质重复项分组的标准

A duplicate group should describe the underlying problem and the intended fix direction. Do not group items only because they share a keyword.

Good group shape:

same user-facing bug or same maintainer-facing task
same subsystem or code surface
same intended change direction
same likely duplicate-resolution path

Bad group shape:

“all PRs that touch Slack”
“all issues mentioning retry”
“all auth-related items”

The group title should name the real problem. The group description should summarize the intent and the code surface.

Examples:

gateway: startup regression from channel status bootstrap

```
whatsapp: QR preflight timeout handling
```

release: cross-OS validation handoff gaps

重复项分组应描述底层问题及预期的修复方向。请勿仅因共享某个关键词就进行分组。

优质分组特征：

相同的用户侧Bug或相同的维护者侧任务
相同的子系统或代码范围
相同的预期修改方向
相同的重复项解决路径

劣质分组特征：

“所有涉及Slack的PR”
“所有提及重试的Issue”
“所有与认证相关的项”

分组标题应明确真实问题。分组描述应总结意图及代码范围。

示例：

gateway: startup regression from channel status bootstrap

```
whatsapp: QR preflight timeout handling
```

release: cross-OS validation handoff gaps

Evidence Checklist

证据检查清单

Before declaring a duplicate, gather evidence from at least two categories.

gitcrawl

neighbors, search hits, and cluster membership count as candidate generation, not as enough proof by themselves.

For PRs:

same or nearly same problem statement
same changed files or overlapping file ranges
same fix direction
same subsystem and failure mode
same linked issue or same user-visible symptom

For issues:

same user-visible problem
same reproduction story or same failure mode
same likely fix area
same PRs already linked or discussed
same maintainers already steering toward the same duplicate grouping

If you only have wording similarity, that is not enough.

判定为重复项前，请至少从两类证据中收集信息。

gitcrawl

的关联项、搜索结果及集群成员仅作为候选重复项生成依据，本身不足以作为判定证据。

针对PR：

相同或几乎相同的问题描述
相同或重叠的文件修改范围
相同的修复方向
相同的子系统与故障模式
相同的关联Issue或相同的用户可见症状

针对Issue：

相同的用户可见问题
相同的复现步骤或相同的故障模式
相同的预期修复范围
已关联或讨论过相同的PR
相同的维护者已倾向于将其归为同一重复项分组

若仅存在表述相似性，不足以判定为重复项。

Step 1: Read The Target

步骤1：查看目标项

Start by reading the target itself. Use live GitHub for current target state.

For a PR:

bash

gh pr view <number> --json number,title,state,mergedAt,body,closingIssuesReferences,files,comments,reviews,statusCheckRollup

For an issue:

bash

gh issue view <number> --json number,title,state,body,comments,closedAt

Record:

target type and number
title
problem statement
proposed intent
subsystem
whether it is open, closed, or merged
whether there is already a likely duplicate thread mentioned by humans

首先查看目标项本身。使用在线GitHub获取目标项的当前状态。

针对PR：

bash

gh pr view <number> --json number,title,state,mergedAt,body,closingIssuesReferences,files,comments,reviews,statusCheckRollup

针对Issue：

bash

gh issue view <number> --json number,title,state,body,comments,closedAt

记录以下信息：

目标项类型与编号
标题
问题描述
提议的意图
所属子系统
当前状态（开启/关闭/已合并）
是否已有人员提及可能的重复线程

Step 2: Search Broadly With Gitcrawl

步骤2：使用Gitcrawl进行广泛搜索

Use

gitcrawl

first because it is the local OpenClaw history and clustering source. Do not switch to broad live GitHub search unless

gitcrawl

is missing data, stale, or failing.

Start with the target and nearby threads:

bash

gitcrawl threads openclaw/openclaw --numbers <issue-or-pr-number> --include-closed --json
gitcrawl neighbors openclaw/openclaw --number <issue-or-pr-number> --limit 20 --json

Then search key phrases and subsystem terms:

bash

gitcrawl search openclaw/openclaw --query "<key phrase from title or body>" --mode hybrid --limit 20 --json
gitcrawl search openclaw/openclaw --query "<subsystem or error phrase>" --mode hybrid --limit 20 --json

Inspect likely clusters:

bash

gitcrawl cluster-detail openclaw/openclaw --id <cluster-id> --member-limit 20 --body-chars 280 --json

For PRs, verify likely code overlap with live file data:

bash

gh pr view <candidate-pr> --json number,title,state,mergedAt,files,body,comments,reviews

For issues, verify likely duplicate issue state and comments live:

bash

gh issue view <candidate-issue> --json number,title,state,body,comments,closedAt

优先使用

gitcrawl

，因为它是OpenClaw的本地历史与聚类数据源。仅当

gitcrawl

缺失数据、数据过时或运行失败时，才切换到在线GitHub的广泛搜索。

先从目标项及关联线程开始：

bash

gitcrawl threads openclaw/openclaw --numbers <issue-or-pr-number> --include-closed --json
gitcrawl neighbors openclaw/openclaw --number <issue-or-pr-number> --limit 20 --json

然后搜索关键短语及子系统术语：

bash

gitcrawl search openclaw/openclaw --query "<从标题或正文中提取的关键短语>" --mode hybrid --limit 20 --json
gitcrawl search openclaw/openclaw --query "<子系统或错误短语>" --mode hybrid --limit 20 --json

查看可能的集群：

bash

gitcrawl cluster-detail openclaw/openclaw --id <cluster-id> --member-limit 20 --body-chars 280 --json

针对PR，使用在线文件数据验证可能的代码重叠：

bash

gh pr view <candidate-pr> --json number,title,state,mergedAt,files,body,comments,reviews

针对Issue，使用在线数据验证可能的重复项状态及评论：

bash

gh issue view <candidate-issue> --json number,title,state,body,comments,closedAt

Step 3: Use Live GitHub Search For Gaps

步骤3：使用在线GitHub搜索填补空白

Use targeted live GitHub search after

gitcrawl

when:

the target is too new for the local store
comments or reviews matter and the local store lacks them
the exact phrase did not appear in local results but the issue/PR is current enough that GitHub should know it

bash

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "<key phrase>"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "<key phrase>"
gh search issues --repo openclaw/openclaw --match comments --limit 50 -- "<error or maintainer phrase>"

在使用

gitcrawl

之后，若出现以下情况，请使用针对性的在线GitHub搜索：

目标项过新，未存储到本地
评论或评审内容很重要，但本地存储缺少这些数据
本地结果未出现精确短语，但该Issue/PR足够新，GitHub应能检索到

bash

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "<关键短语>"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "<关键短语>"
gh search issues --repo openclaw/openclaw --match comments --limit 50 -- "<错误或维护者短语>"

Step 4: Decide The Outcome

步骤4：判定结果

Choose one of these outcomes:

```
not_duplicate
```
```
duplicate_needs_judgment
```
```
duplicate_confirmed
```

Use

duplicate_confirmed

only when the evidence is strong enough that the maintainer could safely close or retag the duplicate item.

Use

duplicate_needs_judgment

when:

the problem looks the same but the implementation goal differs
the code overlap is weak
the issue wording is ambiguous
there may be two valid duplicate group interpretations
the target appears to intersect two existing duplicate groups

选择以下结果之一：

```
not_duplicate
```
（非重复项）
```
duplicate_needs_judgment
```
（重复项需进一步判断）
```
duplicate_confirmed
```
（确认重复项）

仅当证据足够充分，维护者可安全关闭或重新标记重复项时，才使用

duplicate_confirmed

。

在以下情况使用

duplicate_needs_judgment

：

问题看似相同，但实现目标不同
代码重叠性弱
Issue表述模糊
存在两种合理的重复项分组解读
目标项似乎与两个现有重复项分组相关

Step 5: Reuse Or Create One prtags Group

步骤5：复用或创建一个prtags分组

Before creating a group, search

prtags

for an existing one.

Start with text search over groups:

bash

prtags search text -R openclaw/openclaw "<problem phrase>" --types group --limit 10
prtags search similar -R openclaw/openclaw "<problem summary>" --types group --limit 10
prtags group list -R openclaw/openclaw

Inspect likely groups:

bash

prtags group get <group-id>
prtags group get <group-id> --include-metadata

Reuse an existing group when:

it represents the same problem
it already contains clearly related members
adding the target would keep the group coherent

Do not widen an existing group just because

gitcrawl

placed several PRs or issues near each other. Confirm that the actual implementation path and maintainer intent still match before adding the new member.

Create a new group only when no existing group clearly fits.

Create the group with a problem-based title and an intent-based description:

bash

prtags group create -R openclaw/openclaw \
  --kind mixed \
  --title "<problem-centered title>" \
  --description "<same intent, subsystem, and duplicate-resolution path>" \
  --status open

Then attach the target and any known duplicate members:

bash

prtags group add-pr <group-id> <pr-number>
prtags group add-issue <group-id> <issue-number>

If a target appears to already belong to another duplicate group and you cannot safely reuse that group, stop. Do not create a second group.

创建新分组前，请先在

prtags

中搜索现有分组。

先对分组进行文本搜索：

bash

prtags search text -R openclaw/openclaw "<问题短语>" --types group --limit 10
prtags search similar -R openclaw/openclaw "<问题摘要>" --types group --limit 10
prtags group list -R openclaw/openclaw

查看可能的分组：

bash

prtags group get <group-id>
prtags group get <group-id> --include-metadata

在以下情况复用现有分组：

该分组代表相同的问题
已包含明显相关的成员
添加目标项后仍能保持分组的一致性

请勿仅因

gitcrawl

将多个PR或Issue归为相近集群就扩大现有分组。添加新成员前，请确认实际实现路径与维护者意图仍匹配。

仅当没有现有分组明确匹配时，才创建新分组。

创建分组时，使用基于问题的标题和基于意图的描述：

bash

prtags group create -R openclaw/openclaw \
  --kind mixed \
  --title "<以问题为中心的标题>" \
  --description "<相同意图、子系统及重复项解决路径>" \
  --status open

然后添加目标项及所有已知的重复项成员：

bash

prtags group add-pr <group-id> <pr-number>
prtags group add-issue <group-id> <issue-number>

若目标项似乎已属于另一个重复项分组，且你无法安全复用该分组，请停止操作。请勿创建第二个分组。

Step 6: Ensure The Annotation Fields Exist

步骤6：确保注释字段存在

Use

field ensure

so the skill is idempotent.

Recommended target-level fields:

bash

prtags field ensure -R openclaw/openclaw --name duplicate_status --scope pull_request --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_status --scope issue --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope pull_request --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope issue --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope pull_request --type text --searchable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope issue --type text --searchable

Recommended group-level fields:

bash

prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope group --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope group --type text --searchable
prtags field ensure -R openclaw/openclaw --name cluster_summary --scope group --type text --searchable

使用

field ensure

命令确保技能具有幂等性。

推荐的目标级字段：

bash

prtags field ensure -R openclaw/openclaw --name duplicate_status --scope pull_request --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_status --scope issue --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope pull_request --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope issue --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope pull_request --type text --searchable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope issue --type text --searchable

推荐的分组级字段：

bash

prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope group --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope group --type text --searchable
prtags field ensure -R openclaw/openclaw --name cluster_summary --scope group --type text --searchable

Step 7: Save The Maintainer Judgment In prtags

步骤7：将维护者的判断保存到prtags中

For a PR:

bash

prtags annotation pr set -R openclaw/openclaw <pr-number> \
  duplicate_status=confirmed \
  duplicate_confidence=high \
  duplicate_rationale="<same problem, same fix direction, overlapping files and comments>"

For an issue:

bash

prtags annotation issue set -R openclaw/openclaw <issue-number> \
  duplicate_status=confirmed \
  duplicate_confidence=high \
  duplicate_rationale="<same user-visible problem and same intended fix path>"

For the group:

bash

prtags annotation group set <group-id> \
  duplicate_confidence=high \
  cluster_summary="<one-sentence problem summary>" \
  duplicate_rationale="<why these items belong in one duplicate cluster>"

When the evidence is incomplete, set

duplicate_status=candidate

and lower the confidence.

If a per-PR or per-issue annotation write fails because

prtags

cannot resolve the target, do not force a fallback write path. Keep the group state you were able to write, report that the curation backend is still missing the target object, and defer the target-level annotation until

prtags

catches up.

针对PR：

bash

prtags annotation pr set -R openclaw/openclaw <pr-number> \
  duplicate_status=confirmed \
  duplicate_confidence=high \
  duplicate_rationale="<相同问题、相同修复方向、重叠的文件与评论>"

针对Issue：

bash

prtags annotation issue set -R openclaw/openclaw <issue-number> \
  duplicate_status=confirmed \
  duplicate_confidence=high \
  duplicate_rationale="<相同的用户可见问题及相同的预期修复路径>"

针对分组：

bash

prtags annotation group set <group-id> \
  duplicate_confidence=high \
  cluster_summary="<一句话问题摘要>" \
  duplicate_rationale="<这些项属于同一重复项集群的原因>"

当证据不完整时，设置

duplicate_status=candidate

并降低置信度。

若因

prtags

无法解析目标项导致PR或Issue级别的注释写入失败，请勿强制使用回退写入路径。保留已成功写入的分组状态，报告分类筛选后端仍缺少目标对象，并推迟目标级注释操作，直到

prtags

完成同步。

Step 8: Let prtags Sync The Group Comment

步骤8：让prtags同步分组评论

Do not tell the agent to create a GitHub comment directly.

prtags

owns the outbound GitHub comment as a derived projection of group state.

In the normal case, do not manually trigger comment sync. When comment sync is configured, group writes already enqueue the derived comment projection automatically.

Use manual sync only as a repair or retry path:

bash

prtags group sync-comments <group-id>

If the maintainer needs to see which groups still need attention, use:

bash

prtags group list-comment-sync-targets -R openclaw/openclaw

The skill should treat the GitHub comment as a consequence of correct

prtags

group state. It should not treat manual comment authoring as part of the normal duplicate workflow. It should also not treat

sync-comments

as a required step for every duplicate decision.

请勿让Agent直接创建GitHub评论。

prtags

拥有对外的GitHub评论作为分组状态的衍生投影。

正常情况下，请勿手动触发评论同步。当配置好评论同步后，分组写入操作会自动将衍生的评论投影加入队列。

仅在修复或重试场景下使用手动同步：

bash

prtags group sync-comments <group-id>

若维护者需要查看哪些分组仍需处理，请使用：

bash

prtags group list-comment-sync-targets -R openclaw/openclaw

技能应将GitHub评论视为正确的

prtags

分组状态的结果。请勿将手动编写评论视为正常重复项工作流的一部分，也请勿将

sync-comments

视为每个重复项决策的必要步骤。

Output Format

输出格式

Return a short maintainer report with these sections:

text

Decision: duplicate_confirmed | duplicate_needs_judgment | not_duplicate
Target: PR #<n> | Issue #<n>
Confidence: high | medium | low

Evidence:
- ...
- ...
- ...

prtags actions:
- reused group <group-id> | created group <group-id>
- added members: ...
- annotations written: ...
- comment sync: automatic if configured | manual repair triggered for <group-id>

返回一份简短的维护者报告，包含以下部分：

text

Decision: duplicate_confirmed | duplicate_needs_judgment | not_duplicate
Target: PR #<n> | Issue #<n>
Confidence: high | medium | low

Evidence:
- ...
- ...
- ...

prtags actions:
- reused group <group-id> | created group <group-id>
- added members: ...
- annotations written: ...
- comment sync: automatic if configured | manual repair triggered for <group-id>

Stop Conditions

停止条件

Stop and escalate instead of forcing a duplicate decision when:

the target appears to belong to two different duplicate groups
the duplicate grouping is unclear
the wording matches but the implementation goals differ
two PRs touch the same files for different reasons
two issues describe similar symptoms but likely different root causes

The maintainer should get one clean duplicate judgment or an explicit “needs judgment” result. Do not blur the line.

出现以下情况时，请停止操作并升级处理，而非强制做出重复项判定：

目标项似乎属于两个不同的重复项分组
重复项分组判定不明确
表述匹配但实现目标不同
两个PR因不同原因修改相同文件
两个Issue描述相似症状但可能有不同的根本原因

维护者应得到一个清晰的重复项判定结果，或明确的“需进一步判断”结果。请勿模糊边界。