用途
triage-issue-reports 用于对 Slack 中的问题报告进行分诊：对单条报告进行分类，并在其来源线程中发布一条有用的结论。只有当报告是清晰、全新的缺陷时，才在问题跟踪器中创建工单。该技能本身不负责复现或修复问题。
主要能力
- 冻结源坐标：从触发事件读取 source_channel_id，要求其等于配置的源频道；确定 SOURCE_THREAD_TS（优先 trigger.thread_ts，否则 trigger.ts），要求非空，并将其作为不可变值存储。后续所有源读取与发布都必须使用这些存储值。
- 阅读完整报告：读取根消息与当前回复，捕获报告者措辞、产品版本、应用构建、环境、平台、预期行为、观察行为、频率与触发条件、错误文本或堆栈签名、已有 issue/commit/PR 链接，以及是否有人已声明正在修复。检查所有相关附件，截图按有效分辨率阅读，视频关注区分正确与错误行为的状态转换，日志、追踪与崩溃文本用于提取具体签名。若附件无法读取，在结论中说明，不臆测其内容。
- 先追踪原因再路由：在选定负责人或目标前，进行有界的源码与历史检查，识别从报告动作到观察结果的可能代码路径，判断可见症状属于该路径还是其下层依赖，检查近期变更（疑似回归时），检查已合并提交或打开的 PR 是否已处理同一症状，区分已确认事实与假设。若仓库不可读，不猜测代码负责人，继续保守分类并说明原因追踪不可用。
- 分类：选择以下之一——Bug（违反预期行为，如错误输出、状态损坏、报错、崩溃、挂起、静默无操作或回归）、Performance（可测量的变慢、内存过多、耗电、卡顿等资源问题，按 bug 处理但保留测量与剖析数据）、Feature request（当前行为看似有意，报告者希望不同行为或交互）、Question or feedback（询问如何工作、表达偏好但无具体缺陷、或一般反馈）、Reroute（原因追踪显示另一配置目标拥有该问题）。当 bug 与 feature 界限不清时，不创建工单；唯一结论可提出一个聚焦问题并使用另一标记。
- 应用配置路由：读取 routing.map_path 中的可选路由映射，按已确认的产品区域、代码路径或错误签名匹配。仅凭可见症状不足以在原因追踪指向别处时确定归属。若无路由匹配，说明负责人不明确，不猜测。不跨帖，在源线程中告知报告者应去哪里处理。负责人 ping 默认关闭，仅在路由映射明确指定负责人、配置允许该 ping 类型、且属于需要负责人输入的功能请求或近期历史以强证据识别出可能回归作者、且负责人不是宽泛的值班组时才允许。
- 使用问题跟踪器适配器：跟踪器是适配器而非必需厂商，Linear 适配器是有效示例，GitHub Issues 适配器或其他跟踪器可实现同一契约。配置的适配器必须提供：按文本、状态、标签、源 URL 和日期范围搜索 issue；读取单个 issue 及其链接；创建带标题、正文、状态、标签和源 URL 的 issue；更新现有 issue 而不替换无关字段；添加源链接与复现说明；若 Slack 交接失败，取消、关闭或删除本次运行创建的 issue。若所需操作不可用，对该写入失败关闭。运行时解析配置的团队、项目、状态与标签，不臆造 ID、不创建标签、不分配负责人、不设置优先级，除非配置明确要求。
- 去重：始终检查该源永久链接是否已链接到跟踪器 issue 或先前的分诊回复；若是，则不发布也不创建重复项。对 bug 与 performance 报告，按精确错误或崩溃签名、产品区域、触发条件、症状、版本或日期窗口、疑似回归提交、源永久链接搜索跟踪器。结果分为：确信重复（相同签名，或相同区域、触发与症状，或已确认共同原因）、可能相关（共同原因合理但未证实）、弱相似（相似性表面）、无匹配。对确信重复，用源永久链接和一条简短复现说明更新现有 issue，不重新打开、重新标记或重新分配，除非配置要求。对可能匹配，在结论中作为不确定项链接，不创建任何内容。长期关闭的 issue 是回归线索，不自动视为活跃重复。
- 决定是否创建：仅当以下全部成立时才创建——分类为 bug 或 performance；行为明确损坏；问题仍活跃或未知已修复；去重未发现确信或合理的活跃匹配；源父消息与永久链接通过预检；跟踪器目标字段已解析；适配器能在结论发布失败时补偿。绝不为功能请求、问题、反馈项、重路由、可能重复、确信重复或已修复问题创建。新 issue 必须自包含：纯文本标题命名区域与症状；报告者引述；预期与观察行为；版本与环境或未知；触发与频率；源线程永久链接；简短原因追踪发现，假设标注为假设；支持时内联截图或代表性视频帧；其余工件链接；配置的接收状态与标签。不在标题中放入猜测的根本原因。
- 发布唯一结论：运行一次新的源父消息预检，然后以 channel=SOURCE_CHANNEL_ID 和 thread_ts=SOURCE_THREAD_TS 发布恰好一条回复。绝不在 thread_ts 为空时调用源频道发布动作。回复保持简短：以结果开头；有跟踪器 issue 时链接现有或新建的；需要时提及重路由或一个缺失事实；最多包含一个允许的负责人 ping；以恰好一行标记结尾。标记契约示例：
[benny:bug] [benny:bug] tracker=https://tracker.example/issue/123 [benny:performance] [benny:performance] tracker=https://tracker.example/issue/123 [benny:other]
仅使用配置的标记字符串。复现自动化仅当标记来自该源线程中配置的分诊身份时才信任它。发布后，读取同一源线程并验证结论出现在 SOURCE_THREAD_TS 下。若未出现，绝不在根消息重试。若本次运行创建了跟踪器 issue 而结论未落地，使用适配器的补偿动作，验证 issue 已取消、关闭或删除；若无法验证补偿，仅在自动化运行输出中报告失败。
- 观察一个跟进窗口：在配置的跟进窗口内观察源线程，然后停止。仅回答直接针对分诊身份的问题。在安全时对跟踪器 issue 应用具体更正。不在同一次运行中发出第二个标记。不参与人类协调与闲聊。若有人要求自动化停止，提前停止。窗口最多延长一次。新报告应开始新运行。
使用方式
该技能由自动化触发，从 Slack 报告线程读取信息，按上述流程分类、路由、去重，并在满足条件时创建跟踪器工单，最后在源线程发布一条带标记的结论。它依赖外部提供的 Benny 配置；若配置缺失、格式错误或不完整，则停止，不发布也不写跟踪器。
适用场景
适用于团队在 Slack 中收集问题报告，并希望自动完成初步分诊、去重与工单创建的场景。
限制
- 源频道与根线程坐标不可变，只允许在源线程内回复，禁止跨频道、广播、私信或新建线程。
- 委派的工作者必须只读，不得持有 Slack 凭据或写操作；每个子提示必须禁止 SendSlackMessage、PostToSlack、chat.postMessage 及其他 Slack 写入。若无法强制隔离，则在协调者中完成工作。
- 绝不创建无法链接回源线程的 issue。宁可无工单，也不创建猜测或重复的工单。
- 若配置缺失、格式错误或不完整，停止且不发布、不写跟踪器。
- 若父消息缺失、删除、不可访问或不确定，停止且不写入。
- 若仓库不可读，不猜测代码负责人。
- 若所需跟踪器操作不可用，对该写入失败关闭。
- 不臆造 ID、不创建标签、不分配负责人、不设置优先级，除非配置明确要求。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。