企业官网建设流程全解析

用 Claude Code 自定义命令自动化 GitHub Issue 去重：claude-task-master 的 dedupe 命令实战解析

【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master

导读

本文以 claude-task-master 仓库中dedupe.md为对象，完整解析如何在 Claude Code 中定义一个专门用于“查找并标记 GitHub 重复 Issue”的 slash command（斜杠命令）。文章会带你理解该命令的 frontmatter 声明方式、受限工具白名单、五步执行流水线、多 Agent 并行搜索策略，以及标准的去重评论模板——读完后你可以直接将其复制进自己的项目，用 Claude Code +ghCLI 搭建一套可复用的 Issue 去重自动化工作流。

一、什么是 Claude Code 自定义命令（slash command）

Claude Code 允许开发者通过一个 Markdown 文件来定义自己的斜杠命令：命令以!开头（!名称）或在对话中直接触发，其内部可以是给 Claude（Agent）的自然语言指令、可执行步骤与约束。claude-task-master 仓库中的.claude/commands/目录正是这种机制的落地实践：

• .claude/commands/dedupe.md—— GitHub Issue 去重命令（本文主角）；
• .claude/commands/go/ham.md—— “Hamster” 任务执行工作流命令；
• .claude/commands/go/pr-comments.md—— PR 评审意见收集与修复命令；
• .claude/TM_COMMANDS_GUIDE.md—— 完整的 Task Master 命令指南。

这些命令文件共享同一套语法：文件头部是 YAML frontmatter（用---包裹），声明allowed-tools（允许使用的工具白名单）与description（命令描述）；文件正文则是给 Agent 的详细指令。claude-task-master 作为一个面向 Cursor、Lovable、Windsurf、Roo 等环境的 AI 任务管理系统，其命令体系同时服务任务编排与仓库运维两类场景，dedupe就属于后者。

二、命令声明：frontmatter 与工具白名单

dedupe.md的开头用 frontmatter 严格限定命令的能力边界：

--- allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh api:*), Bash(gh issue comment:*) description: Find duplicate GitHub issues ---

这里有两个关键设计：

1. description字段：Find duplicate GitHub issues。Claude Code 会在命令列表中展示该描述，帮助使用者判断命令用途。

2. allowed-tools字段：这是一个最小权限白名单。命令只能通过Bash工具执行五类gh子命令：

   • gh issue view:*—— 查看某个 Issue 详情；
   • gh search:*—— 在 GitHub 上搜索 Issues/PR/代码；
   • gh issue list:*—— 列出某个仓库的 Issues；
   • gh api:*—— 调用 GitHub REST API；
   • gh issue comment:*—— 给 Issue 发表评论。

   这意味着命令体内不允许使用文件编辑、其他 MCP 服务器、web fetch等工具。这种白名单式约束让去重任务在受限、可审计的沙箱内运行，避免 Agent 越权改动仓库文件或引入不可控的外部数据源。

与仓库内其他命令对比：go/ham.md与go/pr-comments.md主要依赖tm（Task Master CLI）与gh pr view进行任务推进与 PR 评审，而dedupe将工具面收窄到gh的 issue 相关子命令，可见本命令的定位是“纯 GitHub 仓库运维”，与任务管理主流程解耦。

三、执行前置检查：避免无效去重

命令正文第一段要求 Agent 在执行前先评估是否有必要去重，这是整个流程的质量闸门。必须通过检查确认目标 Issue 不属于以下三种情况，否则直接中止：

• (a) 该 Issue 已关闭——关闭的 Issue 不需要再去重；
• (b) 不需要去重——典型场景包括：
  • 宽泛的产品反馈（没有具体解决方案）；
  • 正面反馈（如赞美、感谢类内容）；
• (c) 已经由你（此命令）评论过重复线索——避免对同一 Issue 重复评论造成骚扰。

对应到ghCLI 的实现，前置检查通常通过gh issue view <number>（读取 Issue 状态state、已有评论）与gh issue list组合完成。这一步的价值在于：去重不是无脑匹配，而是先判断“该不该去重”，从源头过滤掉低质量操作。

四、五步执行流水线：从摘要到多路并行搜索再到过滤评论

通过前置检查后，命令要求按以下五步精确执行：

Step 1：生成 Issue 摘要

先用 Agent 查看目标 GitHub Issue（gh issue view），并要求 Agent 返回该 Issue 的摘要（summary）。摘要将作为后续搜索的关键词来源，因此要求 Agent 提炼出问题的核心诉求、复现路径与期望行为，而不是简单复制全文。

Step 2：并行搜索潜在重复

基于 Step 1 的摘要，并行启动 5 个 Agent去 GitHub 上搜索重复 Issue。命令原文强调两点：

• 使用多样化的关键词与搜索策略（diverse keywords and search approaches）——不同 Agent 可以分别围绕症状描述、错误信息、功能名、期望行为等维度构造检索词；
• 工具面仅限gh search:*与gh issue list:*，对应gh search issues --repo <owner/repo> "<query>"与gh issue list --search "<query>"等命令。

并行 + 多样化的组合是为了覆盖单一关键词容易遗漏的表述变体（同义词、缩写、中英文措辞差异等），提高召回率。

Step 3：过滤误报

把 Step 1 的摘要与 Step 2 的搜索结果一起喂给另一个 Agent，由它过滤掉误报（false positives）——即那些“看起来相关、实际并非重复”的 Issue。如果过滤后没有任何重复候选，直接中止，不进入评论阶段。

这一步是精度兜底：并行搜索追求召回，过滤 Agent 追求精确，两者配合形成“宽进严出”的漏斗。

Step 4：回帖评论

最终在有候选的情况下，用gh issue comment在目标 Issue 下发布评论，列出最多 3 个疑似重复的 Issue 链接（若没有候选则 0 个）。

完整流水线示意

前置检查(关闭/无需去重/已评论过) ↓ 通过 Issue 摘要（gh issue view） ↓ 5 路并行搜索（gh search / gh issue list，多样化关键词） ↓ 过滤误报（对照摘要剔除 false positives） ↓ 若有剩余 → gh issue comment 回帖（最多 3 条链接）

这套流程在架构上体现了一个典型的Agent 编排模式：摘要 Agent（信息压缩）→ 并行搜索 Agent（召回）→ 过滤 Agent（精排）→ 输出 Agent（回帖），每个环节职责单一、可独立验证。在 claude-task-master 的多 Agent 体系中（如.claude/commands/go/pr-comments.md也采用“收集→汇总→确认→执行→验证”的分段编排），这种“先并行扩大候选、再集中收敛”的策略是处理开放搜索类任务的通用范式。

五、执行约束与硬性规则

命令正文的 Notes 部分为 Agent 及所有子 Agent 设定了不可逾越的约束：

1. 只准用gh，不用 web fetch：与 GitHub 的交互必须通过ghCLI，而不是网页抓取——保证结果结构化、可审计、速率可控；
2. 禁用其他工具：不得使用其他 MCP 服务器、文件编辑等任何超出allowed-tools的工具；
3. 先建待办清单（todo list）：正式执行前先列出 TODO，让执行过程可追踪、可中断；
4. 评论格式必须精确遵循模板（见下节），不得自由发挥。

这些约束与 frontmatter 的allowed-tools形成双重保险：声明层限制“能用什么”，指令层约束“怎么用、用什么流程”，共同把 Agent 的行为收敛到可预期、低风险的轨道上。

六、标准去重评论模板

当找到疑似重复后，命令要求精确按以下格式回帖（示例假设找到 3 个）：

--- Found 3 possible duplicate issues: 1. <link to issue> 2. <link to issue> 3. <link to issue> This issue will be automatically closed as a duplicate in 3 days. - If your issue is a duplicate, please close it and 👍 the existing issue instead - To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with \[Task Master Bot\] ---

该模板的设计意图值得逐条拆解：

• 明确结论与数量：开头点明“Found 3 possible duplicate issues”，让读者一眼知道结论；
• 链接列表：给出候选 Issue 的完整链接，便于跳转核对；
• 自动化关闭倒计时：“will be automatically closed as a duplicate in 3 days” 声明 3 天自动关闭机制，给原作者留出反应时间；
• 双轨处置指引：若确认重复 → 自行关闭并在既有 Issue 上 👍；若想阻止自动关闭 → 回帖或 👎 该评论。这种“默认关闭 + 人工可逆”的机制兼顾了维护效率与社区公平；
• 机器人署名：🤖 Generated with \[Task Master Bot\]标明评论由机器人生成，符合 GitHub 社区对自动化行为的透明性预期。

注意：模板中的\[Task Master Bot\]使用了反斜杠转义方括号，这是 Markdown 中避免链接语法被错误解析的写法，命令要求原样输出，Agent 不应“好心”去掉反斜杠。

七、运行前提与适用场景

要将此命令投入实际使用，需要满足以下前提：

1. 环境：本地已安装 GitHub CLIgh（命令以gh为唯一工具面，无gh则无法运行），并已完成gh auth login认证（仓库的.claude/commands/go/ham.md也提到 JWT/令牌失效时可参考tm auth refresh等刷新机制保持会话有效）；
2. 宿主：Claude Code 中运行，命令文件位于.claude/commands/dedupe.md，仓库内的.claude/commands/目录即标准放置位置；
3. 权限：目标仓库需允许机器人账号gh issue comment（写权限）。

适用场景包括：维护者处理高频重复 Bug 反馈、机器人运营开源仓库时自动归并同类 Issue、大型项目 Issue 积压后的批量清洗。它不适合用于：需要跨仓库深度语义比对的长文本 Issue、需要阅读附件/复现视频的场景（受gh工具面限制）。

八、小结：一条命令背后的自动化设计哲学

dedupe.md全文不过 38 行，却浓缩了一套完整的“受限 Agent 自动化”设计范式：

对 claude-task-master 的使用者而言，dedupe既是一个可直接使用的命令，也是一个“如何为 Claude Code 编写安全、可控、可复用的运维类 slash command”的参考范本。如果你想继续研究仓库内其他命令的写法，可以对照阅读.claude/TM_COMMANDS_GUIDE.md（Task Master 完整命令参考）、.claude/commands/go/ham.md（任务执行工作流）与.claude/commands/go/pr-comments.md（PR 评审自动化），从而搭建属于你自己的 Agent 命令集。

【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master