该技能面向 PostHog 错误追踪中处于活跃状态的 issue，提供一套从聚类、分类到修复与状态更新的工作流程。资料描述的典型场景是 Livewire / Alpine 单页应用中大量浏览器异常，多数为导航瞬态竞态、第三方库抛出或浏览器噪声，而非真实缺陷。
用途
- 系统性分诊 PostHog 错误追踪中的活跃 issue，避免仅凭标题逐条盲目修复。
- 先按根因聚类，每个原因只修一次，再统一处置该簇内的所有 issue。
主要能力
- 加载工作集：按最后出现时间列出活跃 issue，并限定在项目上下文中指定的项目，不切换项目。
- 根因聚类：PostHog 按异常类型和顶部帧分组，技能要求按共享原因重新归组，确保每个活跃 issue 都归属某个簇。
- 分类：为每个 issue 输出一行结论，类别包括 STALE（在已知修复的部署后停止）、TRANSIENT（导航竞态）、VENDOR（第三方库抛出）、NOISE（跨域 Script error、ResizeObserver 循环等）与 LEGIT（稳态真实错误），需附证据。
- 分层修复：应用侧 Alpine 组件或页面脚本按项目注册模式修复；Livewire/Filament 行为修 PHP 并补 Pest 回归测试；可控噪声加 before_send 匹配器；第三方与浏览器噪声只加抑制规则，不打补丁。
- 状态设置：修复、陈旧、瞬态标记为 resolved；第三方与噪声标记为 suppressed；受阻 issue 保持活跃并注明解除条件。
- 可选部署后复核：对等待部署验证的 issue，可询问是否在 24–48 小时内安排一次性复查。
使用方式
- 若仓库存在 .agents/posthog.md，先读取其中的项目 id、before_send 过滤文件、注册模式与既有修复先例，并遵循仓库 AGENTS.md / CLAUDE.md 中关于测试、资源构建、缓存清理的要求。
- 首次调用 PostHog 前阅读 references/posthog-mcp.md，了解 exec 工具、错误追踪工具、状态延迟以及 resolved 与 suppressed 的区别。
- 使用 execute-sql 拉取异常前后的事件时间线，用于判断顶部帧是否具有误导性。
- 提交时每个提交对应一个逻辑修复，并在提交正文列出所覆盖的 PostHog issue id，仅使用普通引用。
- 结束时报告活跃数从 N 到 M，每个簇一行，以 ✅ resolved 或 ⚠️ active 加阻塞原因开头。
适用场景
- 使用 PostHog 错误追踪、以 Livewire / Alpine 构建的单页应用团队。
- 需要按证据区分真实缺陷与噪声、并批量处置积压 issue 的维护工作。
限制
- 资料未提供安装命令、代码示例或具体接口参数，相关细节暂未提供。
- 计划内的定时复查依赖运行环境能力；资料说明在无云例程时，CronCreate 仅在当前会话保持打开时触发。
- 对等待部署验证的 issue，需保留旧 bundle 尾部的出现记录并注明待部署验证，不能立即视为完全解决。