triage-issue

GitHub Issue 分诊

概述

分诊 = 分配 type/ + priority/ 标签，在有值得记录的判断时留下关键评论，然后移除 status/needs-triage。通过 gh label list 检查仓库的标签规范——下文使用的 type/* / priority/* / status/* 约定是常见默认值，但应根据仓库实际拥有的标签进行调整。

范围：每次调用处理一个 Issue。对于积压任务的逐项处理，由调用方通过 gh issue list --label status/needs-triage 列出 Issue，并针对每个结果调用此技能。

核心原则：评论是传递信号，不是走形式。如果 Issue 正文已经涵盖了你要说的内容，就跳过。只补充读者无法仅从正文或标签中获取的信息。

适用场景

• 用户说“triage #N” / “triage this issue”
• Issue 缺少 type/ 或 priority/ 标签
• Issue 带有 status/needs-triage

对于积压任务（triage backlog / 一次处理多个 Issue），由调用方负责协调：列出 Issue，并针对每个 Issue 调用此技能。

流程

1. 阅读 Issue：gh issue view <n>
2. 先阅读正文再作决定（仅看标题会遗漏范围）
3. 决定标签：type/ + priority/
4. 决定是否评论：参见下方“评论标准”
5. 应用：

   gh issue edit <n> \
     --add-label type/X --add-label priority/Y \
     --remove-label status/needs-triage
   gh issue comment <n> --body-file -  # stdin, multi-line safe
   

优先级标准

级别	触发条件
critical	绕过身份验证 · 数据丢失 · 生产环境中断 · 正在发生的利用。立即处理。
high	存在现实攻击路径的安全问题 · 核心流程损坏 · 阻碍其他工作
medium	应当修复 · 用户体验下降 · 有明确收益的重构 · 没有用户可见的故障
low	润色 · 清理 · 可有可无 · 低风险的后续改进

判断依据：影响对象、损害是否可逆、影响范围。如果在两个级别之间拿不准，选择较低级别。

评论标准

以下任一情况都必须评论：

• priority/critical 或 priority/high——记录判断，以便日后说明依据
• Issue 与其他 Issue 重叠（see also #N / dup of #N / subset of #N / blocks #N）
• 工作量估算不明显（XS / S / M / L，或小时/天）
• 存在阻塞项（blocked by #N 或 requires upstream X）

以下情况跳过评论：

• 标题和正文已说明优先级依据，且没有需要补充的交叉引用 / 范围 / 阻塞项
• 评论只会复述正文内容

不要重复正文内容。如果作者已经解释了为什么这是 critical，分诊评论应补充的是_元信息_：关联关系、范围、日期和判断依据。

分诊时不要阅读代码。如果发现需要根据实际代码核实说法、确认根因或探查影响范围——这属于调查。切换到 investigate-issue 技能，妥善处理该 Issue。半吊子的调查会让评论比轻量分诊更糟。

评论模板

与仓库的 PR 模板风格一致——用带表情符号的分节标题，便于快速浏览。没有内容可补充的部分应省略（不要写“ N/A ”标题，直接跳过即可）。

## 🏷️ Triage YYYY-MM-DD

`type/X` · `priority/Y` · effort: **S/M/L**

### 📊 At a Glance

<diagram (mermaid or ascii) + 1-line caption — only include when there's something visual worth showing>

Use a diagram when:

- Cluster fix order: `#29 → #30 → #25` (ascii arrows OK)
- Attack flow / race condition: mermaid `sequenceDiagram`
- Before/after refactor: mermaid `flowchart` or ascii box

Skip the section entirely (don't write empty header) when labels + Related list already convey the picture — most simple triages won't need it.

### 🔗 Related

- <only if relevant: dup of / blocks / blocked by / see also #N>

### 🚧 Notes

<only if priority justification missing from body, or scope is non-obvious>

语言：与 Issue 正文保持一致。标签值、命令名称和分节标题（At a Glance、Related、Notes）保持原样。

工作量估算：XS = <1h · S = 半天 · M = 1–3d · L = >3d。根据影响范围估算，而不是根据代码行数。

分节要求：

• 🏷️ Triage 行 + 📊 At a Glance——始终包含（这是承载关键信息的摘要）
• 🔗 Related——存在实际交叉关联时包含，否则省略标题
• 🚧 Notes——仅当正文未说明优先级依据或工作范围不明显时包含，否则省略标题

不要复述正文已有的内容。分诊评论是对_判断_的元信息，而不是对_问题_的重新概述。

快速参考

命令	用途
gh issue view <n> --json title,body,labels	阅读 issue
gh issue edit <n> --add-label X --remove-label Y	应用标签
gh issue comment <n> --body-file -	通过标准输入发表评论
gh issue list --label status/needs-triage --json number,title,body,labels --limit 50	列出待处理事项（调用方枚举事项后，再针对每个事项调用此技能）

常见错误

• 在评论中重复正文——会增加噪音。正文已经存在；评论只用于补充元信息。
• 对每个事项都发表评论——对于明确的中等/低优先级事项，不发表评论才是正确做法。
• 将 priority/critical 用于“重要但无需放下一切来处理”——critical 应保留给真正的紧急情况。拿不准时，默认使用 high。
• 忘记 --remove-label status/needs-triage——会导致事项一直滞留在待处理筛选器中。
• 日期偏差——评论标题中始终使用今天的日期，这样未来的你就知道当时做出判断的时间。