OpenClaw gitcrawl 技能实战：GitHub Issue/PR 本地归档检索、重复聚类与 gh 实时校验工作流

OpenClaw gitcrawl 技能实战GitHub Issue/PR 本地归档检索、重复聚类与 gh 实时校验工作流【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本文基于 OpenClaw 仓库中的 gitcrawl 技能定义讲解如何把gitcrawl这一本地 GitHub issue/PR 归档工具接入 Agent 的维护者分诊流程先用doctor检查数据新鲜度再用threads、neighbors、search、clusters四组命令做候选发现与重复聚类最后通过gh shim的缓存/实时双模式以及原生gh校验在“评论、打标签、关闭、合并”等写操作前拿到实时证据。读完本文你可以在 OpenClaw 这类大型开源仓库中以极低 API 开销完成 issue/PR 溯源、去重判断与安全合并决策。gitcrawl 技能在 OpenClaw 中的定位OpenClaw 把可复用的 Agent 工作流沉淀为“技能”skill每个技能是一个独立目录由SKILL.md描述用法可选附带 Agent 元数据。gitcrawl 技能目录结构如下SKILL.md技能主体定义gitcrawlCLI 的使用命令与决策规则agents/openai.yaml面向 Agent 的展示元数据。从 openai.yaml 可以看到该技能的定位与默认提示词interface: display_name: Gitcrawl short_description: Search local OpenClaw issue and PR history before live GitHub triage default_prompt: Use $gitcrawl to inspect OpenClaw issue and PR history, find related threads and duplicate candidates, then verify actionable decisions with live GitHub.这段元数据点出了技能的核心设计思想先查本地归档local issue and PR history再走实时 GitHublive GitHub triage。OpenClaw 的 issue/PR 数量庞大每一次分诊如果都直接打 GitHub API既有速率限制风险也会丢失“历史上已关闭、已去重、已落地修复”的上下文。gitcrawl作为本地归档层正是解决这两点候选发现走缓存动作决策走实时。安装与前置条件技能 SKILL.md 的 frontmatter 声明了运行前置metadata: openclaw: homepage: 见 openclaw 组织的 gitcrawl 仓库 requires: bins: - gitcrawl install: - kind: go module: github.com/openclaw/gitcrawl/cmd/gitcrawllatest bins: - gitcrawl要点运行前要求 PATH 中可找到gitcrawl二进制requires.bins安装方式是标准的 Go 模块安装go install github.com/openclaw/gitcrawl/cmd/gitcrawllatest安装后产出gitcrawl命令gitcrawl的源码不在本仓库内属于 openclaw 组织的独立 Go 项目。本文所有命令与参数均以本仓库技能文档中的调用约定为准。第一步用 doctor 检查归档新鲜度技能开篇就强调使用本地 issue/PR 归档前先检查其新鲜度freshnessgitcrawl doctor --json--json输出便于 Agent 程序化解析。这一步的意义在于本地归档是“历史快照”如果目标 issue/PR 是刚提交的、或本地数据明显滞后基于过期数据做去重/关闭决策会出错。后文的 openclaw-pr-maintainer 技能 也给出了明确回退规则——当gitcrawl缺失、数据过期、缺少目标线程、或没有 embeddings影响neighbors/search类命令时应回退到实时 GitHub 搜索工作流。候选发现四命令threads / neighbors / search / clustersSKILL.md 给出了完整的候选发现命令族全部针对openclaw/openclaw仓库gitcrawl threads openclaw/openclaw --numbers issue-or-pr-number --include-closed --json gitcrawl neighbors openclaw/openclaw --number issue-or-pr-number --limit 12 --json gitcrawl search issues query -R openclaw/openclaw --state open --json number,title,url gitcrawl clusters openclaw/openclaw --sort size --min-size 5 gitcrawl cluster-detail openclaw/openclaw --id cluster-id逐个拆解其用途与参数threads按编号溯源完整线程gitcrawl threads openclaw/openclaw --numbers issue-or-pr-number --include-closed --json给定一个 issue 或 PR 编号返回其关联线程--include-closed保证已关闭的历史线程也在结果中——这对判断“该问题是否早已修复并关闭”至关重要。--json输出结构化结果供 Agent 消费。neighbors向量邻近检索gitcrawl neighbors openclaw/openclaw --number issue-or-pr-number --limit 12 --jsonneighbors基于嵌入embeddings做语义邻近检索找出与目标编号“语义上相近”的 issue/PR是发现重复提交、相关讨论、已尝试修复的主要手段。--limit 12控制候选数量。需要注意该命令依赖本地 embeddings 数据若归档中未生成 embeddings此命令不可用回退条件见前文。search关键词/混合检索gitcrawl search issues query -R openclaw/openclaw --state open --json number,title,url在 issue 集合中执行查询-R指定仓库--state open只查开放状态--json number,title,url指定输出列方便直接生成候选清单。clusters / cluster-detail重复聚类视图gitcrawl clusters openclaw/openclaw --sort size --min-size 5 gitcrawl cluster-detail openclaw/openclaw --id cluster-idclusters列出重复簇--sort size按簇内成员数排序--min-size 5只保留规模不小于 5 的簇——这能快速定位“同一问题被反复提交”的重灾区。随后用cluster-detail --id cluster-id展开指定簇的成员明细。补充维护者技能的扩展只读路径仓库中的 openclaw-pr-maintainer/SKILL.md 在 “Start issue and PR triage with gitcrawl” 一节给出了另一组常用只读命令其中search与cluster-detail使用了更丰富的参数gitcrawl threads openclaw/openclaw --numbers issue-or-pr-number --include-closed --json gitcrawl neighbors openclaw/openclaw --number issue-or-pr-number --limit 12 --json gitcrawl search openclaw/openclaw --query scope or title keywords --mode hybrid --json gitcrawl cluster-detail openclaw/openclaw --id cluster-id --member-limit 20 --body-chars 280 --json对比可见两个细节search支持--mode hybrid混合检索模式即关键词与语义结合的查询cluster-detail支持--member-limit 20簇成员展示上限与--body-chars 280正文截断长度用于在输出给 Agent 前控制上下文体积。该技能同时还划定了一条成本红线不要主动运行gitcrawl sync --include-comments这类昂贵的更新命令除非用户明确要求更新本地库、或过期数据阻塞了当前决策。gh shim缓存优先动笔前切实时SKILL.md 为 PR 分诊定义了“gh shim”gitcrawl gh子命令的双层读取策略先走缓存只有在做出变更/合并决策之前才切换到实时livegitcrawl gh pr status number-or-url -R openclaw/openclaw --compact gitcrawl gh pr view number-or-url -R openclaw/openclaw --json number,title,state,url,isDraft,headRef,headSha gitcrawl gh --live pr status number-or-url -R openclaw/openclaw --compactgitcrawl gh pr status ... --compact从本地归档读取 PR 状态摘要输出紧凑格式gitcrawl gh pr view ... --json 字段列表按number,title,state,url,isDraft,headRef,headSha等字段做结构化读取isDraft、headRef、headSha对判断“是否草稿、基于哪个分支、指向哪个提交”非常关键gitcrawl gh --live ...--live标志强制绕过缓存直连 GitHub用于最终决策点。这一设计的逻辑是分诊早期阶段浏览、归类、找候选允许使用缓存数据因为速度优先一旦进入“即将对外动作”阶段状态必须来自实时源否则可能基于过期的 CI 状态或已变更的 PR head 做错误判断。写操作前的实时校验与证据门槛技能文档明确规定在评论、打标签、关闭、重开、合并或提交 PR review 之前必须使用实时gh加当前 checkout 的证据checkout proofgh pr view number --json number,title,state,mergedAt,body,files,comments,reviews,statusCheckRollup gh issue view number --json number,title,state,body,comments,closedAt两条命令分别覆盖 PR 与 issue 的关键实时字段PR 侧的mergedAt、files、reviews、statusCheckRollupCI 检查汇总是合并决策的直接依据issue 侧的closedAt、comments是判断“是否已被解决/已有后续讨论”的依据。这一点在仓库的其他技能中得到了交叉印证。tag-duplicate-prs-issues/SKILL.md 明确划分了三种工具的职责边界工具职责gitcrawl候选生成与历史上下文所有候选在实时 GitHub 确认前都只是“线索”gh/gh api实时 GitHub 事实目标状态、正文、评论、review、文件、open/closed/merged 状态prtags维护者策展层保存去重分组与判断结论它同时规定了回退到实时搜索的具体触发条件目标/候选尚未出现在本地库中、本地数据对当前决策明显过期或不完整、gitcrawl报错/超时/缺少 neighbors/search 所需数据——并要求在回退时记录回退事实与原因。这与 gitcrawl 技能自身的报告规范一致。输出规范报告什么、不做什么SKILL.md 末尾给出两条硬性输出纪律报告内容要具体绝对日期而非“最近”“几天前”、仓库名、issue/PR 编号、cluster id、数据缺口source gaps——即当本地归档缺少某部分数据时必须明示禁止仅凭相似度做破坏性动作“Do not close/label from similarity alone”——关闭或打标签必须同时满足两个条件意图匹配matching intent 实时验证live verification。后者与 tag-duplicate-prs-issues/SKILL.md 的工作规则完全呼应不能因为标题相似就判重不能因为改了相同文件就判重重复簇必须建立在“同一用户可见问题、同一意图、实质重叠的实现或调查上下文”之上。gitcrawl的 neighbors 命中、search 命中、簇成员关系都只算“候选生成”本身不构成足够证据。在 OpenClaw 维护者工作流中的协作位置从仓库内多处交叉引用看gitcrawl 技能是 OpenClaw 维护者分诊体系的“第一站”openclaw-pr-maintainer/SKILL.md 要求“任何检查 OpenClaw issue/PR 的场景都先用$gitcrawl”查本地数据中的相关线程、重复尝试和已落地修复同时提醒指派人assignment状态gitcrawl查不了必须用实时gh issue view/gh pr viewopenclaw-repair-sweep/SKILL.md 在无人值守修复扫荡中用$gitcrawl做队列发现、去重与历史 PR 检索把实时 GitHub 变更操作交给$openclaw-pr-maintainer该技能与discrawl、slacrawl、graincrawl、notcrawl等同名族技能并列于.agents/skills/目录命名遵循“平台 crawl”约定即“为各协作平台建本地可检索归档”的同构设计gitcrawl 对应 GitHub 侧。实践小结推荐的只读分诊顺序综合 gitcrawl 技能本体与维护者技能的约束一次标准的 issue/PR 分诊可以按以下顺序执行gitcrawl doctor --json——确认本地归档可用且新鲜若不可用回退实时搜索并记录原因gitcrawl threads ... --include-closed --json——拿到目标线程及其已关闭历史gitcrawl neighbors ... --limit 12 --json或gitcrawl search ... --mode hybrid --json——生成重复/相关候选gitcrawl clusters ... --sort size --min-size 5cluster-detail --id cluster-id——确认候选所在的重复簇gitcrawl gh pr status/view缓存——快速读取 PR 结构信息决策前切换实时源gitcrawl gh --live ...或原生gh pr view / gh issue view含statusCheckRollup等完整字段输出报告时给出绝对日期、编号、cluster id 与数据缺口关闭/打标签仅在“意图匹配 实时验证”双条件满足时执行且避免主动触发gitcrawl sync等高成本更新命令。这套“本地归档发现候选 → 实时源验证决策 → 严格报告缺口”的三层结构使得 Agent 在大规模 issue/PR 洪流中既能控制 API 开销又不会把语义相似误当作事实相同——这正是 gitcrawl 技能在 OpenClaw 维护流程中的核心价值。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考