PM Monitor Ticket Triage 是一套面向产品与运营场景的可重复受理分诊工作流，用于把杂乱的输入（工单、评论、客户反馈、缺陷报告、支持请求）整理成清晰的响应与执行队列。技能可直接调用，也可通过 pm-monitor 入口工作流选用。其首要目标是让每个事项达到可响应、可指派负责人、可执行的状态。
用途与流程 技能要求先复制七步清单并在工作笔记中持续更新，不得跳步：
- 确认分诊来源与目标：来源可为工单系统导出、Markdown 笔记、会议记录、聊天/邮件线程、电子表格；目标可为冲刺规划受理、紧急缺陷清扫、客户反馈清理、待办列表整理。若存在 .agents/project-context.md 需先读取，以对齐干系人期望、交付阶段、风险容忍度和沟通风格。未提供来源事项时返回阻塞状态并说明最少所需输入。
- 确认可用工具与来源：识别当前可用的工单工具（如 Jira/Linear/ClickUp）、沟通来源（评论、Slack、邮件）以及导出的本地资料（Markdown、CSV、文档）。来源覆盖不全时，请求最少结构：事项 ID 或标题、来源文本、当前状态、负责人与截止/评审日期（若已知）。
- 选择并套用分诊标准：默认维度包括分类（bug、feature、task、question、dependency、change-request）、优先级（P1 紧急至 P4 低）、严重度（critical、major、minor、cosmetic）、置信度（高/中/低）和状态建议（ready、needs-info、defer、escalate）。要求保留来源原文、不编造事实、未知项标记为 TBD，歧义事项置信度设为低并说明原因。
- 规范化事项：为每项生成包含 ID、标题、来源链接、分类、优先级、严重度、负责人、日期、依赖、问题陈述、建议下一步和置信度的记录；发现重复或重叠时保留一条规范项、列出合并引用并记录合并理由。
- 暴露阻塞与缺失上下文：检查是否缺负责人、验收标准、可复现步骤、目标日期、范围边界；缺失关键字段的事项标记为 needs-info，并附一个具体追问。
- 生成响应与路由输出：为每个 ready 或 needs-info 事项给出建议渠道、简短事实性响应草稿、任务转换决定（不建任务/新建任务/关联已有任务）、路由负责人与日期。响应要求协作、非防御性，说明已知、待定和后续动作，需要信息时只问一个具体问题，不承诺无依据的时间线。
- 关闭与信号汇总：为每项给出关闭建议（立即关闭、保持开启、升级），每项必须以一个明确的下一个状态结束。
输出结构 技能按固定顺序生成分诊报告，包含受理摘要（总数、按分类/优先级统计、各状态数量）、优先队列表、待补信息队列表、响应队列表、延迟/搁置表、升级表和关闭信号表。输出契约还要求返回所用目标、工具与来源、分诊标准、按建议的计数、最紧急前三项及一行理由、因缺上下文被阻塞的事项清单、含评论草稿的响应队列、关闭汇总，以及降低置信度的工具/数据缺口。
工具适配 用户要求特定工具格式时，可在不改变核心逻辑的前提下映射：Jira/Linear/ClickUp 映射为状态/优先级字段、标签和指派人建议；Notion/Trello 映射为看板列与卡片属性；电子表格映射为每项一行的扁平表格。
适用场景与限制 适用于冲刺规划前的受理整理、紧急缺陷清扫、客户反馈清理、待办列表整理等运营型分诊工作。使用时应保持语言简短、具体、可操作，优先输出可直接决策的内容；保留已有 ID 与链接，未知项保持 TBD 可见，不得在未记录去向的情况下自动关闭或丢弃事项。该技能本身不依赖特定平台，实际可用工具与数据源需由使用者提供，技能中未声明具体收费、价格或效果数据。