mcpField
T
tag-duplicate-prs-issues

tag-duplicate-prs-issues

github.com/openclaw开发393.3k394 次安装今天更新
代码仓库

关于 tag-duplicate-prs-issues

面向维护者的 PR 和 Issue 去重分组技能，帮助基于问题、意图和实现证据判断重复项，并通过 prtags 记录整理结果。

主要功能

  1. 01结合 gitcrawl 与实时 GitHub 核实候选
  2. 02要求多类证据支持重复判断
  3. 03复用或创建唯一去重组
  4. 04通过 prtags 保存判断与说明
  5. 05写入前检查工具和登录状态

适用场景

  1. 01维护者整理重复 PR
  2. 02维护者合并重复 Issue 线索

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/openclaw/openclaw --skill tag-duplicate-prs-issues

安装后在 Claude Code 中输入/tag-duplicate-prs-issues确认已加载。

附带文件agents/openai.yaml

详细介绍

标记重复的 PR 和 Issue

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

此技能用于维护者进行分类和归组。 不用于评审 PR 的实现质量。

必需设置

在完成此设置之前，请勿写入重复组或注释。 仍可使用 gitcrawl 和实时 gh 进行只读发现。

配套技能

先使用 $gitcrawl 在本地发现候选项。 如果 prtags 仓库的 skills/prtags/SKILL.md 中提供了 prtags 技能，请使用该技能。

安装 CLI

从下面的固定版本安装 prtags。 除非维护者明确希望测试未发布的行为，否则不要依赖旧的本地构建版本。

prtags CLI 安装路径：

GOBIN="$HOME/.local/bin" go install github.com/dutifuldev/prtags/cmd/[email protected]

prtags 位于 OpenClaw 组织之外，因此此安装固定使用经审查的 版本；该版本由 Go 模块代理解析，并由公共校验和数据库验证。GOBIN 会 将安装的可执行文件保留在与旧安装程序相同的用户本地目录中，因此现有的 $HOME/.local/bin PATH 仍会解析到新安装的版本。 不要将远程脚本通过管道传入 Shell 来安装，也不要让安装指向分支： 这两种做法都会以维护者自身的权限执行该第三方在运行时提供的任何内容。改用较新的 prtags 版本属于需要审查的文件修改，而不是任务中途的步骤。

验证 prtags 身份

应通过 OAuth 设备流程，使用维护者自己的 GitHub 账户登录 prtags。 交互式分类处理时，请勿使用共享的维护者令牌。

prtags auth login
prtags auth status

预期结果是，prtags 在本地存储登录的维护者身份，并使用该账户执行经过身份验证的写入操作。

设置缺失规则

开始工作流前无需进行预检查。 按正常步骤继续，直到确实需要某项工具或某种账户状态。

一旦在写入步骤中发现 prtags 缺失或未登录，请立即停止。 此后不要继续使用部分写入模式。

如果缺少 prtags，请让用户运行 安装 CLI 中固定的安装命令。 将该节作为已安装版本的唯一依据；不要临时另拟安装路径。

如果 prtags auth status 显示用户未登录，请让用户运行：

prtags auth login

仅在缺失的工具或登录状态修复后继续。

读取路径默认设置

在本工作流中发现候选项时，先使用 gitcrawl。 将其视为相关 Issue、重复尝试和已关闭讨论的本地历史与聚类层。

在作出可据以行动的判断之前，使用实时 gh 或 gh api 检查目标讨论和所有候选项。 如果有具体原因导致 gitcrawl 缺失或过期，请使用实时 GitHub，例如：

  • 目标或候选项尚未出现
  • 本地数据对于所需判断明显已过期或不完整
  • gitcrawl 报错、超时，或缺少所需的邻近项/搜索数据

回退到实时 GitHub 搜索时，请注明这一情况及原因。

如果后续 prtags 的目标级写入因其自身镜像尚未同步而失败，请停止并报告归类后端缺少目标对象，不要强制执行回退写入。

目标

对于每个目标 PR 或 Issue：

  1. 收集重复证据
  2. 判断是否确实重复
  3. 为该重复项聚类创建或复用一个 prtags 组
  4. 在 prtags 中保存维护者的判断
  5. 依靠正常的 prtags 组写入，在已配置该集成时触发 GitHub 评论同步

工具角色

按以下边界使用这些工具：

  • gitcrawl 用于生成候选项和获取历史背景
    • 首先使用它进行本地标题和正文搜索、查找邻近项、聚类和已关闭讨论串
    • 在通过 GitHub 实时信息确认之前，将每个候选项都视为线索
  • gh 是 GitHub 的事实来源
    • 使用它获取目标状态、正文、评论、审查、文件、关联议题以及当前的开放、关闭或合并状态
    • 仅当 gitcrawl 数据过期、数据缺失或无法表达所需查询时，才使用 gh search
  • prtags 是维护者整理层
    • 使用它创建或复用一个重复组
    • 使用它保存重复状态、置信度、判断依据和组摘要
    • 使用它作为 GitHub 上重复组评论的事实来源

工作规则

  • 不要仅因为标题相似，就将某项判定为重复项。
  • 不要仅因为修改了相同文件，就将某项判定为重复项。
  • 重复聚类应基于相同的用户侧问题、相同意图，以及在很大程度上重叠的实现或调查背景。

单组规则

将重复组视为互斥。 一个 PR 或议题在同一时间最多应归入一个重复组。

这意味着：

  • 创建新组前，先搜索是否已存在一个代表同一重复问题的组
  • 如果目标看起来已经属于另一个重复组，请停止操作并先解决冲突
  • 不要仅因措辞略有不同，就为同一目标创建第二个组
  • 如果两个看似合理的现有组存在重叠，且你无法安全地得出合并判断，请停止操作并询问维护者

此规则比速度更重要。 该技能应为每个问题保留一个连贯的重复聚类，而不是保留许多近似重复的聚类。

合适的重复组应体现什么

重复组应描述根本问题和预期修复方向。 不要仅因为条目共享某个关键词就将其分组。

良好的组形态：

  • 相同的用户侧缺陷或维护者侧任务
  • 相同的子系统或代码层面
  • 相同的预期变更方向
  • 相同的可能重复项解决路径

不佳的组形态：

  • “所有涉及 Slack 的 PR”
  • “所有提到重试的议题”
  • “所有与身份验证相关的条目”

组标题应指明实际问题。 组描述应总结意图和涉及的代码层面。

示例：

  • gateway: startup regression from channel status bootstrap
  • whatsapp: QR preflight timeout handling
  • release: cross-OS validation handoff gaps

证据核对清单

在判定为重复项之前，至少从两个类别收集证据。 gitcrawl 的邻近项、搜索命中和聚类成员关系属于候选项生成，本身不足以构成充分证据。

对于 PR：

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

对于议题：

  • 相同的用户可见问题
  • 相同的复现过程或相同的故障模式
  • 相同的可能修复区域
  • 已关联或讨论过相同的 PR
  • 相同的维护者，且其讨论已推动形成同一个重复组

如果你掌握的只有措辞相似性，则不足以判定。

第 1 步：读取目标

先阅读目标本身。 使用 GitHub 实时信息获取目标的当前状态。

对于 PR：

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

对于议题：

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

记录：

  • 目标类型和编号
  • 标题
  • 问题描述
  • 拟议意图
  • 子系统
  • 当前状态是开放、关闭还是已合并
  • 是否已有人员提到可能的重复讨论串

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

优先使用 gitcrawl，因为它是本地 OpenClaw 历史记录和聚类数据源。 除非 gitcrawl 缺少数据、数据过旧或运行失败，否则不要切换到实时 GitHub 广泛搜索。

从目标及附近的讨论串开始：

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

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

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

检查可能的聚类：

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

对于 PR，使用实时文件数据验证可能的代码重叠：

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

对于 Issue，实时核实可能重复项的状态和评论：

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

第 3 步：使用实时 GitHub 搜索填补空白

在以下情况下，于使用 gitcrawl 后进行有针对性的实时 GitHub 搜索：

  • 目标对于本地存储而言太新
  • 评论或 reviews 很重要，而本地存储缺少这些内容
  • 精确短语未出现在本地结果中，但该 Issue/PR 足够新，GitHub 理应已有相关记录
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>"

第 4 步：确定结果

选择以下结果之一：

  • not_duplicate
  • duplicate_needs_judgment
  • duplicate_confirmed

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

出现以下情况时，使用 duplicate_needs_judgment：

  • 问题看似相同，但实现目标不同
  • 代码重叠较弱
  • Issue 表述含糊
  • 可能存在两种合理的重复分组方式
  • 目标似乎与两个现有重复组相交

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

创建组前，先搜索 prtags 中是否已有组。

先对组进行文本搜索：

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

检查可能的组：

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

出现以下情况时，复用现有组：

  • 它代表同一个问题
  • 其中已包含明确相关的成员
  • 添加目标后，该组仍能保持一致性

不要仅因为 gitcrawl 将多个 PR 或 Issue 聚集在一起，就扩大现有组。 添加新成员前，确认实际实现路径和维护者意图仍然一致。

仅当没有现有组明显适合时，才创建新组。

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

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

然后附加目标及任何已知重复成员：

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

如果目标似乎已属于另一个重复组，且无法安全复用该组，请停止。 不要创建第二个组。

第 6 步：确保标注字段存在

使用 field ensure，使该技能保持幂等。

推荐的目标级字段：

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

推荐的组级字段：

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

第 7 步：在 prtags 中保存维护者判断

对于 PR：

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>"

对于 Issue：

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>"

对于组：

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>"

证据不完整时，设置 duplicate_status=candidate 并降低置信度。

如果因 prtags 无法解析目标而导致单个 PR 或 Issue 的标注写入失败，请勿强行采用备用写入路径。 保留已成功写入的组状态，报告整理后端仍缺少目标对象，并将目标级标注推迟，直至 prtags 追上进度。

第 8 步：让 prtags 同步组评论

不要指示 Agent 直接创建 GitHub 评论。 prtags 负责将出站 GitHub 评论作为组状态的派生投影。

正常情况下，不要手动触发评论同步。 配置评论同步后，组写入已自动将派生评论投影加入队列。

仅在修复或重试时使用手动同步：

prtags group sync-comments <group-id>

如果维护者需要查看哪些组仍需关注，请使用：

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

该技能应将 GitHub 评论视为 prtags 组状态正确的必然结果。 它不应将手动创建评论视为常规重复项工作流的一部分。 它也不应将 sync-comments 视为每项重复判断都必须执行的步骤。

输出格式

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

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>

停止条件

出现以下情况时，应停止并升级处理，而不是勉强作出重复判定：

  • 目标看起来属于两个不同的重复组
  • 重复分组不明确
  • 措辞相同，但实现目标不同
  • 两个 PR 因不同原因触及相同文件
  • 两个问题描述了相似的症状，但根因可能不同

维护者应得到一个明确的重复判定，或一个明确的“需要判断”结果。 不要模糊界限。

评论

支持 Markdown