triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Triage

Move tickets through the pre-implementation part of the board: from raw

Triage

to a fully groomed

Ready for Agent

Ready for Human

, so

engineer

only ever executes work that is already spec'd. Division of labour: triage grooms, engineer executes, reviewer merges. All three share one vocabulary.

Every comment posted during triage MUST start with:

> *This was generated by AI during triage.*

将工单在看板的预实现阶段进行流转：从原始的

Triage

状态到完全梳理后的

Ready for Agent

或

Ready for Human

状态，确保

工程师

仅执行已明确需求的工作。分工方式：工单梳理人员负责梳理，工程师负责执行，评审员负责合并。三者使用统一的术语体系。

工单梳理过程中发布的每条评论必须以以下内容开头：

> *This was generated by AI during triage.*

Resolve the tracker first (tracker-agnostic)

先适配看板平台（跨平台兼容）

Look up the repo root (

git rev-parse --show-toplevel

) in

~/.claude/afk.json

under

repos

. The entry names the

tracker

(

github

linear

, or any future one) and the board coordinates. If there is no entry, suggest

/afk-setup

This skill is written in a canonical vocabulary; the actual status/label strings live on the board, and boards SHOULD be configured to use these names verbatim. Any tracker only needs to support these five operations:

fetch a ticket (title, body, comments, labels, status, reporter, dates, blockers)
set status (to a canonical column)
add / remove a label
post a comment
close / cancel a ticket

Adapters today: GitHub Projects (

gh issue ...

gh project item-edit

), Linear (MCP

get_issue

save_issue

save_comment

list_comments

, loaded via ToolSearch). Any new tracker: implement those five operations and map the canonical names to its strings; nothing else here is tracker-specific.

在

~/.claude/afk.json

的

repos

字段中查找仓库根目录（通过

git rev-parse --show-toplevel

获取）。该条目会指定

tracker

类型（

github

、

linear

或未来支持的其他类型）以及看板坐标。如果没有对应条目，建议执行

/afk-setup

。

本技能采用标准术语体系；实际的状态/标签字符串存储在看板上，看板应配置为直接使用这些名称。任意看板平台只需支持以下五项操作：

获取工单（标题、内容、评论、标签、状态、提交人、日期、依赖项）
设置状态（切换到标准列）
添加/移除标签
发布评论
关闭/取消工单

当前支持的适配器：GitHub Projects（通过

gh issue ...

、

gh project item-edit

命令）、Linear（通过ToolSearch加载的MCP接口

get_issue

save_issue

save_comment

list_comments

）。新增看板平台适配：只需实现上述五项操作，并将标准名称映射到平台自身的字符串即可；本技能的其余部分与平台无关。

The board vocabulary (shared with engineer + reviewer)

看板术语体系（与工程师、评审员共享）

Status = pipeline stage (columns). Triage works the left end:

```
Triage
```
: raw; needs evaluation/grooming. Triage's input.
```
Ready for Agent
```
: fully spec'd; an AFK agent can pick it up. Triage output.
```
Ready for Human
```
: fully spec'd, but needs a human (judgment, manual testing, or access an agent lacks). Triage output.

In Progress

In Review

Changes Requested

Done

: owned by

engineer

and

reviewer

; triage does not move these.

Terminal:
```
Won't Fix
```
/
```
Canceled
```
(close the ticket).

Category = kind of work (labels), orthogonal to status (same set as engineer):

bug

enhancement

security

tech-debt

documentation

research

Sub-state labels:

```
needs-info
```
: a
```
Triage
```
ticket blocked on the reporter. Stays in
```
Triage
```
; clears when they reply.

Priority = urgency, a required field (the board's native priority, not a label). Every groomed ticket carries one. Linear's names and our shorthand:

Linear	Shorthand	When
Urgent	P0	drop-everything: broken prod, data loss, a live security hole
High	P1	`bug` and `security` by default; anything blocking other work
Medium	P2	the default: features, enhancements, tech-debt
Low	P3	nice-to-have, no near-term cost

Default to Medium. A

bug

security

ticket is at least High, Urgent if it is actively breaking production or losing/leaking data; use judgment beyond that. Set a best-guess priority when you CREATE an issue, and make sure it is set by the time the ticket leaves

Triage

. On a tracker with no native priority field, carry it as a

P0

P3

label.

A groomed ticket carries exactly one category label, a priority, and lands in exactly one status. If signals conflict, flag it and ask the maintainer before acting.

状态 = 流水线阶段（列）。工单梳理负责处理左侧的初始阶段：

```
Triage
```
：原始状态；需评估/梳理。是工单梳理的输入状态。
```
Ready for Agent
```
：需求完全明确；AFK Agent可直接接手。是工单梳理的输出状态。
```
Ready for Human
```
：需求完全明确，但需要人工处理（判断、手动测试或Agent无法获取的权限）。是工单梳理的输出状态。

In Progress

In Review

Changes Requested

Done

：由

工程师

和

评审员

负责；工单梳理不处理这些状态。

终结状态：
```
Won't Fix
```
/
```
Canceled
```
（关闭工单）。

分类 = 工作类型（标签），与状态正交（与工程师使用的分类集一致）：

bug

、

enhancement

、

security

、

tech-debt

、

documentation

、

research

。

子状态标签：

```
needs-info
```
：
```
Triage
```
状态的工单因等待提交人信息而阻塞。保持
```
Triage
```
状态；提交人回复后清除该标签。

优先级 = 紧急程度，为必填字段（使用看板原生的优先级字段，而非标签）。所有已梳理的工单都需设置优先级。Linear的优先级名称及我们的简写：

Linear	简写	使用场景
Urgent	P0	需立即处理：生产环境故障、数据丢失、活跃安全漏洞
High	P1	默认用于 `bug` 和 `security` 工单；任何阻塞其他工作的任务
Medium	P2	默认优先级：功能开发、功能增强、技术债务处理
Low	P3	锦上添花的需求，无近期成本压力

默认优先级为Medium。

bug

或

security

工单至少设为High优先级；若正在导致生产环境故障或数据丢失/泄露，则设为Urgent优先级；其他情况按需判断。创建工单时需设置一个初步优先级，并确保工单离开

Triage

状态前已确认优先级。对于无原生优先级字段的看板平台，使用

P0

P3

标签来标识优先级。

已梳理的工单需包含且仅包含一个分类标签、一个优先级，并处于唯一的状态。若信号存在冲突，需先标记并询问维护人员后再操作。

Invocation

调用方式

The maintainer invokes

/triage

and describes intent in natural language. Interpret and act. Examples:

"Show me anything that needs my attention"
"Triage JAM-12" / "let's look at #42"
"Move #42 to Ready for Agent"
"What's ready for agents to pick up?"

维护人员通过

/triage

命令调用，并以自然语言描述意图。工具会解读并执行操作。示例：

"展示所有需要我关注的工单"
"梳理JAM-12" / "查看#42"
"将#42移至Ready for Agent状态"
"哪些工单已准备好让Agent接手？"

Show what needs attention

展示需关注的工单

Query the board and present, oldest first:

Untriaged: never evaluated (no category label).
Triage
: evaluation in progress.
needs-info
with reporter activity since the last triage notes: needs re-evaluation.

Show counts and a one-line summary per ticket. Let the maintainer pick.

查询看板并按创建时间从早到晚展示：

未梳理：从未被评估（无分类标签）。
Triage
状态：正在评估中。
带有
needs-info
标签且提交人自上次梳理记录后有新活动：需重新评估。

展示工单数量及每条工单的一行摘要，由维护人员选择处理对象。

Triage one ticket

单条工单梳理流程

Gather context. Read the full ticket (body, comments, labels, reporter, dates) and any prior triage notes (don't re-ask resolved questions). Explore the codebase via the repo's knowledge vault (start at
```
docs/<repo>-vault/_index.md
```
if present) and the domain glossary, respecting ADRs in the area. Read
```
.out-of-scope/*.md
```
and surface any prior rejection that resembles this ticket.
Recommend. State your category + priority + target-status recommendation with reasoning, plus a brief relevant codebase summary. Wait for direction.
Reproduce (bugs only). Before any grilling, attempt reproduction: read the steps, trace the code, run tests/commands. Report the result: successful repro with code path, failed repro, or insufficient detail (a strong
```
needs-info
```
signal). A confirmed repro makes a much stronger brief.
Grill (if needed). If the ticket needs fleshing out, run
```
/grill-with-docs
```
.
Apply the outcome:
- ```
Ready for Agent
```
  : post an agent brief (
```
references/agent-brief.md
```
  ), set the priority (required; see the priority table), and set status
```
Ready for Agent
```
  .
- ```
Ready for Human
```
  : same brief structure, plus why it can't be delegated (judgment calls, external access, design decisions, manual testing); set the priority and status
```
Ready for Human
```
  .
- ```
needs-info
```
  : add the label, post triage notes (template below), keep status
```
Triage
```
  .
- ```
Won't Fix
```
  (bug): polite explanation, then close.
- ```
Won't Fix
```
  (enhancement): write to
```
.out-of-scope/
```
  (
```
references/out-of-scope.md
```
  ), link to it from a comment, then close.

收集上下文。阅读工单完整内容（标题、正文、评论、标签、提交人、日期）及所有过往梳理记录（避免重复询问已解决的问题）。通过仓库的知识 vault（若存在则从
```
docs/<repo>-vault/_index.md
```
开始）和领域术语表探索代码库，尊重相关领域的ADR（架构决策记录）。阅读
```
.out-of-scope/*.md
```
文件，若存在与当前工单类似的过往拒绝记录，需予以指出。
给出建议。说明你建议的分类+优先级+目标状态，并附上理由，以及简要的相关代码库摘要。等待维护人员指示。
复现问题（仅针对bug工单）。在进一步询问前，尝试复现问题：阅读步骤、追踪代码、运行测试/命令。报告结果：成功复现并说明代码路径、复现失败，或信息不足（强烈建议标记
```
needs-info
```
）。确认复现的问题会让工单描述更有说服力。
补充信息（若需要）。若工单需要补充细节，执行
```
/grill-with-docs
```
命令。
执行结果：
- ```
Ready for Agent
```
  ：发布Agent任务简报（参考
```
references/agent-brief.md
```
  ），设置优先级（必填；参考优先级表格），并将状态设为
```
Ready for Agent
```
  。
- ```
Ready for Human
```
  ：使用相同的简报结构，额外说明无法委托给Agent的原因（判断决策、外部权限、设计决策、手动测试）；设置优先级并将状态设为
```
Ready for Human
```
  。
- ```
needs-info
```
  ：添加该标签，发布梳理记录（使用下方模板），保持状态为
```
Triage
```
  。
- ```
Won't Fix
```
  （bug工单）：给出礼貌的解释，然后关闭工单。
- ```
Won't Fix
```
  （功能增强工单）：将拒绝理由写入
```
.out-of-scope/
```
  目录（参考
```
references/out-of-scope.md
```
  ），在评论中链接该文件，然后关闭工单。

Quick status override

快速状态覆盖

If the maintainer says "move #42 to Ready for Agent", trust them and apply it directly. Confirm what you're about to do (status change, label, comment, close), then act. Skip grilling. If moving to

Ready for Agent

without a grilling session, ask whether they want an agent brief written first.

若维护人员说“将#42移至Ready for Agent状态”，请直接执行该操作。先确认你要执行的操作（状态变更、标签修改、评论发布、关闭工单），然后执行。跳过补充信息步骤。若未经过补充信息步骤就将工单移至

Ready for Agent

状态，需询问维护人员是否需要先撰写Agent任务简报。

Needs-info template

Needs-info模板

markdown

undefined

markdown

undefined

Triage Notes

工单梳理记录

What we've established so far:

point 1
point 2

What we still need from you (@reporter):

question 1
question 2

Capture everything resolved during grilling under "established so far" so the work
isn't lost. Questions must be specific and actionable, not "please provide more info".

目前已确认的信息：

要点1
要点2

仍需向你（@提交人）确认的信息：

问题1
问题2

将补充信息过程中解决的所有问题记录在“目前已确认的信息”部分，避免工作成果丢失。问题必须具体且可执行，不能是“请提供更多信息”这类模糊表述。

Resuming a previous session

恢复之前的会话

If prior triage notes exist on the ticket, read them, check whether the reporter has answered outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.

若工单上存在过往梳理记录，请先阅读这些记录，检查提交人是否已回复未解决的问题，并在继续操作前呈现更新后的情况。避免重复询问已解决的问题。

Pairs with

协作角色

engineer pulls
```
Ready for Agent
```
(and co-pilots
```
Ready for Human
```
).
reviewer owns
```
In Review
```
-> merge /
```
Changes Requested
```
. Keep the vocabulary identical across all three; that is what lets a ticket flow Triage -> Ready -> In Progress -> In Review -> Done on any tracker.

工程师领取
```
Ready for Agent
```
状态的工单（并协助处理
```
Ready for Human
```
状态的工单）。
评审员负责
```
In Review
```
到合并/
```
Changes Requested
```
的流程。确保三者使用完全相同的术语体系，这样工单才能在任意看板平台上顺畅流转：Triage -> Ready -> In Progress -> In Review -> Done。

References (load on demand)

参考文档（按需加载）

```
references/agent-brief.md
```
: the durable agent-brief format (the contract an agent works from; survives refactors, no file paths/line numbers).
```
references/out-of-scope.md
```
: the
```
.out-of-scope/
```
rejected-request knowledge base (institutional memory + dedup of feature rejections).

```
references/agent-brief.md
```
：标准化的Agent任务简报格式（Agent执行工作的依据；可经受重构，不包含文件路径/行号）。
```
references/out-of-scope.md
```
：
```
.out-of-scope/
```
目录下的拒绝请求知识库（机构记忆+避免重复拒绝相似功能请求）。