triage-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Triaging a GitHub Issue

GitHub Issue的Triage流程

Overview

概述

Triage = assign

type/

priority/

labels, leave a key comment when there's judgment worth recording, then remove

status/needs-triage

. Inspect the repo's label schema via

gh label list

— the

type/*

priority/*

status/*

convention used below is a common default but adapt to what the repo actually has.

Scope: one issue per invocation. For backlog walkthroughs, the caller enumerates

gh issue list --label status/needs-triage

and invokes this skill per result.

Core principle: comments are signal, not ceremony. Skip when the issue body already covers what you'd say. Only add information the reader can't get from the body or labels alone.

Triage操作指的是为Issue分配

type/

priority/

标签，当需要记录判断依据时留下关键评论，然后移除

status/needs-triage

标签。可通过

gh label list

查看仓库的标签体系——下文使用的

type/*

priority/*

status/*

是通用默认规则，但需根据仓库实际情况调整。

范围：每次调用仅处理一个Issue。对于待办事项梳理，调用者需先执行

gh issue list --label status/needs-triage

列出相关Issue，再针对每个结果调用此技能。

核心原则：评论是有效信息，而非形式化内容。若Issue正文已涵盖你想表达的内容，则无需添加评论。仅补充无法从正文或标签中直接获取的信息。

When to Use

使用场景

User says "triage #N" / "triage this issue"
An issue lacks
```
type/
```
or
```
priority/
```
labels
An issue carries
```
status/needs-triage
```

For backlog work (

triage backlog

/ many issues at once), the caller orchestrates: list issues, invoke this skill per issue.

用户提出“triage #N” / “处理这个Issue”
Issue缺少
```
type/
```
或
```
priority/
```
标签
Issue带有
```
status/needs-triage
```
标签

对于批量待办事项处理（

triage backlog

/ 同时处理多个Issue），需由调用者统筹：先列出Issue，再针对每个Issue调用此技能。

Process

处理流程

Read the issue:
```
gh issue view <n>
```
Read body before deciding (title alone misses scope)
Decide labels: type/ + priority/
Decide comment: see Comment Criteria below

Apply:

bash

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

查看Issue：
```
gh issue view <n>
```
先阅读正文再做决定（仅看标题会遗漏范围信息）
确定标签：分配type/ + priority/标签
确定评论内容：参考下方评论准则

执行操作：

bash

gh issue edit <n> \
  --add-label type/X --add-label priority/Y \
  --remove-label status/needs-triage
gh issue comment <n> --body-file -  # 从标准输入读取内容，支持多行

Priority Rubric

优先级判定标准

Level	Trigger
`critical`	Auth bypass · data loss · prod outage · live exploitation. Drop everything.
`high`	Security with realistic attack path · core flow broken · blocks other work
`medium`	Should fix · degraded UX · refactor with concrete benefit · no user-visible breakage
`low`	Polish · cleanup · nice-to-have · low-risk follow-up

Anchor: who is affected, how reversible the damage is, blast radius. If unsure between two tiers, downgrade.

优先级级别	触发条件
`critical`	认证绕过·数据丢失·生产环境宕机·实时漏洞利用。需暂停所有其他任务优先处理。
`high`	存在可行攻击路径的安全问题·核心流程故障·阻塞其他工作进展
`medium`	应修复的问题·用户体验下降·有明确收益的重构·无用户可见功能故障
`low`	优化完善·清理工作·锦上添花的功能·低风险后续任务

判定锚点：受影响人群、损害的可逆性、影响范围。若在两个级别间拿不定主意，优先降级。

Comment Criteria

评论准则

Always comment when any of these apply:

```
priority/critical
```
or
```
priority/high
```
— record the call so it's defensible later

Issue overlaps another (

see also #N

dup of #N

subset of #N

blocks #N

)

Scope estimate is non-obvious (XS / S / M / L, or hours/days)
A blocker exists (
```
blocked by #N
```
or
```
requires upstream X
```
)

Skip the comment when:

Title + body already cover priority justification AND there's no cross-reference / scope / blocker to add
Comment would just restate what's in the body

Don't repeat the body. If the author already explained why this is critical, the triage comment is for meta information: relationships, scope, dates, defensibility.

Don't read code during triage. If you find an issue needs claims verified against actual code, root cause confirmed, or blast radius probed — that's investigation. Switch to the

investigate-issue

skill and do that one issue properly. Half-investigation makes comments worse than light triage.

在以下任一情况必须添加评论：

优先级为
```
priority/critical
```
或
```
priority/high
```
——记录判定依据，便于后续追溯
Issue与其他Issue存在关联（如
```
参见#N
```
/
```
重复#N
```
/
```
属于#N的子集
```
/
```
阻塞#N
```
）
范围预估不明显（如XS/S/M/L，或按小时/天估算）
存在阻塞因素（如
```
被#N阻塞
```
或
```
依赖上游X
```
）

无需添加评论的情况：

标题+正文已涵盖优先级判定依据，且无关联Issue、范围或阻塞因素需要补充
评论内容仅会重复正文已有信息

不要重复正文内容。若作者已说明问题为何严重，Triage评论应聚焦于元信息：关联关系、范围、时间、判定依据。

Triage阶段不要阅读代码。若发现需要验证代码中的问题、确认根本原因或评估影响范围——这属于调查工作。请切换到

investigate-issue

技能，针对该Issue进行完整调查。不完整的调查会让评论效果不如简单的Triage处理。

Comment Template

评论模板

Mirrors the repo's PR template style — emoji-headed sections for at-a-glance scanning. Sections that add nothing get omitted (don't write "N/A" headers; just skip).

markdown

undefined

与仓库的PR模板风格保持一致——使用带emoji的标题，便于快速浏览。无实质内容的章节需省略（不要写“N/A”标题，直接跳过）。

markdown

undefined

🏷️ Triage YYYY-MM-DD

type/X

priority/Y

· effort: S/M/L

type/X

priority/Y

· 工作量：S/M/L

📊 At a Glance

📊 概览

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.

<图表（mermaid或ASCII图）+ 1行说明——仅当有值得展示的可视化内容时添加>

以下场景适合使用图表：

修复顺序：
```
#29 → #30 → #25
```
（ASCII箭头即可）
攻击流程/竞争条件：使用mermaid
```
sequenceDiagram
```
重构前后对比：使用mermaid
```
flowchart
```
或ASCII框图

若标签+关联列表已能清晰传达信息，则完全跳过此章节（不要留空标题）——大多数简单的Triage处理不需要此部分。

🔗 Related

🔗 关联Issue

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

<仅在相关时添加：重复/阻塞/被阻塞/参见#N>

🚧 Notes

🚧 说明


**Language**: match the issue body. Keep label values, command names, and section headings (`At a Glance`, `Related`, `Notes`) as-is.

**Sizing**: XS = <1h · S = half-day · M = 1–3d · L = >3d. Estimate from blast radius, not from line count.

**Section budget**:

- `🏷️ Triage` line + `📊 At a Glance` — always include (this is the load-bearing summary)
- `🔗 Related` — include when there's a real cross-link, otherwise drop the heading
- `🚧 Notes` — include only when body lacks priority justification or scope is non-obvious; otherwise drop the heading

**Don't** restate what the body already says. The triage comment is meta-information about the _call_, not a re-summary of the _issue_.

<仅当正文缺少优先级判定依据或范围预估不明显时添加>


**语言风格**：与Issue正文保持一致。标签值、命令名称和章节标题（`概览`、`关联Issue`、`说明`）需保持原样。

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

**章节要求**：

- `🏷️ Triage`行 + `📊 概览`——必须包含（这是核心摘要）
- `🔗 关联Issue`——仅当存在真实关联时保留，否则删除标题
- `🚧 说明`——仅当正文缺少优先级判定依据或范围预估不明显时保留，否则删除标题

**不要**重复正文已有内容。Triage评论是关于判定操作的元信息，而非对Issue内容的重新总结。

Quick Reference

快速参考

Command	Purpose
`gh issue view <n> --json title,body,labels`	Read the issue
`gh issue edit <n> --add-label X --remove-label Y`	Apply labels
`gh issue comment <n> --body-file -`	Comment via stdin
`gh issue list --label status/needs-triage --json number,title,body,labels --limit 50`	List backlog (caller enumerates, then invokes this skill per issue)

命令	用途
`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`	列出待处理Issue（调用者需先列出，再针对每个Issue调用此技能）

Common Mistakes

常见错误

Repeating the body in the comment — adds noise. The body is already there; comment for meta only.
Commenting on every issue — silence on a clear medium/low is correct.
priority/critical
for "important but not drop-everything" — reserve critical for true emergencies. Default to
```
high
```
when in doubt.
Forgetting
--remove-label status/needs-triage
— leaves the issue stuck in backlog filter forever.
Date drift — always use today's date in the comment header so future you knows when the call was made.

在评论中重复正文内容——会增加冗余信息。正文已存在，评论仅需补充元信息。
对每个Issue都添加评论——对于清晰的中/低优先级Issue，不添加评论才是正确做法。
将“重要但无需立即处理”的问题标记为
priority/critical
——critical仅用于真正的紧急情况。拿不定主意时默认标记为
```
high
```
。
忘记执行
--remove-label status/needs-triage
——会导致Issue一直停留在待办筛选列表中。
日期错误——评论标题中必须使用当前日期，便于未来追溯判定时间。