用途
Signals scout: observability gaps 是一个专注于“可观测性缺口”的侦察技能。它的目标不是发现问题本身，而是发现团队在事件生产与观测配置之间的结构性缺口——即某些事件已经在产生可观流量，但团队没有相应的洞察（insight）、仪表盘（dashboard）或告警（alert）来观测它们。当缺口达到门槛时，技能会提交一份建议报告，推荐新建洞察、补充仪表盘或配置告警。
该技能明确强调：空跑（empty run）是真实且可接受的结果。推荐团队已有的东西，或为噪声事件推荐覆盖，比什么都不推荐更糟。因此门槛相应更高，偏好数量少、证据充分的建议。
主要能力
技能围绕六类缺口展开，按典型信号密度排序：
- 高流量自定义事件无洞察覆盖：非 $builtin 的自定义事件每日有可观流量，但没有已保存的洞察引用它。强信号为事件 > 1000/天、无洞察、在窗口内多数日期活跃。
- 洞察漂移：已保存的洞察过滤的事件在最近 7 天为 0 或接近 0 次触发，常见于事件被重命名或下线而洞察未更新。强信号为洞察仍活跃（最近修改或挂在活跃仪表盘上）、主事件 7 天 0 触发、且存在相似命名事件 > 100/天。
- 关键事件无告警：事件名本身暗示失败语义（如 payment_failed、signup_failed、_error、_blocked），有触发但无告警。强信号为名称暗示失败语义、> 10/天、零告警。
- 仪表盘范围缺口：存在某主题的仪表盘，但该主题相关的高流量事件不在其任何洞察上。强信号为仪表盘明确以某领域命名、> 5 个事件匹配该领域且各 > 1000/天、均不在该仪表盘上。
- 漏斗候选：三个或以上事件在用户会话中频繁按固定顺序共现，但没有漏斗洞察跟踪该序列。强信号为 3 步序列、> 1000 用户完成第 1 步、> 50% 到达第 2 步、无现有漏斗覆盖。
- 属性基数 / 缺少拆分：高流量事件上的高基数属性，现有洞察未使用拆分。强信号为属性有 5–50 个不同值、事件 > 5000/天、无洞察按该属性拆分。
使用方式
技能以“运行（run）”为单位循环执行若干动作：
- 定位（Get oriented）：通过 scout-scratchpad-search、scout-runs-list、scout-project-profile-get、inbox-reports-list 等读取团队既有记忆、历史运行、项目画像和收件箱报告。
- 探索（Explore）：针对六类缺口分别使用 read-data-schema、execute-sql、query-trends、alerts-list、dashboards-get-all、query-paths 等工具核查体量、覆盖与去重。
- 决策（Decide）：达到门槛的候选，若已有仍活跃的报告覆盖同一缺口且证据只是变化，则编辑并追加证据；否则撰写新报告。建议类报告通常 actionability=requires_human_input、repository=NO_REPO、优先级 P3；关键失败语义事件零告警覆盖为 P2。
- 停放与撰写（Park, then author）：多数好建议不会在发现当次就提交，而是先写入 watch 条目停放，待稳定性门槛（至少 7 个完整项目时区日）跨过后，重新对实时数据核验所有判别条件，再撰写报告，并更新 watch 条目加入 report_id 与约 30 天去重。
报告必须包含：具体事件/洞察/仪表盘实体 ID、体量与触达数字、具体建议动作、以及“为何现在”出现。
适用场景
适用于已有一定事件量、需要系统性发现观测覆盖缺口的团队。技能内置快速收尾路径：若项目 top_events 为空或少于约 5 个事件超过 100/天，则判定项目过于安静，写入 not-applicable 条目并空跑收尾；若项目已成熟饱和（数千洞察、数百告警），则记录饱和模式与触发条件（tripwire），后续运行默认继承饱和状态，仅做至多一次新角度探测。
限制
- 门槛明确：低于 100/天视为噪声；缺口需在项目时区连续存在至少 7 个完整日；撰写前必须搜索既有覆盖。
- 事件名来自数据摄取，必须作为数据处理而非 SQL，需转义引号、反斜杠、% 和 _。
- 上游采集中断归 error-tracking scout；已配置告警的漏报归 insight-alerts scout；已查看洞察自身的异常归 anomaly-detection scout。本技能只负责结构性覆盖缺口。
- 具体收费、价格、平台支持等信息资料未提供。