# Evals for observability

These cases are eyeballed, not automated. Read `cases.yaml` and check three things by hand. First, every `should_trigger` prompt should make this skill the obvious pick — pay special attention to the non-obvious ones (the "can't see where the time goes across services" latency-symptom line, and the "LLM calls as spans with token counts" line, since those are where a thinner trigger set would miss). Second, every `should_not_trigger` prompt must route cleanly to its named sibling — the sharp boundary is `monitoring` (it emits no signals, it decides the page) and `cost-tracking` (it prices the gen_ai.* tokens this skill emits); if either of those feels like it could legitimately land here, tighten the description. Third, run the `capability` scenario against a generated answer and confirm each `must_include` item is actually present, not hand-waved — especially that every Collector exporter is wired into a pipeline, that the manual span sets status and attributes, that logs carry trace_id/span_id with no PII, and that no metric uses a high-cardinality label. Note that `scripts/verify.sh` checks the emitted artifact (Collector config + SDK init), not the prose: a great write-up that emits no wired-up config has not finished the job.
