用途：在每日或值班巡检中分诊 PostHog 错误跟踪问题，回答“哪里坏了”“有哪些新错误”等提问，目标是给出简短、按优先级排序、值得人工关注的问题清单，而不是倾倒所有活跃问题。多数项目有数百个活跃问题，真正重要的通常是新出现（最近 24-48 小时首次出现）、量级突增或影响大量不同用户的问题。
主要能力：提供查询错误跟踪问题列表（含出现次数、用户数、会话数等聚合指标并排序）、单个问题详情（状态、负责人、顶层栈帧、发布版本）、采样 $exception 事件（含堆栈、URL、浏览器、$session_id）、查找命中该问题的会话回放，以及读取 Inbox 预筛选的可操作信号。
使用方式：先根据用户措辞确定时间窗口，未指定时默认“今天/现在”用 -24h、“本周”用 -7d、值班交接用 -24h；再选择“重要”的判定信号——新问题用 orderBy: "first_seen" 配合 DESC 和紧窗口，高影响用 orderBy: "users" 按受影响用户数排序，趋势用 orderBy: "occurrences" 对比短窗口与较长基线找突增。随后拉取候选列表，从窄开始，结果太少再放宽；volumeResolution 要与窗口匹配（-24h 用 24 个桶），否则只有总量看不出形状。若项目混合浏览器与服务端 SDK，按用户数排序常被服务端错误淹没，可用 library 过滤（值匹配 SDK 的 $lib，如 posthog-js、posthog-node、posthog-python、posthog-edge、posthog-ios 等）。接着过滤噪声：窗口内量级平稳的、纯机器人来源的应剔除或标记为抑制。对前 3-5 个候选项用 query-error-tracking-issue-events 拉取样本异常，获得栈帧与 URL，而非只有标题。最后先给一行结论，再用表格按所选信号排序展示问题、首次出现时间、用户数、会话数、样本消息和建议动作（调查、指派、抑制、合并或已修复则解决）。
适用场景：面向用户的应用以“用户数”作为严重度代理；无真实 distinct_id 的后端服务可退回用会话数或出现次数。若项目使用 Inbox，应先检查，可能已有精选结果。
限制：分诊过程中不要自动指派或自动解决，应呈现清单由用户决定，批量操作属于专门技能。不要为每个分诊问题都拉取回放，仅在用户要求深入时进行。提供每行的 _posthogUrl 便于跳转；自行构造链接须用完整 /project/<project_id>/error_tracking/<id> 路径。相关技能包括 investigating-error-issue、grouping-noisy-errors、suppressing-noisy-errors、authoring-error-tracking-alerts。