# 问题/PR Cluster Deduper 当针对常见故障模式（Slack、iMessage、支持线程或手动列表）报告了一组 GitHub 问题和拉取请求，并且您需要基于证据的重复数据删除建议或执行时，请使用此技能。 ## 目的为问题和 PR 集群提供一致的、以证据为导向的分类通道，从而消除重复工作、保留贡献者信用，并使清理行动保持可审计性。执行是命令主导的且保守的：仅通过“gh”读回加上确定性文件/元数据检查来驱动决策，并避免超出分类逻辑的推测性本地分析。主要目标：通过明确的每项操作、链接和命令结果，使每次运行都做好准备。 ## 愿景将每个集群视为一个分类系统，而不是一个文档练习。预期的行为是确定性分类、可审核的注释文本、安全变异流和快速操作员理解。 ## 原理（执行前必读）这些在“principles.md”中定义： * 证据胜于叙述 * 标题相似度的根本原因对齐 * 保信归因 * 安全默认设置（“空运行”和拦截器） * 注释和标签中的完整审计跟踪 * 以人为本：像高级开发人员倡导者一样进行沟通，而不是像脚本一样。在选择最终结果之前，请阅读“constitution.md”以了解治理要求和决策质量规则。 ## 操作员经验和通信默认值此工作流程是为高速维护者和外部贡献者设计的： * 确保每条回复简短、清晰且尊重。 * 以发生的事情为主导，然后说明原因。 * 包括简单的英语下一步并重新打开路径。 * 避免唐突或指责性的语言，尤其是重复的内容。 * 永远不要隐藏不确定性；如果被阻止，请说出缺少什么以及接下来需要什么。 * 将助理视为开发者体验主管：乐于助人、实用且直接，但不会听起来机械。 * 使用示例作为风格指导，而不是逐字粘贴的模板。 * 改变每条消息的句子顺序和开头行，因此重复运行听起来并不相同。 * 不要在一次集群运行中重复完全相同的消息正文两次，除非不可能存在安全变化。 * 使用简短的对话段落（2-4 段），并避免单行机器人模板。 * 如果意图明确，即使在结束时也要保持语气温暖和解释性。 ## 何时使用 * 您有一组可疑的重复项，需要分类为规范/相关/独立。 * 您需要一个具有确切状态的具体行动计划，而不是笼统的评论。 * 用户要求执行安全关闭/标签/评论步骤。 * 您需要确定哪些更改应保持规范，以避免重复的公关流失。 ## 输入 * `cluster_refs`（必需）：ID 或 URL 形式的问题/PR 引用列表。 * `mode`（可选）：`plan`（默认）或`execute`。 * `channel`（可选）：源上下文，如 `slack`、`imessage`、`support` 等。 * `repo` （可选）：不使用当前结账时显式的 `owner/repo`。 * `canonical_hint` （可选）：存在歧义时的明确偏好。 * `merge_guard` （可选）：`高|中` 合并严格性；默认“高”。 * `max_changed_files_for_canonical`（可选）：默认`30`。 * `max_delta_lines_for_canonical`（可选）：默认`2500`。 * `min_greptile_score` （可选）：默认为 `65`（如果可用）。 * `body_noise_mode` （可选）：`strict|medium` 用于垃圾体容忍度；默认“中”。 * `reuse_copy_detection` （可选）：`off|on` 与默认的 `on` 用于机器人/复制工作检查。 * `bot_author_pattern`（可选）：可疑作者的子字符串列表。 * `merge_tool_pref` （可选）：`auto`、`gh`、`merge-skill` 或 `land-skill`；默认“自动”。 * `dry_run` （可选）：`0|1` 强制非变异模式。 * `output_mode` (可选): `compact|detailed`;默认“详细”。 * `triage_report`（可选）：分类报告文件的路径（如`/Users/vincentkoc/Desktop/triage_report.md`），用于种子初始集群候选。 * `search_limit`（可选）：GH 搜索中每个项目的最大相似项目数；默认“12”。 * `search_queries` （可选）：显式查询术语（以空格分隔）。 ## 输出 * 具有明确状态的每项操作矩阵（`KEEP_OPEN_CANONICAL`、`CLOSE_DUPLICATE`、`KEEP_OPEN_RELATED`、`KEEP_OPEN_UNRELATED`、`MANUAL_REVIEW_REQUIRED`），每行显示标题+作者。 * 具有根本原因映射、范围增量和风险阻止因素的证据矩阵。 * 信用链和归因原理（单信用违约，双信用仅例外）。 * 所需的命令集（空运行和执行模式）：关闭、注释、标签、合并和更改日志操作。 *“需要手动审核”结果的升级列表，包含置信度分数和硬停止原因。 ## 子代理编排在该链中使用子代理可以获得更高的一致性和更低的错误： * `agents/cluster-intake-agent.md` * `agents/cluster-similarity-agent.md` * `agents/cluster-evidence-agent.md` * `代理/集群决策代理.md` * `agents/cluster-synthesis-agent.md` 按顺序运行并将每个输出馈送到下一个输出。 * 摄入→相似性→证据→决策→综合。 1. 摄入：标准化集群引用（首先需要），包括可选的 `triage_report` 扩展。 2. 相似性：从 GitHub 搜索中找到其他相关的开放问题/PR，并附上排名的候选者。 3. 证据：获取集群+相似候选者的完整背景。 4. 决策：绘制风险和硬停止状态图。 5.综合：发出最终的行动矩阵和指挥计划。如果任何子代理阻塞，则仅在明确的“需要手动审查”的情况下继续，并保持执行安全。当协调器支持存在时，将它们作为链运行并在步骤之间传递结构化输出： * 从`cluster-intake-agent`开始 * 将输出馈送到“cluster-similarity-agent” * 将输出馈送到“cluster-evidence-agent” * 将输出馈送到“cluster-decision-agent” * 将输出馈送到“cluster-synthesis-agent” 如果子代理不可用，请按此文件顺序手动执行相同的步骤，并保持输出格式不变。 ## 一致的工具 UI 的执行规则在运行时使用“update_plan”并一次保留一个正在进行的步骤。 *“发现”→“评估”→“计划”→“执行”（如果需要）→“验证”。 * 在“in_progress”和“completed”之间转换每个阶段。 * 如果存在硬停止阻止程序，请将“执行”保留为“待处理”并返回“需要手动审核”。 * 这使 Codex/Cursor/Claude 执行格式保持一致。 ## 工作流程 1. 集群摄入和标准化 * 将每个输入解析为规范链接和类型。 * 跳过格式错误的条目，并附上“需要手动审核”的合理注释。 2.相似度扫描（必填） * 使用提供的“cluster-intake-agent”摘要作为主要种子。 * 通过运行 GitHub 查询来扩展搜索范围以查找其他候选者，并将可能的邻居包含在同一根本原因系列中。 * 拉： * `gh 问题列表 --search " in:title" --state all --repo --json 数字、标题、url、状态、作者、updatedAt、标签` * `gh pr list --search " in:title" --state all --repo --json 数字、标题、url、状态、作者、updatedAt、isDraft、可合并` * 当标题/正文重叠明确时，保留可能的匹配项，而不仅仅是关键字。 3. 从 GitHub 获取证据 * 对于 PR：`gh pr view --json number,title,body,state,author,labels,createdAt,updatedAt,mergedAt, returnedAt,mergeable,mergeStateStatus,isDraft,changedFiles,additions,deletions,statusCheckRollup,commits,url` * 对于问题： `gh 问题视图 --json number,title,body,state,labels,author,createdAt,updatedAt,url,comments` * 在决定规范范围时提取 PR 的文件足迹：`gh pr diff --name-only` * 拉取 PR 的检查状态：`gh pr 检查 ` * 拉取评论/AI 工具信号文本：`gh issues view --json comments` 4、规范护栏 * 可合并性：可合并标志、合并状态阻止程序、草稿状态、检查汇总状态。 * 流失：“更改的文件”、“添加”、“删除”。 * 身体卫生：具体的根本原因细节与仅模板/占位符文本。 * AI 评论分数：低于阈值的类似 Greptile 的评论会降低信心。 * 复制/机器人信号：生成/复制的语言、类似机器人的作者、低证据的机械提交。 * 任何硬停止问题都会将项目标记为“需要手动审核”并阻止自动关闭。 5. 审查候选规范 * 对于每个顶级候选 PR：“gh pr view --json files”和“gh pr diff ”。 * 如果健康，则视为规范候选人并进行合并准备。 * 如果两个候选人相当，则更喜欢稳定、风险较低的范围。 * 如果较新的 PR 是超组安全的，则更喜欢具有更高表面修复覆盖率的较新 PR。 6. 决定结果 * 规范问题/PR：保持开放。 * 重复的 PR/问题：以明确的评论和合理的消息结束。 * 相关不重复：保持开放并标记关系。 * 不相关：分成单独的集群/路由注释。 * 对于任何硬停止故障：使用明确的阻止程序保持“需要手动审查”。 7. 合并和变更日志跟进 * 如果执行 + 获胜 PR 为绿色： * 更喜欢合并/着陆助手（如果可用） * 后备： `gh pr merge --auto --merge` （或回购策略 `--squash` / `--rebase`） * 重新运行检查发现并报告最终状态 * 如果需要更改日志，请在未发布的“### 修复”下仅添加一次，并且不要重复现有条目。 * 如果无法在合并之前添加变更日志，则仅在存储库策略需要时才创建后续压缩提交。 8. 发出结果 * 在“计划”模式下：仅草稿评论、标签、关闭命令和阻止程序。 * 在“执行”模式下：在所有护栏通过后仅运行安全的 GH 突变。 * 使用下面所需的格式返回最终输出。 9. 治理漂移审查 * 检查“AGENTS.md”和“CONTRIBUTING.md”以了解范围更改或存储库策略更改。 * 验证输出是否保留明确的信用参考和简明的问题/公关参考。 ## 治理和防漂移检查 * 如果存储库具有更高优先级的指令源（特定于项目的代理/贡献者），则该源优先于该技能的默认值。 * 保持密切的原因和评论符合存储库约定。 * 永远不要忽略所需的验证门。 ## 所需的最终输出格式 ### 集群摘要（紧凑） * 规范 PR：`` * 规范问题：`` * 合并门：`` * 信用链：`<基础工作参考文献 + 最终修复参考文献>`（在 95% 以上的情况下默认为 1 个贡献者；仅在明确例外的情况下最多为 2 个贡献者） * 试运行：`` ### 每项操作矩阵（必需）将其呈现为表格：项目 |行动|标题 |作者 |神器|基本原理 |目标 ---|---|---|---|---|---|--- `pr:xxxxx` | `KEEP_OPEN_CANONICAL` | `流式接收者 ID 根本原因修复` | `@canonical_author` | `https://github.com/openclaw/openclaw/pull/xxxxx` | `规范的补救路径` | ``-`` `问题：yyyyy` | `CLOSE_DUPLICATE` | `松弛流停止竞争条件` | `@duplicate_author` | `https://github.com/openclaw/openclaw/issues/yyyyy` | “被规范公关覆盖” | `#zzzzz` `问题：aaaaa` | `KEEP_OPEN_RELATED` | `块模式发射行为不匹配` | `@相关作者` | `https://github.com/openclaw/openclaw/issues/aaaaa` | `相邻区域：块路径语义` | ``-`` 必需的矩阵字段：项目、操作、标题、作者、工件链接、简短理由以及规范目标/重复映射目标（如果适用）。 ### 命令/结果块（必需）将命令结果渲染为表格：状态 |命令|状态 ---|---|--- `计划的`/`执行的`/`阻止的` | `gh 问题视图...` | “通过”/“已申请”/“被检查阻止” 包括每个操作的准确命令文本和结果状态。 ### 证据矩阵（必填）将每个项目的证据呈现为表格：项目 |标题 |作者 |根本原因标记 |范围增量 |合并风险|信心 ---|---|---|---|---|---|--- `pr:xxxxx` | `流式接收者 ID 根本原因修复` | `@canonical_author` | `接收者 ID + 流管道` | `触及流 API + 块管道` | `低` | ‘高’ 阻止者必须是明确的。 ### 信用和关闭理由块（必填） * 所有合并/关闭结果的显式信用链，在 95% 以上的情况下默认有一个信用贡献者；仅通过显式例外最多为两个。 * 规则：默认一名贡献者（目标 95% 以上的案例），仅当较早的 PR 不可合并且较晚的 PR 是直接、干净的延续时才默认两名贡献者。 * 每个非规范项目的规范/相关边界原理。 * 使用上面的通信默认值，为每个评论关闭操作包含准确的面向客户的消息正文（或模板）。 ### 升级 * 列出未解决的障碍和不确定性，并注明“需要手动审核”（如果有）。 * 包括每个项目的置信度（“高|中|低”）和难以停止的原因。 ## 消息模板 ### 消息行为契约仅使用模板意图；不要在问题/PR 中重述确切的措辞。 * 从上下文确认开始。 * 用简单的语言解释保留/关闭决定。 * 说明为什么选择这条路径。 * 当存在不确定性时，包括直接重新开放路径。 * 以一个明确的下一步行动结束。与严格的块复制相比，更喜欢句子变化。保持语法自然，避免重复的措辞。 ### 规范公关信用额度风格规则：使用以下意图，然后自然地为每条消息改变措辞。不要输出单个固定文本。 “这里进步很大。最终修复位于 @ 的 # 中。这是我们保留的版本，因为它是最稳定、最完整的路径。如果您认为存在差距，请告诉我，我将立即重新开启审核。默认单学分模板：`感谢您之前的贡献。最终修复位于 @ 的 # 中。您早期的贡献已保存在规范历史中。如果这看起来不对劲，请告诉我，我可以立即重新审查。出色的双学分模板：“我很欣赏之前的通行证。最终修复位于@ 和@ 的# 中。 # 中的早期路径奠定了坚实的基础，而后来的 PR 完成了合并安全的延续。如果需要更正，请告诉我，我可以立即重新检查信用和关闭。 ### 关闭重复的 PR “感谢您之前的贡献。我将把它作为 # 的重复项来关闭。这里的尝试很棒，但是这个 PR 已经过时了，一个更新的、稳定的 PR 正在处理相同的根本原因路径。您的作品将保存在规范归属追踪中。如果这是一个错误，请告诉我，我可以立即重新审查。单信用关闭模板：“我感谢您推动这一点。我将把它作为 # 的重复项来关闭。这是较早的步骤，新的规范修复现在包括所涵盖的范围。如果感觉不对，请告诉我，我可以立即重新审查。出色的双信用关闭模板：“感谢您接受此任务。我将把它作为 # 的重复项来关闭。 # 创建了初始路径，后来的 PR 将其带入合并安全的延续中。这两项贡献都保留在规范信用记录中。如果这是一个错误，请告诉我，我可以立即重新审查。 ### 保持规范问题开放 `将其作为该集群的规范保持开放。这似乎是我们正在解决的渠道集群的共同问题形式。如果应该重新分配，请告诉我你看到了什么，我将重新评估边界。 ### 关闭重复问题 “谢谢你的报告。我将其作为 # 的重复项关闭。相同的故障模式和行为映射到那里的规范修复路径。如果这是一个错误，请告诉我，我可以立即重新审查。 ### 相关/不重复 “提出这个问题是个好主意。这看起来相关，但这不是重复的。它在 {reason} 处分叉，因此它保持为单独的轨道。如果这感觉像是错过了，请告诉我，我可以尽快重新检查。 ### 不相关 “感谢您举报这一点。这看起来与该集群分离，并将保留在其自己的线程中。如果这看起来相关，请指出共享故障步骤，我可以立即重新运行重复数据删除。 ### 变化示例使用起始组（切勿在一次运行中重玩同一个开场游戏两次）： “这个电话打得很好。我将其作为 #xxxxx 的重复项来关闭。现在，规范修复中涵盖了相同的故障模式，并且该路径已完全被取代。您早期的作品仍然是归因追踪的一部分。如果这是一个失误，请告诉我发生了什么变化，我可以立即重新审查。 “很好的工作，以清晰的背景来呈现这一点。我检查了重叠部分并确认最终修复位于 @canonical_author 的 #xxxxx 中。我们保留这一点是因为它涵盖了最完整的根本原因。如果这在你的重现中看起来不正常，请告诉我，我可以快速重新检查边界。 “谢谢你推动这个。这看起来是相关的，而不是重复的。它在“{reason}”处分歧，目前属于一个单独的轨道。如果您认为这个界限是错误的，请向我指出共同失败的步骤，我会立即重新评估它。 “我很欣赏这里的早期通行证。我将 #xxxxx 视为规范，因为它是该集群最安全、最完整的路径。如果我应该重新运行此拆分，请共享确切的重叠部分，我可以立即执行此操作。 ## 按情况划分的消息传递示例 ### 情况 1：干净重复、单学分结果 * 规范：`pr:xxxxx` 作者：`@canonical_author` * 重复：“issue:yyyyy”，作者：“@first_author”，“issue:zzzzz”，作者：“@second_author” * 要求的行为： * 仅指定一位权威作者（针对 95% 以上的案例）。 * 重复关闭使用单信用关闭模板。 * 相关注释包括具体的分歧原因。 ### 情况2：早期PR不可合并，直接后续延续，双学分 * 规范：`pr:xxxxx` * 早期基础工作：`pr:yyyyy`（不可合并，通过 diff 重叠和干净的后续检查证明直接延续） * 要求的行为： * 使用双学分模板。 * 理由陈述必须包括： * 第一个 PR 不可合并的原因， * 为什么第二个 PR 是直接延续， * 为什么测试/冲突风险保持干净。 ### 情况 3：相关但不重复 * 结果示例：“KEEP_OPEN_RELATED”。 * 消息必须使用具有明确描述向量散度的“{reason}”的相关模板。 ## 动作命令 > 除非明确使用完整的“owner/repo” URL，否则从 repo checkout 运行命令。 ### 为封闭重复项添加标签 * PR/问题重复：`gh issues edit --add-label dedupe:child --add-label close:duplicate` * 规范问题：`gh issues edit --add-label dedupe:parent` ### 以评论结束（问题） * 先评论，后关闭： * `gh 问题评论 --body "..."` * `gh 问题关闭 --原因未计划` ### 关闭公关 * `gh pr close --comment "..."`（最好与规范的关闭消息一起使用）。 ### 合并助手 * `gh pr merge --merge --auto` * `gh pr merge --squash --auto` * `gh pr merge --rebase --auto` ### 护栏检查 * `gh pr view --json mergeable,mergeStateStatus,isDraft,statusCheckRollup` * `gh pr view --json 更改文件、添加、删除` * `gh 问题视图 --json 注释` ## 脚本/alias.sh 帮助程序从此技能目录运行帮助程序以执行批量驱动的重复数据删除操作： `./scripts/alias.sh run-cluster /path/to/cluster.txt` `./scripts/alias.sh --dry-run run-cluster /path/to/cluster.txt` 支持的簇格式： `<类型>:|<操作>|<目标>` 支持的操作： *`检查` * `关闭-公关-重复` * `关闭问题重复` *`努普` 示例： pr:xxxxx|检查| pr:yyyyy|关闭 pr 重复|xxxxx 问题：bbbbb|关闭问题重复|aaaaa 问题：ccccc|noop| 仅在示例中使用占位符 ID： `pr:xxxxx|检查|` 优先使用“scripts/cluster-example.txt”作为可重用集群运行的起始模板。 ## Git 清理选项 * 删除过时的分支： `gitbranch -D ` * 删除远程分支：`git push origin --delete ` ## 安全/反模式 * 不要仅根据元数据对重复项进行分类；检查正文和差异语义。 * 不要使用无效的 GH 问题关闭原因（例如“--reason重复”）。 * 采取重复操作时保留来源归属。 * 硬停护栏失效时切勿自动关闭。 * 在可合并性/流失/AI 审查障碍未解决时，请勿合并或关闭项目。

Openclaw Github 重复数据删除

包含技能