OpenClaw 重复 PR/Issue 甄别工作流gitcrawl 候选发现、prtags 分组与 GitHub 评论同步的完整实现【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclawOpenClaw 仓库中维护了一套针对重复 PR/Issue 的分诊技能skill核心文件为 .agents/skills/tag-duplicate-prs-issues/SKILL.md。该技能定义了本地历史检索gitcrawl→ 实时 GitHub 验证gh→ 维护者裁决落库prtags→ 评论自动同步的完整链路。读完本文你将掌握这套三工具分工的分诊流程、重复判定的证据规则与单组原则并能复现其中的全部命令、字段定义和裁决输出格式同时了解仓库中配套的自动化关闭脚本 scripts/close-duplicate-prs-after-merge.mjs 如何用 hunk 级 diff 重叠来硬性佐证重复结论。1. 技能定位只判重复不评质量该 skill 的 frontmatter 明确了使用场景name: tag-duplicate-prs-issues description: Use gitcrawl to search duplicate OpenClaw PRs/issues, group related work in prtags, and sync duplicate state to GitHub.技能文档开宗明义这是给维护者做分诊和归类用的不是用来评审 PR 实现质量的This skill is for maintainer triage and grouping. It is not for reviewing the implementation quality of a PR.。配套元数据 agents/openai.yaml 中也给出了技能的一句话触发描述Find duplicate PRs and issues with gitcrawl, group them in prtags, and let prtags sync the GitHub comment。技能的最终目标Goal被归纳为五步收集重复证据gather duplicate evidence判定是否为真实重复decide whether it is a real duplicate为该重复簇创建或复用一个prtags分组create or reuse one prtags group把维护者裁决保存到prtagssave the maintainer judgment in prtags依赖prtags的正常分组写入来驱动 GitHub 评论同步rely on normal prtags group writes to drive GitHub comment sync when that integration is configured2. 前置准备安装 prtags、OAuth 登录与缺件即停规则2.1 配套技能与 CLI 安装文档要求在 setup 完成前不要写入任何重复分组或标注但只读的发现阶段read-only discovery可以只依赖gitcrawl和实时gh继续推进。配套技能有两处$gitcrawl本地候选发现的第一入口。仓库中对应的技能定义在 .agents/skills/gitcrawl/SKILL.md其 metadata 声明gitcrawl是一个 Go 二进制github.com/openclaw/gitcrawl/cmd/gitcrawllatest职责是GitHub archive: issue/PR search, sync freshness, duplicate clusters, gh-shim PR status。prtags来自独立仓库的 CLI技能文档要求从该仓库最新的 GitHub Release 安装不要依赖旧的本地构建除非维护者明确想测试未发布行为curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir $HOME/.local/bin2.2 认证维护者本人 OAuth 设备流prtags必须以维护者本人账号通过 OAuth device flow 登录明确禁止用共享维护者 token 做交互式分诊prtags auth login prtags auth status预期结果是prtags在本地保存登录的维护者身份并以此身份执行所有认证写操作。2.3 Missing-Setup Rule不要前置预检但要缺件即停文档对 setup 的检查策略写得很细值得单独提炼不要在工作流一开始做强制 preflight正常步骤先走直到真正需要某个工具或账号状态为止一旦发现prtags缺失或未登录发生在写步骤时立即停止不得在半写状态partial write mode下继续缺失工具时引导用户执行上面的 install 脚本prtags auth status显示未登录时引导用户执行prtags auth login只有在缺失的工具或登录状态被修复后才允许恢复工作流。这条规则的意义在于分诊是读多写少的工作流把预检推迟到真正写之前既不影响只读探索又能保证所有写操作要么完整发生、要么完全不发生。3. 读路径默认值Read-Path Defaultgitcrawl 优先gh 兜底技能对工具角色划定了清晰的边界这是理解整套流程的骨架工具角色边界gitcrawl候选生成 历史上下文本地 title/body 搜索、neighbors、clusters、已关闭线程发现所有候选在被实时 GitHub 确认前都只是线索gh实时 GitHub 事实目标状态、正文、评论、review、文件、关联 issue、当前 open/closed/merged 状态仅当 gitcrawl 陈旧、缺数据或无法表达查询时才用gh searchprtags维护者策管层创建/复用一个重复分组保存重复状态、置信度、理由、组摘要作为面向 GitHub 的分组评论的唯一事实来源允许放弃 gitcrawl 改用实时 GitHub 搜索的情形被限定为三种具体理由目标或候选尚未入库、本地数据对当前决策明显陈旧/不完整、gitcrawl 报错或超时或缺少所需数据。回退到实时搜索时必须注明回退及原因。gitcrawl 技能文档.agents/skills/gitcrawl/SKILL.md还补充了两个关键实践检查同步新鲜度gitcrawl doctor --json铁律Do not close/label from similarity alone; require matching intent plus live verification.——不得仅凭相似度就关闭/打标必须意图匹配 实时验证。还有一条针对写失败的兜底规则如果后续的prtags目标级写入失败原因是其自身 mirror 尚未同步到位则应停止并报告curation backend 缺少该目标对象而不是强行走 fallback 写路径。4. 判定规则证据清单与单组原则4.1 什么才算重复工作规则Working Rules给出了三条否定式判据不能仅因为标题相似就判重不能仅因为改了相同的文件就判重重复簇必须基于相同的用户可见问题 相同意图 实质重叠的实现或调查上下文。4.2 证据清单Evidence Checklist宣布重复前证据必须来自至少两个类别。特别注意gitcrawl 的 neighbors、搜索命中、cluster 成员身份只算候选生成本身不构成足够证明。针对PR可用的证据维度相同或几乎相同的问题陈述相同或范围重叠的变更文件相同的修复方向相同子系统和相同失效模式相同的关联 issue 或相同的用户可见症状针对Issue可用的证据维度相同的用户可见问题相同的复现路径或失效模式相同的疑似修复区域相同已关联/已讨论的 PR相同维护者已在把两边引向同一个重复归类只有措辞相似only have wording similarity被明确列为不合格证据。4.3 单组原则One-Group Rule重复分组被定义为互斥的一个 PR/Issue 同一时间最多属于一个重复组。由此推出四条操作约束建新组之前先搜索是否已有表达同一重复故事的组若目标似乎已属于另一个重复组先停下解决冲突不能因为措辞略有不同就为同一目标建第二个组若两个候选组重叠且无法安全合并裁决停下并询问维护者。文档特意强调This rule matters more than speed.——宁可慢也要保持每个问题一个内聚的重复簇而不是产生一堆近重复簇。4.4 好分组 vs 坏分组的形状一个合格的重复组应该描述底层问题和预期修复方向不能只因共享某个关键词就归组好形状相同的用户可见 bug 或维护者任务、相同子系统/代码面、相同的变更方向、相同的重复处置路径坏形状反例所有碰过 Slack 的 PR、所有提到 retry 的 issue、所有 auth 相关条目组标题应命名真实问题组描述应概括意图与代码面。文档给出的三个正面示例gateway: startup regression from channel status bootstrapwhatsapp: QR preflight timeout handlingrelease: cross-OS validation handoff gaps5. 八步工作流从读取目标到评论同步Step 1读取目标Read The Target一律用实时 GitHub 获取目标当前状态。PR 用gh pr view number --json number,title,state,mergedAt,body,closingIssuesReferences,files,comments,reviews,statusCheckRollupIssue 用gh issue view number --json number,title,state,body,comments,closedAt需要记录八项信息目标类型与编号、标题、问题陈述、预期意图、子系统、open/closed/merged 状态、是否已有人文提及疑似重复线程。Step 2gitcrawl 广域检索gitcrawl 是本地 OpenClaw 历史与聚类源只有当它缺数据、陈旧或故障时才切换到广域实时搜索。命令按目标与邻近线程 → 关键短语/子系统检索 → 集群细看 → 候选实时验证四段展开# 目标线程与邻居 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,closedAtStep 3实时 GitHub 搜索补盲在 gitcrawl 之后仅当满足以下情形才做定向实时搜索目标太新、本地库没有评论/review 重要而本地库缺失确切短语本地没有但 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 phraseStep 4做出三选一裁决每个目标必须落到以下三种结果之一not_duplicateduplicate_needs_judgmentduplicate_confirmed仅当证据强到维护者可以安全关闭或重新打标该重复项时才使用使用duplicate_needs_judgment的明确情形问题看似相同但实现目标不同代码重叠弱措辞含糊可能存在两种合理的重复组解释目标似乎同时交叠两个已存在的重复组。Step 5复用或创建一个 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若目标似乎已属于另一个组且无法安全复用停止不要创建第二个组。Step 6幂等地确保标注字段存在用field ensure保证技能幂等。目标级PR 与 Issue 各一套字段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注意duplicate_status的三值not_duplicate,candidate,confirmed与 Step 4 的三态裁决形成映射证据不全时写入candidate并调低置信度。Step 7保存维护者裁决PR 与 Issue 各自写入目标级标注prtags annotation pr set -R openclaw/openclaw pr-number \ duplicate_statusconfirmed \ duplicate_confidencehigh \ duplicate_rationalesame problem, same fix direction, overlapping files and commentsprtags annotation issue set -R openclaw/openclaw issue-number \ duplicate_statusconfirmed \ duplicate_confidencehigh \ duplicate_rationalesame user-visible problem and same intended fix path组级标注prtags annotation group set group-id \ duplicate_confidencehigh \ cluster_summaryone-sentence problem summary \ duplicate_rationalewhy these items belong in one duplicate cluster两条失败处理规则证据不全时写duplicate_statuscandidate并降低置信度若目标级标注写失败是因为prtags无法解析目标mirror 未追上则不要强制 fallback 写保留已写成功的组状态报告 curation backend 缺少该目标对象推迟目标级标注直到prtags追上。Step 8让 prtags 同步组评论这条设计是整个技能最有架构意味的一点不要指示 Agent 直接创建 GitHub 评论。prtags拥有对外的 GitHub 评论它是组状态的派生投影derived projection of group state。配置了评论同步后组写入本身就会自动入队派生评论正常情况不需要手动触发同步。手动同步只作为修复/重试路径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停止条件Stop Conditions要求遇到以下情况时停下升级而不是硬判目标似乎属于两个不同重复组重复归类不清晰措辞匹配但实现目标不同两个 PR 因不同原因触碰相同文件两个 issue 症状相似但疑似不同根因。维护者得到的要么是一个干净的重复裁决要么是一个明确的 needs judgment 结果——Do not blur the line.6. 仓库源码佐证hunk 级证据的自动化落地技能文档反复强调代码重叠必须与意图匹配相互印证仓库中与之形成闭环的自动化实现是 scripts/close-duplicate-prs-after-merge.mjs——一个在 PR 落地merge后关闭重叠候选 PR 的脚本。它的证据模型恰好是技能证据清单在代码面的精确化共享 issue 引用issueRefsFromPr()从closingIssuesReferences以及标题/正文中的close(s|d)/fix(e|s|d)/resolve(s|d)? #N正则中提取 issue 号求交集hunk 级重叠parseUnifiedDiffRanges()解析 unified diff 的 -old new,count 行得到每个文件的变更行区间hasOverlappingHunks()做区间相交判断——这比技能文本中相同或范围重叠的变更文件更细一档直接落到行号区间硬性闸门buildDuplicateClosePlan()中若既无共享 issue 又无重叠 hunk直接抛错拒绝关闭Refusing to close ... no shared issue and no overlapping changed hunks与技能不能仅凭标题相似判重的原则在代码上同构默认 dry-runparseArgs()中--apply缺省为 false未显式传--apply时只打印计划dry-run only; pass --apply to label/comment/close duplicate PRs执行时按打标 → 评论 → 关闭三步操作默认标签集为duplicate、close:duplicate、dedupe:child。其用法为node scripts/close-duplicate-prs-after-merge.mjs --landed-pr number --duplicates numbers [--repo owner/repo] [--apply]对应的测试 test/scripts/close-duplicate-prs-after-merge.test.ts 用 vitest 覆盖了关键语义PR 列表解析逗号/空白/#前缀混排、unified diff hunk 区间解析以及两个典型的判重放行用例——无显式 issue 引用但 hunk 重叠和issue 引用相同但 hunk 已漂移验证了两类证据任取其一即可、但必须至少有一类的判定逻辑。这与技能文档 Step 4 的谨慎姿态一致脚本只在机械可证的重叠下自动关闭而需要维护者判断的部分意图是否相同仍留给 tag-duplicate-prs-issues 工作流与 prtags 裁决。7. 小结这套流程可迁移的设计原则从 SKILL.md 与配套脚本看OpenClaw 的重复甄别体系沉淀了几条可复用的工程原则分层事实源本地缓存gitcrawl只做候选生成实时 APIgh负责事实核验策管库prtags负责裁决与对外投影三层各司其职、互不越权写操作的原子性纪律缺件即停、mirror 未追上即停、不 fallback 强写保证外部可见状态不会出现半套标注评论即派生物GitHub 评论不手工撰写而是组状态的投影手工同步仅作修复手段——这消除了评论与标注不一致这类长期漂移问题;证据可计算化从至少两类证据的自然语言规则到脚本里共享 issue 交集 hunk 区间相交的机械判定重复判定在规则层与代码层保持了同一套证据模型。适用前提提醒prtags为独立仓库的 CLI需从 Release 安装并完成 OAuth 登录gitcrawl为 Go 二进制见 .agents/skills/gitcrawl/SKILL.md 的 metadata所有-R openclaw/openclaw命令假定在 OpenClaw 仓库上下文中运行gh需已登录且有仓库读写权限。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考