用途：把积压的开放支持工单整理为两类产出——有代码或数据依据的回复草稿，以及针对真实缺陷的 PR 草稿。核心原则是先诊断、后写代码，并先判断症状属于哪一层。
枚举队列：工单存在于 conversations 产品中，可通过 PostHog MCP 的 execute-sql 工具查询 system.support_tickets（项目 2，US）；Zendesk 镜像在数据仓库中保留完整评论历史。参考 references/ticket-queries.md 提供现成 SQL：开放工单扫描、关键词过滤、Zendesk 完整评论提取（child_events JSON 模式）、跨 US 与 EU 区域把请求者邮箱解析到组织或团队。Slack 频道 #support-web-analytics 会同步新 Zendesk 工单，消息内链接携带 conversations UUID。
分类并执行对应剧本（详见 references/diagnostic-playbooks.md）：前端崩溃查错误跟踪与 sourcemap；两个数字不一致先讲语义（事件级与会话入口级范围、landing 与 containing、任意事件与入口事件过滤器）；计数随时间下降需区分原始存储计数与查询侧排除，$pageview 与 $pageleave 比例、UA 分段、SDK 版本固定都相关，机器人流量消失通常不是缺陷；追踪器未加载或计数低于竞品需用 Playwright 对客户线上站点做运行时加载审计；广告平台集成错误涉及来源重建、OAuth 失败模式（如 Microsoft AADSTS650052）与归因连接键；渠道类型误判查 channel_definitions.json 与 channel_type.py 决策树。
产出：回复草稿中每个结论须落到 file:line、查询结果或文档链接，并给出对齐的过滤器或属性；修复 PR 每个修复独立 worktree 与分支，使用约定式提交和仓库模板的草稿 PR，公开仓库不得出现客户名称、Zendesk 编号或客户流量规模。另用 .notes/ 维护分诊笔记。验证工具包括运行时加载审计、通过 Metabase 查询生产库（prod-us、prod-eu）以及错误跟踪 MCP 查询。未提供价格与平台限制等信息。