GitLens 仓库的 `/update-issues` 技能指南：从 triage 报告到 GitHub 状态变更的安全执行流水线

开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载导读本文深入解析 vscode-gitlens 仓库中维护者使用的/update-issues技能Claude Skill定义于 .claude/skills/update-issues/SKILL.md。它是 issue 工作流中唯一会修改 GitHub 状态的环节读取 triage、investigation、prioritization 三类报告 JSON将推荐动作翻译为标签、评论、里程碑与关闭操作并借助强制 dry-run、pre-flight 状态检查、逐条确认与审计日志六重安全机制落地执行。读完本文你将掌握该技能的使用方式、三类报告的判定规则、动作翻译表、底层gh命令与源码佐证以及它如何与/triage、/investigate、/prioritize串联成完整流水线。一、技能定位issue 工作流的“写操作”出口vscode-gitlens 的 issue 治理体系由一组 Claude Skills 构成完整用法可参考 docs/triage-dev-skills.md。其中分析类技能/triage、/investigate、/prioritize全部是只读的——它们只产生 Markdown 报告和 JSON 决策文件不触碰 GitHub而/update-issues是唯一被允许修改 GitHub 状态的技能加标签、发评论、设里程碑、关闭 issue。从 scripts/issues/workflow.mts 的流水线编排可以看到triage 流水线在完成triage → investigate → prioritize后会打印/update-issues --from-report命令并等待人工执行脚本本身从不自动应用变更——这正是该技能“human-in-the-loop”设计哲学的体现。使用方式/update-issues --from-report [path] [--dry-run]参数含义--from-report指向报告 JSON 文件的路径自动检测报告类型省略路径时自动使用.work/triage/reports/下最新的报告 JSON--dry-run只展示将要执行的动作而不做任何修改。首次调用默认即 dry-run必须确认后才真正落地从 docs/triage-dev-skills.md 的 Composability Reference 可知/update-issues支持三种输入形态--from-report用最新报告、--from-report 具体路径指定YYYY-MM-DD-RESOLUTIONS.json等文件、--dry-run仅演练。它消费三类 JSON 报告中的任意一种输出依次为dry-run 表格 → 用户确认 → 执行 →.work/triage/reports/YYYY-MM-DD-ACTIONS.md审计日志。二、Stage 0 — 加载报告并判定类型第一步是读取 JSON 文件并按内容结构而非文件名判定报告类型。由于*-DECISIONS.json同时匹配 triage 与 investigation 文件“取最新文件”时只看文件名会选错类型因此必须检查数组字段报告类型判定字段典型文件名Triage 决策含verdicts数组YYYY-MM-DD-DECISIONS[-batch-N].jsonInvestigation 决策含investigations数组YYYY-MM-DD-INVESTIGATION-DECISIONS.jsonResolution 决策含resolutions数组YYYY-MM-DD-RESOLUTIONS.json这些 JSON 的结构由 scripts/issues/types.mts 定义。其中TriageVerdict接口给出了 verdict 的完整字段issueNumber、verdict、confidenceHigh/Medium/Low、evidenceChecklistStatus、recommendedLabels、recommendedActions、requiresHumanApproval、evidenceSummary、canonicalDuplicateNumber等——requiresHumanApproval字段正是技能要求“关闭类动作逐条人工确认”的数据来源。VerdictClass联合类型则枚举了全部 11 种 verdict与下文动作翻译表一一对应。三、Stage 1 — 将推荐动作翻译为 GitHub 操作技能按报告类型维护三张“动作翻译表”这是整个执行逻辑的核心。3.1 Triage 决策 → 动作VerdictActionsClose - Fixed关闭 issuereason: completed加标签triaged移除标签triageClose - Duplicate关闭 issuereason: not planned评论链接到 canonical issue加标签duplicateClose - Not a Bug关闭 issuereason: not planned加标签not-bug评论说明为何不是缺陷Close - Already Exists关闭 issuereason: not planned加标签already-exists评论说明已存在的功能Close - Invalid关闭 issuereason: not planned加解释性评论Close - Stale关闭 issuereason: not planned评论说明过期原因Request More Info加标签needs-more-info评论请求具体信息Retype - Bug将 issue 类型改为 bugRetype - Feature Request将 issue 类型改为 enhancementValid - Needs Triage无动作需先调查Valid - Already Triaged无动作3.2 Investigation 决策 → 动作结果ActionsConfirmed Bug加标签triaged移除标签triageConfirmed Bug (blocked)加标签triaged、移除triage再依据blockedBy字段加阻塞标签blocked、blocked: vscode、blocked: git、blocked: cli或blocked: language-serverLikely Fixed加标签needs-more-info评论请报告者在最新版本上验证Cannot Reproduce加标签needs-more-info评论请求更新复现步骤Inconclusive / Insufficient无动作需人工复核注意阻塞标签的可选值blocked: vscode、blocked: git、blocked: cli、blocked: language-server对应 GitLens 依赖的不同外部组件blockedBy字段决定了精确选择哪个标签。3.3 Resolution 决策 → 动作推荐Actionsshortlist设里程碑为 Shortlist加标签triaged移除标签triagebacklog设里程碑为 Backlog加标签triaged移除标签triagewont-fix关闭 issuereason: not planned加标签wontfix评论说明理由community-contribution加标签needs-help若是 bug或needs-champion若是 enhancement评论邀请社区贡献四、Stage 2 — Pre-flight 状态检查动手前先核实现状关键规则在应用任何动作之前必须验证 issue 的当前状态使用 GitHub CLI 查询gh issue view number --repo gitkraken/vscode-gitlens --json state,labels,milestone对每个 issue 逐一核对已关闭→ 跳过关闭动作并警告用户标签已存在→ 跳过冗余的加标签操作里程碑已设置→ 若相同则跳过不同则警告报告年龄→ 若报告生成已超过 24 小时警告 issue 状态可能已发生变化这一设计意图可以从数据缓存机制得到印证scripts/issues/config.mts 中配置了teamCacheTtlMs: 4h、changelogCacheTtlMs: 1h、labelsCacheTtlMs: 24h、issueCommentLimit: 3、duplicateCandidateLimit: 5、staleInactivityDays: 365等参数——报告中的数据本就带有缓存时效因此在执行前重新核对实时状态是必要的护栏。另外GitHub 端还存在“needs-more-info标签 超时自动关闭”的既有自动化技能依赖它处理无响应的待验证 issue详见 docs/triage-dev-skills.md 中的 Staleness detection 一节。五、Stage 3 — 展示 Dry Run 并请求确认在真正执行前技能必须先呈现一张汇总表。技能文档给出了标准模板## Actions to Apply | Issue | Action | Details | Status | | ----- | ------------- | ----------------------------------- | ---------------------------- | | #1234 | Close | Reason: not planned, Comment: ... | Ready | | #1234 | Add label | duplicate | Ready | | #2345 | Add label | needs-more-info | Ready | | #2345 | Comment | Could you provide... | Ready | | #3456 | Set milestone | Backlog | Ready | | #4567 | Close | Reason: completed | ⚠️ Already closed — skipping | ### Summary - Actions ready: N - Skipped (already applied): N - Warnings: N在继续之前必须询问确认。用户有三种选择应用全部 ready 动作选择性应用指定 issue 编号取消需要特别说明关闭 issue 的确认是逐条的——即每个要关闭的 issue 都必须获得用户明确同意而非笼统批准后批量关闭。六、Stage 4 — 执行动作底层gh命令详解批准后技能通过ghCLI 执行动作。技能文档给出了六条核心命令这里逐条展开参数说明# 加标签 gh issue edit number --repo gitkraken/vscode-gitlens --add-label label # 移除标签 gh issue edit number --repo gitkraken/vscode-gitlens --remove-label label # 设置里程碑 gh issue edit number --repo gitkraken/vscode-gitlens --milestone milestone # 发布评论 gh issue comment number --repo gitkraken/vscode-gitlens --body message # 带理由和评论关闭not planned 类 gh issue close number --repo gitkraken/vscode-gitlens --reason not planned --comment message # 以 completed 理由关闭Close - Fixed gh issue close number --repo gitkraken/vscode-gitlens --reason completed --comment message注意两点执行细节目标仓库固定为gitkraken/vscode-gitlens与 scripts/issues/config.mts 中owner: gitkraken, repo: vscode-gitlens的配置一致issue 链接也统一构造为https://github.com/owner/repo/issues/number格式参见 .claude/skills/triage/SKILL.md 的输出规范。每个 issue 的执行顺序先标签再里程碑再评论最后关闭。这样能确保关闭前 issue 已携带正确的元数据。错误处理若某条gh命令失败记录错误并继续处理剩余动作最后统一汇总所有失败项——不因单个失败中断整个批次。七、Stage 5 — 审计日志每个动作都有据可查执行完毕后将审计日志写入.work/triage/reports/YYYY-MM-DD-ACTIONS.md。技能文档给出了模板# Actions Applied — YYYY-MM-DD Source report: path to source JSON Report type: triage | investigation | resolution Applied at: ISO timestamp Applied by: git user ## Actions Taken | Issue | Action | Result | | ----- | ----------------------------- | --------------------------------------- | | #1234 | Closed (not planned) | ✓ Success | | #1234 | Added label duplicate | ✓ Success | | #2345 | Added label needs-more-info | ✓ Success | | #2345 | Posted comment | ✓ Success | | #3456 | Set milestone: Backlog | ✗ Failed: milestone Backlog not found | ## Summary - Successful: N - Failed: N - Skipped: N这使每一次 GitHub 变更都具备完整的可追溯性。.work/目录是 gitignore 的所有产物集中在主工作树的.work/triage/reports/下详见 docs/triage-dev-skills.md 的 Output Files 一节流水线各阶段产物文件名模式对应关系为*-TRIAGE-REPORT.md/*-DECISIONS.json/triage产出、*-INVESTIGATION-REPORT.md/*-INVESTIGATION-DECISIONS.json/investigate产出、*-RESOLUTION-REPORT.md/*-RESOLUTIONS.json/prioritize产出、*-ACTIONS.md/update-issues产出。八、六条安全规则为什么这个技能“不危险”/update-issues是唯一写 GitHub 的技能因此它的安全模型是整个 issue 工作流中最严格的先 dry-run— 总是先展示动作计划并获得确认再执行Pre-flight 检查— 动手前总是核实 issue 当前状态逐条关闭确认— 关闭每个 issue 都需要用户明确批准禁止创建标签— 只使用已有标签若推荐标签不存在警告并跳过不擅自新建禁止强制操作— 绝不使用--force或绕过安全检查全量审计— 每个执行的动作都必须记录日志这与 docs/triage-dev-skills.md Safety Model 中的描述完全对应分析只读、更新需确认、pre-flight 检查、逐条关闭确认、审计追踪、human-in-the-loop所有关闭推荐均带requiresHumanApproval: true。同时从 scripts/issues/workflow.mts 可以看到pnpm workflow脚本即使编排了完整 triage 流水线也只会打印/update-issues --from-report供人工执行绝不会自动调用它——从编排层进一步保证了“写操作必须由人触发”。九、Chaining与上下游技能的串联方式/update-issues消费 issue 工作流中其他技能的输出形成可组合的流水线/triage recent → /update-issues (应用 triage verdicts) /triage recent → /investigate --from-report → /update-issues (应用 investigation 结果) /triage recent → /investigate --from-report → /prioritize --from-report → /update-issues (完整流水线)实战中对应的典型场景均出自 docs/triage-dev-skills.md每周收件箱清理/triage recent评估最近 7 天新 issue产出 spam/重复/缺信息/错分类/超范围等判定随后/update-issues --from-report以 dry-run 形式展示所有推荐动作批准后执行。积压清理/triage audit --older-than 365d --batch-size 50分批审计历史积压/update-issues关闭过期 issue、为待验证 issue 请求信息、为已确认 bug 打triaged标签。规划信号落地/prioritize --from-report给出 Shortlist/Backlog/里程碑推荐后/update-issues据此设置里程碑。与 dev 流水线/dev-scope→/deep-planning→/challenge-plan→ 实现 →/deep-review→/commit相比triage 流水线的产物全部汇聚到/update-issues这一个出口形成“分析只读、落地可控”的闭环。十、源码层面的运行前提与限制报告生成依赖 CLI 脚本triage 报告由 scripts/issues/triage.mts 生成recent/audit/single三种模式脚本输出 evidence pack JSON 的绝对路径技能读取该 JSON 进行分析。scripts/issues/workflow.mts 中的编排脚本使用node --experimental-strip-types运行.mts脚本并支持--agent claude|auggie、--model、--dry-run、--rubber-duck等全局选项。报告有缓存时效triage.mts中findFreshPack对 reactive/audit 模式的包做 1 小时新鲜度校验比对meta.workflow与queryParams.batchNumber超过时限或--force-refresh时重建证据包——这解释了为何/update-issues要求执行前重新核对实时 issue 状态。批次与速率限制triage 报告的single模式单次 GraphQL 查询最多 10 个 issuesingleIssueBatchLimitaudit默认批次 50auditBatchSizeGitHub Search API 约 30 次/分钟的限制也会约束大批次操作的耗时。24 小时警告报告生成超过 24 小时后issue 状态可能已变化技能会发出警告——本质上是将“缓存数据可能过期”的风险显式化。综上/update-issues是一套“读取报告 → 翻译动作 → 核对现状 → 演示确认 → 有序执行 → 全量审计”的完整写操作闭环配合六条安全规则与上下游技能构成了 GitLens 仓库从 issue 接收、调查、优先级排序到落地变更的自动化治理体系。对于需要维护大型开源仓库 issue 队列的团队这套模式只读分析 人工确认写操作 审计日志可以作为可复制的工程参考。相关文件速览技能定义.claude/skills/update-issues/SKILL.md技能总览与用法docs/triage-dev-skills.md证据包与 verdict 类型定义scripts/issues/types.mts缓存与批次配置scripts/issues/config.mts报告生成脚本scripts/issues/triage.mts流水线编排脚本scripts/issues/workflow.mts赞分享开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载相关推荐从 Git 变更到 GitHub Issue解析 GitLens 仓库的 create-issue 技能工作流从 Git 变更到 GitHub Issue解析 GitLens 仓库的 create issue 技能工作流 GitLens 仓库在其 AI 协作技能体系开发工具版本控制Astro 仓库的 Agent 分诊流水线Triage Skill 如何端到端处理 Bug 报告Astro 仓库的 Agent 分诊流水线Triage Skill 如何端到端处理 Bug 报告 Astro 官方仓库在 .agents/skills/tri前端Web框架SSR前端构建GitLens 仓库 Issue 工作流 Skills 完全指南从 Triaging 到交付的 Agent 流水线实战GitLens 仓库 Issue 工作流 Skills 完全指南从 Triaging 到交付的 Agent 流水线实战 导读 本文基于 docs/triage开发工具版本控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考