Issue / PR 分诊与排队

把仓库里的 issue 与 PR 变成一组可执行的结论：每条要么有优先级与批次、要么有明确的关闭理由。判断必须带证据，写回必须可复核。

边界：本 skill 只动 issue / PR / Projects 看板与 docs/plans/ 下的分诊文档，不碰 src/、tests/、DSH 源码，也不改 issue 正文。仓库硬约束见 AGENTS.md §1（代码改动走 PR、禁止写 DSH 源码）。

一次性准备

• 看板读写需要 project scope：gh auth refresh -s project（只能人点浏览器，不要自己起流程干等）。
• 看板身份、标签口径、批次定义、默认规则：references/taxonomy.md。
• GitHub API / gh CLI 的坑（视图分组不可写、字段选项替换会清值、非 ASCII 键乱码等）：references/gh-gotchas.md。动手前先读一遍，能省掉一整轮返工。

阶段 1 · 取快照

node .agents/skills/issue-triage/scripts/snapshot.mjs --out /tmp/triage

产出 snapshot.json（结构化）与 digest.md（人读：标题 + 标签 + 年龄 + 评论摘要 + 代码/提交里的修复引用）。先读 digest 再做判断，不要靠标题猜。

snapshot.mjs 会额外扫描 main / 任意 merge-train 分支的提交与 CHANGELOG、docs、src、tests 里对本 issue 号的引用，这是「已经修好了吗」最便宜的证据来源。

阶段 2 · 分类（每条都要落三个坐标）

1. 类型：bug / enhancement / question / documentation / refactor / chore。
2. 领域：area/sidebar（承载面/布局/面板/交互）· area/explorer · area/editor · area/tabs · area/git · area/terminal · area/security · area/build · area/i18n；跨领域或纯流程类不挂，不要硬塞。
3. 优先级：P0 崩溃/阻塞或核心能力缺失（基本需求） · P1 影响日常使用/数据丢失/门禁红 · P2 功能性缺陷（有 workaround）或广泛需要的功能 · P3 体验与建议、窄场景，以及已修好/已不再适用的条目。

铁律：

• 已有优先级标签默认保留（维护者此前打过的是判断，不是噪声）。只有「主题已从产品中消失」才下调，且要在文档里记一笔。
• 只降不升：真觉得该升级，先说给人听，别默默改。
• 一条 issue 只能有一个 P 标签：gh issue edit --add-label 不会移除旧标签，批量改完必须回读自查（见阶段 4）。
• 对 PR 不判类型/领域，只判优先级：从它引用的仍开着的 issue 继承（取最高档）；引用不到就留空，不要编。

阶段 3 · 判动作（决定「要不要关、要不要追」）

按证据把每条归到一组，证据不足就留在待办：