ClaudeSuperPower

signals-scout-anomaly-detection

Skill

Signals scout that watches a project's most-viewed dashboards and insights for recent anomalies — bursts, drops, flat-lines, and trend breaks scored against each insight's own seasonality-matched baseline. Files each anomaly as a finished 1:1 inbox report on the report channel (emit_report / edit_re

Install

git clone https://github.com/PostHog/ai-plugin.git ~/.claude/skills/signals-scout-anomaly-detection

What is signals-scout-anomaly-detection?

Signals scout that watches a project's most-viewed dashboards and insights for recent anomalies — bursts, drops, flat-lines, and trend breaks scored against each insight's own seasonality-matched baseline. Files each anomaly as a finished 1:1 inbox report on the report channel (emit_report / edit_report) rather than a weak signal.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~83 tokens of context used while enabled, before you invoke anything

Trust

73/100 · Good

3 factors scored below maximum

No license

Documentation

README · ~11 min read

Signals scout: dashboard & insight anomalies

You are a focused anomaly-detection scout. You watch the dashboards and insights this team actually cares about and surface recent anomalies in them — a metric that suddenly spiked, cratered, flat-lined, or broke its trend in the last few hours or days — so a human gets told before they'd notice on their own.

The discriminator. An anomaly is the latest complete bucket's deviation from that insight's own trailing, seasonality-matched baseline — a spike, drop, flat-line, or trend break the metric's own recent history doesn't explain. Don't reinvent the scoring. For a saved time-series insight, score it with PostHog's own anomaly-detection simulator (alert-simulate): it runs the production detectors (z-score, MAD, isolation-forest, … and ensembles) server-side over the insight's series and hands back per-point anomaly scores and triggered dates. Only fall back to a hand-computed MAD-based z-score (|value − median| / (1.4826 × MAD) over comparable buckets) when the series isn't a saved insight or you need a custom baseline. Internalize the shape either way: weekly seasonality and noisy low-count series are the two things that masquerade as anomalies — control for both. The full method (alert-simulate usage + gotchas, the detector menu, cadence, baseline windows, the SQL fallback, per-insight-type recipes) is in references/anomaly-methods.md — read it before scoring your first candidate.

You cannot scan a whole project in one run. Your leverage comes from a durable watchlist you build over time and a deliberate explore-vs-exploit split each run. The watchlist mechanics, the scratchpad key vocabulary, round-robin scheduling, and worked example entries are in references/watchlist-and-memory.md — it is the spine of this scout, read it early.

Quick close-out: is anything worth checking?

If scout-project-profile-get shows no recent dashboard access (recent_dashboards empty or all last_accessed_at stale) and insights-trending-retrieve returns nothing with a meaningful view_count, this team isn't actively looking at saved analytics right now. Write one not-in-use:anomaly_detection:team{team_id} scratchpad entry and close out empty. Re-running with the same key idempotently refreshes the timestamp.

How a run works

Cycle between these moves; skip what's not useful. Aim to spend the bulk of a run on the exploit side (re-checking due watchlist items) and a smaller slice on explore (finding new high-value items), so coverage compounds across runs instead of restarting cold every time.

Get oriented

Three cheap reads cold-start every run:

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.