用途
Ticket Triage 用于评估单个开发工单（用户故事、功能请求、缺陷报告）的就绪度，判断开发者能否在不追问澄清问题的情况下直接开工并构建正确的内容。它输出结构化的 READY / NEARLY READY / NOT READY 结论，并附带可操作的整改指导。
主要能力
该技能围绕六项就绪标准进行评估，工单必须全部通过才算就绪：
- 具体的验收标准：验收标准需具体描述功能行为，而非仅复述功能名称。
- 切分恰当：工单是单一可交付的工作单元，不是伪装成故事的史诗，也不是人为割裂紧密耦合的关注点。
- 验收标准可验证且具体：每条验收标准都可测试，不含导致通过/失败取决于主观判断的模糊语言。
- 可通过 UI 由用户验证：工单整体可由用户通过应用交互验证。只要有一条验收标准描述用户可观察的行为即通过。
- 非纯基础设施：工单交付用户可体验的价值。纯基础设施、工具或运维工单应归类为 Chore 或 Task。
- 数据模型的校验标准：当工单引入新数据模型或为现有模型添加面向用户的字段时，每个字段需有明确的校验规则（类型、必填/可选、长度或值范围、格式、允许值、默认值）。不引入新数据模型时标记为 N/A 并通过。
使用方式
工单可通过多种方式提供：直接粘贴在提示词中、提供文件路径、或通过 Jira / Linear / GitHub Issue 等跟踪器的 MCP 工具获取（若无 MCP 工具则请用户粘贴内容）。若提供多个工单，会分别评估并给出逐工单的评估结果，不会合并为单一结论。若工单内容含糊或不完整（例如只有标题没有描述），会在评估中注明但仍评估现有内容。
评估流程为：识别工单元数据（标题、类型、优先级）；逐项判定通过/失败并引用实际工单文本给出理由；确定总体结论；指出具体缺口并直接引用工单文本；提供具体整改步骤。
输出格式为清晰的表格化评估，包含结论、六项标准的逐项结果与简要理由。根据结论不同，READY 时简要确认并标注可选改进；NEARLY READY 时列出 1-2 项具体小改动并提供可直接复制粘贴的改写验收标准；NOT READY 时包含缺口、整改步骤和整改示例（前后对比）三部分。
适用场景
适用于团队在开发前对工单进行就绪度把关，帮助团队写出更好的工单。在独立模式下为建议性质，在流水线模式下为门禁性质——NOT READY 的工单不能进入切片队列。
限制
评估默认倾向通过：当标准处于边界且合理开发者会有分歧时，给予通过；但若需扭曲逻辑才能通过，则说明应判定失败。NEARLY READY 的“< 30 分钟修复”是粗略的人工工作量估计，若修复需要调研、会议或设计决策，则不算 30 分钟修复。两项或以上标准失败即为 NOT READY，即使每项修复单独看都很小。