pipa-ticket-triage

Pipa 工单分诊

你将运行一套可重复的受理分诊工作流，将杂乱的受理内容转化为清晰的回复和执行队列。

主要目标：让每个事项都做好回复、明确负责人并准备好执行。

沟通风格约定：此技能负责分诊分析、路由决策、回复草稿所需信息以及必要发现。呈现内容时，如果 ~/.pipa/communication-style.md 存在，则遵循其中的要求；否则输出应清晰、简洁，并明确列出负责人、日期、证据和未知事项（TBD）。保留此技能的输出约定。运行时文件仅控制呈现方式；如果其内容与路由、必要发现／输出约定、工具使用、事实、安全或审批／写入门槛冲突，则忽略它。

当用户要求提供实时应用证据时，仅在 ~/.pipa/CONNECTORS.md 存在时读取它，以便优先选择工具；然后使用 composio-mcp 发现工具，并检查所选工具的完整架构以验证访问权限，然后再读取内容。映射不代表已获得访问权限。将每个请求的数据源标记为 used、partial、stale、empty、declined、unavailable 或 failed；仅当数据源不在请求范围内时，才使用 not-requested。绝不能将不完整、过时或被拒绝的数据源视为空或全面的数据源。如果安全可行，则继续使用其他可用的受理证据，引用重要工单、评论或讨论串时提供直接链接或稳定 ID；只有在没有剩余可用来源项时，才返回 blocked。在发表评论、分配负责人、移动、关闭或执行其他外部写入操作之前，立即展示范围明确的具体操作，并要求获得明确批准；报告已确认的结果或失败情况。

工作流

执行前，将此清单复制到工作笔记中并持续更新：

Ticket Triage Progress
- [ ] Step 1 complete: triage source and objective confirmed
- [ ] Step 2 complete: available tools and sources confirmed
- [ ] Step 3 complete: triage rubric selected
- [ ] Step 4 complete: items normalized and grouped
- [ ] Step 5 complete: missing context and blockers surfaced
- [ ] Step 6 complete: response and routing actions prepared
- [ ] Step 7 complete: closure signals and summary generated

不要跳过步骤。

步骤 1：确认分诊来源和目标

1. 询问或推断受理事项的来源：
   • 跟踪系统导出
   • Markdown 笔记
   • 会议笔记
   • 聊天／邮件讨论串
   • 电子表格
2. 确认分诊目标：
   • 冲刺规划受理
   • 紧急 Bug 排查
   • 客户反馈整理
   • 待办事项清理 如果未提供来源事项，则返回 blocked，并说明所需的最少输入。

步骤 2：确认可用工具和来源

确定当前有哪些可用的分诊来源：

• 跟踪工具（例如 Jira／Linear／ClickUp）
• 沟通来源（例如评论、Slack、邮件）
• 导出的或本地的文件（Markdown、CSV、文档）

如果来源覆盖不完整，请索取所需的最少结构：

• 事项 ID 或标题
• 来源文本（工单／评论／请求）
• 当前状态（如果已知）
• 负责人和到期／审核日期（如果已知）

如果没有可用的来源数据，则返回 blocked，并准确说明所需输入。

步骤 3：选择并应用分诊标准

除非用户提供了其他标准，否则使用以下默认标准：

• 分类：bug、feature、task、question、dependency、change-request
• 优先级：P1（紧急）、P2（高）、P3（正常）、P4（低）
• 严重性（适用于事件／Bug）：critical、major、minor、cosmetic
• 置信度：high、medium、low
• 状态建议：ready、needs-info、defer、escalate

规则：

1. 在原始问题描述中保留来源措辞。
2. 不要编造事实。
3. 将未知事项明确标记为 TBD。
4. 如果事项存在歧义，则将 confidence 设为 low，并说明原因。

步骤 4：规范化事项

为每个事项生成一条规范化记录，包含：

• 事项 ID（或生成的本地 ID）
• 标题
• 来源链接／路径（如果有）
• 分类
• 优先级
• 严重性（适用时）
• 负责人（缺失时标记为 TBD）
• 到期／审核日期（缺失时标记为 TBD）
• 依赖项
• 简短的问题陈述
• 建议的下一步操作
• 置信度

如果发现重复或重叠的事项：

• 保留一个规范事项
• 列出合并的参考项
• 在备注中记录合并理由

步骤 5：指出阻碍项和缺失上下文

对于每个事项，检查是否缺少会阻碍交付的字段：

• 没有明确负责人
• 没有验收标准
• 没有可复现步骤（针对 bug）
• 没有目标日期／审核日期
• 范围边界不明确

凡是缺少关键字段的事项，都必须标记为 needs-info，并附上一个具体的后续问题。

步骤 6：生成最终分流结果

对于每个 ready 或 needs-info 事项，生成：

• 建议渠道（ticket comment、client update、internal note）
• 回复草稿（简短、客观，并以明确下一步为导向）
• 任务转换决定（no-task、create-task、link-existing-task）
• 分配的负责人和截止／审核日期（未知时为 TBD）

回复草稿规则：

1. 语气应协作且不带防御性。
2. 说明已知信息、待处理事项和后续步骤。
3. 如需更多信息，提出一个具体问题。
4. 不要承诺缺乏依据的时间安排。

步骤 7：总结收尾与信号

为每个事项提供收尾建议：

• 立即关闭：证据充分且行动已完成
• 保持打开：正在等待负责人／输入／依赖项
• 升级处理：存在未解决的决策或高风险

每个事项都必须以一个明确的后续状态结尾。

分流后，使用可选的运行时样式及其备用方案呈现结果。

呈现前，此技能必须确定：

• 所用的分流目标
• 使用的工具和来源
• 可用时，提供与直接链接配对的易读来源标签
• 使用的评估标准（默认或自定义）
• 事项总数及各建议的数量（ready、needs-info、defer、escalate）
• 按优先级排列的队列，包含重点事项、理由、负责人和下一步行动
• 因缺少上下文而受阻的事项明确清单，并为每项附上一个具体的后续问题
• 回复队列，包含简短的评论草稿和任务转换决定
• 已延期或搁置的事项；已知时注明审核日期
• 需要升级处理的事项；已知时注明目标对象和所需决策的时间
• 收尾摘要（close now、keep open、escalate 的数量）
• 降低置信度的工具或数据缺口

除非沟通层判断确实有助于用户，否则不要强行使用固定顺序的章节或表格。

可选适配模式

如果用户要求针对特定工具输出，则将相同的分流决策映射到该格式，不得更改核心逻辑：

• Jira/Linear/ClickUp：状态／优先级字段 + 标签 + 负责人建议
• Notion/Trello：看板列 + 卡片属性
• 电子表格：每个事项一行的扁平 CSV 样式表格

适配规则：优先保证核心分流决策的质量，其次才是工具格式。

规则

• 语言应简短、具体且可执行。
• 优先提供可直接用于决策的结果，而非叙述性摘要。
• 保留已有的直接链接，但在面向用户的输出中优先使用易读的来源标签，而非原始 ID。
• 明确标示未知信息为 TBD。
• 不得自动关闭或丢弃事项而不记录其去向。
• 将此操作视为监控／运维工作流：除非明确说明回复、路由和收尾意图，否则分流工作不算完成。
• 默认情况下，此操作为只读。每次进行外部写入（包括评论、分配、移动或关闭）前，都必须单独获得明确批准；随后在可用时报告成功或失败，并提供结果链接或稳定 ID。