ticket-triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ticket Triage

工单评审

Evaluate a single ticket against six readiness criteria and produce a clear verdict with actionable remediation guidance.

根据六项就绪标准评估单个工单，给出明确的评审结论及可执行的整改指导意见。

How to Get the Ticket

获取工单的方式

The user might provide the ticket in several ways. Adapt accordingly:

Pasted in the prompt: The ticket text is right there. Use it directly.
File path: Read the file.
Jira / Linear / GitHub Issue / other tracker: If MCP tools are available for the tracker, use them to fetch the ticket. If not, ask the user to paste the content.
Multiple tickets: If given multiple tickets, evaluate each one separately and produce a per-ticket assessment. Do not batch them into a single verdict.

If the ticket content is ambiguous or incomplete (e.g., just a title with no description), note that in your assessment but still evaluate what's there.

用户提供工单的方式可能有多种，请灵活应对：

粘贴在提示中：工单文本直接在提示里，可直接使用。
文件路径：读取对应文件获取工单内容。
Jira / Linear / GitHub Issue 或其他跟踪工具：如果有对应跟踪工具的MCP工具可用，使用其获取工单内容；若没有，请让用户粘贴工单内容。
多个工单：若提供了多个工单，请分别评估每个工单并出具单独的评审结果，不要合并为一个结论。

如果工单内容模糊或不完整（例如只有标题没有描述），请在评审中注明这一点，但仍基于现有内容进行评估。

Evaluation Posture

评估原则

Before diving into the criteria, understand the right mindset for this evaluation. The question you are answering is: "Could a developer pick up this ticket and build the right thing without needing to ask clarifying questions?"

You are not looking for perfection. You are looking for sufficiency. A ticket with slightly informal language that nonetheless communicates the expected behavior clearly is FINE. Only fail a criterion when the gap would genuinely cause a developer to build the wrong thing, miss an important behavior, or be unable to verify their work.

When in doubt, pass the criterion and note an optional improvement. Reserve failures for genuine problems that would block development or lead to incorrect implementations.

在开始对照标准评估前，请先明确正确的评估思路。你需要回答的核心问题是：“开发人员能否直接接手此工单并开发出正确的功能，无需进一步询问澄清？”

你无需追求完美，只需判断内容是否足够充分。即使工单语言稍显非正式，但能清晰传达预期行为，也属于合格范畴。只有当内容缺失会导致开发人员构建错误功能、遗漏重要行为或无法验证工作成果时，才判定该标准不通过。

若存在疑问，默认判定标准通过，并标注可选的优化建议。仅当问题确实会阻碍开发或导致实现错误时，才判定不通过。

The Six Readiness Criteria

六项就绪标准

A ticket is Ready for Development only if it passes ALL six criteria. Failing even one makes it not ready.

工单必须全部通过六项标准才算“已准备好进入开发阶段”。即使只未通过一项，也视为未就绪。

1. Specific Acceptance Criteria

1. 具体的验收标准（ACs）

The ACs must communicate what the feature does concretely enough that a developer knows what to build. They should describe behaviors, not just restate the feature name.

Passes: "Dragging changes order in the UI" -- a developer knows what to implement: drag interaction that visually reorders items

Passes: "When a user submits a task with a title shorter than 3 characters, a validation error appears below the title field" -- very precise and detailed

Fails: "User can create a task" -- this is a feature summary, not an AC. It says nothing about what creating a task involves, what fields are shown, or what happens after creation

Fails: "Validation errors are displayed on the form" -- which errors? for which fields? where on the form?

The bar is "would a developer know what to build?" not "is every edge case documented?" ACs that clearly communicate the expected behavior pass even if they could be more detailed.

验收标准必须足够具体地传达功能内容，让开发人员明确知道要构建什么。标准应描述行为，而非仅复述功能名称。

通过示例：“拖拽可更改UI中的排序”——开发人员清楚需要实现的功能：可拖拽交互，能直观地重新排序项目

通过示例：“当用户提交标题短于3个字符的任务时，标题字段下方会显示验证错误提示”——非常精确详细

不通过示例：“用户可创建任务”——这是功能概述，不是验收标准。它没有说明创建任务的流程、显示哪些字段，或创建后的后续操作

不通过示例：“表单上会显示验证错误提示”——哪些错误？针对哪些字段？在表单的哪个位置？

判断标准是“开发人员是否知道要构建什么？”，而非“是否记录了所有边缘情况？”。只要能清晰传达预期行为，即使可以更详细，验收标准也判定通过。

2. Appropriately Sliced

2. 合理拆分

The ticket is a single, deliverable unit of work. Not an epic disguised as a story, nor an artificial slice that separates tightly coupled concerns (like creating a model in one ticket and adding its validations in another).

Passes: "Add drag-and-drop reordering to the task list" -- single feature, clear scope

Fails: "Build import and export functionality" -- two distinct features with different complexity

Red flags: 3+ distinct capabilities listed, "and" in the title joining unrelated concerns, question marks in the description suggesting the scope isn't decided.

工单是单一、可交付的工作单元。不能是伪装成用户故事的史诗级需求，也不能是人为拆分的、将紧密关联的关注点分离的工单（例如一个工单创建模型，另一个工单添加其验证规则）。

通过示例：“为任务列表添加拖拽重排序功能”——单一功能，范围明确

不通过示例：“构建导入和导出功能”——两个独立的功能，复杂度不同

危险信号：列出3项及以上不同的功能、标题中用“和”连接不相关的关注点、描述中存在表明范围未确定的疑问。

3. Verifiable and Specific ACs

3. 可验证且具体的验收标准

Each AC must be testable -- a QA engineer could determine pass or fail from the AC text. The key question is whether the AC contains subjective language that makes the pass/fail determination a matter of opinion.

Passes: "Order persists after page refresh" -- clear test: reorder, refresh, check

Passes: "A user only sees their own tasks" -- clear test: log in as user A, verify user B's tasks are not visible

Fails: "Query is reasonably performant with large data sets" -- "reasonably" is subjective, "large" is undefined

Fails: "Users perceive the app as more powerful" -- entirely subjective, no way to test

Subjective red-flag words that typically cause failures: "appropriately", "reasonably", "correctly", "clearly", "feels", "perceived", "intuitive", "meaningful". However, context matters -- "User can toggle theme" is fine even though "toggle" is slightly informal, because the behavior is obvious.

每个验收标准必须可测试——QA工程师能根据验收标准文本判断是否通过。核心是验收标准中是否包含主观语言，导致通过/不通过的判定取决于个人意见。

通过示例：“排序结果在页面刷新后保持不变”——测试步骤清晰：重新排序、刷新页面、检查结果

通过示例：“用户只能看到自己的任务”——测试步骤清晰：以用户A登录，验证用户B的任务不可见

不通过示例：“在大数据集下查询性能合理”——“合理”是主观表述，“大”未定义

不通过示例：“用户认为应用功能更强大”——完全主观，无法测试

通常导致不通过的主观危险词汇：“适当的”、“合理的”、“正确的”、“清晰的”、“感觉”、“认为”、“直观的”、“有意义的”。但需结合上下文判断——“用户可切换主题”即使“切换”稍显非正式，也判定通过，因为行为明确。

4. User-Verifiable Through the UI

4. 可通过UI由用户验证

The ticket as a whole must be verifiable by a user interacting with the application. Evaluate this at the ticket level, not per-AC.

Passes: A ticket where the core behavior is user-facing, even if one AC mentions an implementation detail. For example, if a ticket has 3 ACs and two describe UI behavior while one says "foreign key relationship exists", the ticket passes -- it IS user-verifiable. The implementation AC is a style issue to note as an optional improvement, not a criterion failure. If even ONE AC describes a user-observable behavior, the ticket passes this criterion.

Fails: A ticket where ALL ACs describe implementation details ("foreign key exists", "data is stored in the database", "migrations run successfully") with no user-observable behavior at all.

The question is: "Can a user verify this ticket is done by using the app?" If yes, it passes. Period.

整个工单必须可通过用户与应用的交互来验证。请从工单层面评估，而非逐个验收标准评估。

通过示例：核心行为面向用户的工单，即使有一个验收标准提到实现细节。例如，某个工单有3个验收标准，其中两个描述UI行为，一个提到“存在外键关联”，该工单仍判定通过——它是可由用户验证的。实现细节相关的验收标准属于可优化的风格问题，而非标准不通过的理由。只要有一个验收标准描述了用户可观察的行为，工单就通过此标准。

不通过示例：所有验收标准都描述实现细节（“存在外键”、“数据存储在数据库中”、“迁移成功运行”），完全没有用户可观察的行为。

判断标准是：“用户能否通过使用应用来验证工单已完成？”如果可以，就判定通过。仅此而已。

5. Not Infrastructure-Only

5. 非纯基础设施类

The ticket delivers value that a user of the application can experience. Pure infrastructure, tooling, or devops tickets should be typed as "Chores" or "Tasks", not "Stories."

Passes: "User can see a task list page after the app starts" -- infrastructure + user value combined

Fails: "Docker Compose starts the app and database is reachable from Rails" -- developer/infra value only

Infrastructure work is necessary and valid. The criterion is about typing and framing, not dismissing the work. If a ticket is purely infrastructure, recommend reclassifying it as a Chore or merging it with a user-facing ticket so they ship together.

工单能为应用用户带来可感知的价值。纯基础设施、工具或DevOps类工单应归类为“杂务”或“任务”，而非“用户故事”。

通过示例：“应用启动后用户可看到任务列表页面”——结合了基础设施和用户价值

不通过示例：“Docker Compose启动应用，且Rails可连接到数据库”——仅为开发人员/基础设施团队带来价值

基础设施工作是必要且有效的。此标准关注的是工单的类型和表述方式，而非否定工作本身。如果工单是纯基础设施类，建议重新归类为杂务，或与面向用户的工单合并，以便一同交付。

6. Validation Criteria for Data Models

6. 数据模型的验证标准

This criterion applies when a ticket introduces a new data model (a new database table / entity) or adds user-facing fields to an existing model. When it applies, every user-facing field must have explicit validation rules: type, required/optional, min/max length or value, format, allowed values, default value.

Passes: A ticket that includes something like:

Field	Type	Required	Constraints	Default
title	string	Yes	Min 3 chars, max 255 chars	--
status	enum	Yes	pending, in_progress, completed, archived	pending

Fails: "Each task has: Title (string), Description (text), Status, Due date" -- field names and rough types but no validation rules

N/A -- mark as Pass: When the ticket does NOT introduce a new data model. Specifically:

Adding a foreign key for a relationship (e.g., adding
```
user_id
```
to tasks) is a relationship change, not a new data model. Pass.
Using fields that already exist on an established model (e.g., reordering tasks using a
```
position
```
field introduced in an earlier ticket) is not introducing new fields. Pass.
Pure UI changes, behavioral changes, or features that don't touch data models. Pass.

The criterion only triggers when the ticket says something like "create a Comment model" or "each task should have: [list of new fields]" -- i.e., the ticket is defining what data gets stored and the developer needs to know the validation rules to build the forms and model correctly.

Watch for: tickets that mention data fields in the description but have no validation section, enum fields that list values without specifying the default, and fields whose validation rules are defined in a different ticket (this means the ticket isn't self-contained).

此标准适用于引入新数据模型（新数据库表/实体）或为现有模型添加面向用户的字段的工单。适用时，每个面向用户的字段必须有明确的验证规则：类型、必填/可选、最小/最大长度或值、格式、允许值、默认值。

通过示例：工单包含如下内容：

字段	类型	必填	约束条件	默认值
title	string	是	最少3个字符，最多255个字符	--
status	enum	是	pending, in_progress, completed, archived	pending

不通过示例：“每个任务包含：标题（字符串）、描述（文本）、状态、截止日期”——仅列出字段名称和大致类型，无验证规则

不适用——标记为通过：当工单未引入新数据模型时。具体包括：

添加外键建立关联（例如为任务添加
```
user_id
```
）是关联变更，不是新数据模型。判定通过。
使用现有模型已有的字段（例如使用之前工单中引入的
```
position
```
字段对任务重新排序）不属于添加新字段。判定通过。
纯UI变更、行为变更或不涉及数据模型的功能。判定通过。

仅当工单明确提到“创建Comment模型”或“每个任务应包含：[新字段列表]”——即工单定义了要存储的数据，开发人员需要知道验证规则才能正确构建表单和模型时，此标准才适用。

注意：描述中提到数据字段但无验证部分的工单、列出值但未指定默认值的枚举字段、验证规则定义在其他工单中的工单（意味着本工单不独立），均不符合要求。

Evaluation Process

评估流程

For each ticket:

Identify the ticket metadata: title, type, priority (if available)
Evaluate each criterion: Determine pass/fail with specific reasoning that references the actual ticket text
Determine the overall verdict: Ready, Nearly Ready (fails exactly 1 minor criterion with a < 30 min fix), or Not Ready
Identify specific gaps: What exactly is missing or vague, with direct quotes from the ticket
Provide remediation guidance: Concrete steps the team needs to take, not generic advice

针对每个工单：

识别工单元数据：标题、类型、优先级（若有）
评估每项标准：根据工单文本确定通过/不通过，并给出具体理由
确定整体评审结论：就绪、接近就绪（仅未通过1项次要标准，修复时间<30分钟）或未就绪
识别具体差距：明确缺失或模糊的内容，并直接引用工单中的文本
提供整改指导：团队需采取的具体步骤，而非通用建议

Output Format

输出格式

Present the assessment in a clear, scannable format:

undefined

以清晰、易扫描的格式呈现评审结果：

undefined

Ticket Triage: [Ticket Title]

工单评审：[工单标题]

Verdict: [READY FOR DEVELOPMENT / NEARLY READY / NOT READY]

评审结论：[已准备好进入开发阶段 / 接近就绪 / 未就绪]

Criteria Assessment

标准评估

#	Criterion	Result	Notes
1	Specific Acceptance Criteria	Pass/Fail	[brief reason]
2	Appropriately Sliced	Pass/Fail	[brief reason]
3	Verifiable and Specific ACs	Pass/Fail	[brief reason]
4	User-Verifiable Through UI	Pass/Fail	[brief reason]
5	Not Infrastructure-Only	Pass/Fail	[brief reason]
6	Validation Criteria for Data Models	Pass/Fail/N/A	[brief reason]


Then, based on the verdict:

**If READY**: Brief confirmation of why the ticket is good to go. Note any optional improvements (clearly marked as non-blocking).

**If NEARLY READY**: List the 1-2 specific, small changes needed. Provide the exact rewritten AC or addition so the team can copy-paste it.

**If NOT READY**: Include all three of these sections:

**Gaps** -- Bulleted list of every specific gap, grouped by failing criterion. Quote the problematic text from the ticket directly.

**Remediation Steps** -- Numbered checklist of what the team needs to do, in priority order. Be specific: don't say "add validation rules" -- say which fields need which rules. For example:

- Add validation for `title`: required, string, min 3 chars, max 255 chars
- Replace AC "Status is stored in the database" with: "When a user changes a task's status, the new status badge is visible immediately and persists after page refresh"
- Split this ticket into: (1) Status filtering, (2) Due date filtering, (3) Keyword search

**Remediated Example** -- Show a before/after for the most impactful section of the ticket. This teaches the team the pattern so they can apply it to other tickets. Format:

> **Before:**
> - User can create a task
> - Tasks persist in the database
>
> **After:**
> - When a user fills in the task title and clicks "Create", they are redirected to the task list and the new task appears at the top
> - When a user creates a task without a title, a validation error "Title is required" appears below the title field
> - When a user refreshes the task list page, all previously created tasks are still visible

序号	标准	结果	备注
1	具体的验收标准	通过/不通过	[简要理由]
2	合理拆分	通过/不通过	[简要理由]
3	可验证且具体的验收标准	通过/不通过	[简要理由]
4	可通过UI由用户验证	通过/不通过	[简要理由]
5	非纯基础设施类	通过/不通过	[简要理由]
6	数据模型的验证标准	通过/不通过/不适用	[简要理由]


然后，根据评审结论补充内容：

**若为就绪**：简要确认工单可进入开发的原因。注明任何可选的优化建议（明确标记为非阻塞项）。

**若为接近就绪**：列出1-2项具体的小修改需求。提供重写后的验收标准或补充内容，方便团队直接复制使用。

**若为未就绪**：包含以下三部分内容：

**差距**——按未通过的标准分组，列出所有具体差距，直接引用工单中的问题文本。

**整改步骤**——按优先级排序的编号清单，说明团队需要做的具体事项。要具体：不要说“添加验证规则”，而是说明哪些字段需要哪些规则。例如：

- 为`title`字段添加验证规则：必填、字符串类型、最少3个字符、最多255个字符
- 将验收标准“状态存储在数据库中”替换为：“当用户更改任务状态时，新状态徽章会立即显示，且在页面刷新后保持不变”
- 将此工单拆分为：(1) 状态筛选，(2) 截止日期筛选，(3) 关键词搜索

**整改示例**——展示工单中影响最大的部分的前后对比。这能指导团队掌握规范，应用到其他工单中。格式如下：

> **整改前：**
> - 用户可创建任务
> - 任务存储在数据库中
>
> **整改后：**
> - 当用户填写任务标题并点击“创建”时，会被重定向到任务列表页面，新任务显示在顶部
> - 当用户未填写标题就创建任务时，标题字段下方会显示验证错误提示“标题为必填项”
> - 当用户刷新任务列表页面时，所有已创建的任务仍可见

Judgment Calls

判断规则

Default to passing. Your starting assumption should be that a criterion passes. Only fail it when you can point to a specific, concrete problem that would cause a developer to build the wrong thing or be unable to verify their work. "This could be more detailed" is an optional improvement, not a failure.

Redundant implementation ACs: If a ticket has a mix of user-facing ACs and one implementation-detail AC (like "saved to the database"), the ticket still passes criteria 4 (user-verifiable). Note the redundant AC as an optional cleanup in your assessment, but do not fail the criterion. Only fail criterion 4 when the ticket has NO user-verifiable ACs.

Borderline ACs: If an AC communicates the expected behavior clearly enough that a developer would know what to build, it passes criteria 1 and 3 -- even if the wording is informal or could be more precise. "Dragging changes order in the UI" is clear. "Results update correctly" is not (what does "correctly" mean?).

Infrastructure + user value: If a ticket combines infrastructure work with a user-facing deliverable, it passes criterion 5.

Implied data models: If the ticket doesn't explicitly say "create a new model" but the feature clearly requires one (e.g., "users can leave comments on tasks" implies a Comment model), flag the missing data model definition under criterion 6.

Relationships vs. new models: Adding a foreign key to establish a relationship between existing models (e.g.,

user_id

on tasks) does NOT trigger criterion 6. The criterion is about new entities with user-facing fields that need form validation, not about database-level relationship plumbing.

Artificial splits: If a ticket references another ticket for essential details (e.g., "Status values are defined in TICKET-4"), flag this under criterion 2. The ticket should be self-contained or explicitly declare the dependency.

Nearly Ready threshold: Use this when the ticket fails exactly 1 criterion and the fix is small (< 30 minutes of refinement). Two or more failing criteria means Not Ready, even if each fix is individually small.

默认通过：初始假设是标准通过。仅当能指出具体、明确的问题（会导致开发人员构建错误功能或无法验证工作成果）时，才判定不通过。“此处可更详细”属于可选优化建议，而非不通过理由。

冗余的实现类验收标准：若工单混合了面向用户的验收标准和一项实现细节类验收标准（如“保存到数据库”），工单仍通过标准4（可通过UI由用户验证）。在评审中注明冗余的验收标准为可选清理项，但不要判定标准不通过。仅当工单没有任何可由用户验证的验收标准时，才判定标准4不通过。

边界验收标准：只要验收标准能清晰传达预期行为，让开发人员知道要构建什么，就通过标准1和3——即使表述非正式或可更精确。“拖拽可更改UI中的排序”是清晰的；“结果会正确更新”则不清晰（“正确”指什么？）。

基础设施+用户价值：若工单结合了基础设施工作和面向用户的交付内容，则通过标准5。

隐含的数据模型：若工单未明确说明“创建新模型”，但功能显然需要新模型（例如“用户可在任务下发表评论”隐含Comment模型），则在标准6下标记缺失的数据模型定义。

关联 vs 新模型：添加外键以建立现有模型间的关联（如任务表中的

user_id

）不会触发标准6。此标准关注的是带有面向用户字段（需要表单验证）的新实体，而非数据库层面的关联配置。

人为拆分：若工单引用其他工单获取关键细节（例如“状态值定义在TICKET-4中”），则在标准2下标记此问题。工单应独立完整，或明确声明依赖关系。

接近就绪的阈值：当工单仅未通过1项标准且修复工作耗时短（<30分钟）时，使用此结论。即使每个修复都很简单，若未通过2项及以上标准，仍判定为未就绪。

Tone

语气

Be direct and constructive. The goal is to help the team ship better tickets, not to gatekeep. Frame remediation as "here's what would make this ready" rather than "here's what's wrong." When a ticket is well-written, say so -- recognizing good practices helps establish patterns across the team.

直接且有建设性。目标是帮助团队产出更优质的工单，而非设置障碍。将整改建议表述为“这样做可让工单就绪”，而非“此处存在问题”。当工单撰写优秀时，要给予肯定——认可良好实践有助于在团队中建立规范。