Back to Details

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.
If 
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"
If 
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
or 
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:
  1. gather duplicate evidence
  2. decide whether it is a real duplicate
  3. create or reuse one 
    prtags
    group for that duplicate cluster
  4. save the maintainer judgment in 
    prtags
  5. rely on normal 
    prtags
    group writes to drive GitHub comment sync when that integration is configured
针对每个目标PR或Issue，完成以下步骤：
  1. 收集重复项证据
  2. 判断其是否为真正的重复项
  3. 为该重复项集群创建或复用一个
    prtags
    分组
  4. 将维护者的判断保存到
    prtags
    中
  5. 当配置好集成后，依赖
    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描述相似症状但可能有不同的根本原因
维护者应得到一个清晰的重复项判定结果，或明确的“需进一步判断”结果。请勿模糊边界。