Metrics anomaly investigator
Skill KirKruglov/claude-skills-kit/skills/data-analysis/metrics-anomaly-investigator
70+ curated agent skills for Claude Cowork and Claude.ai — ready-to-use tools for non-technical users: project management, productivity, and AI workflow automation
npx -y skills add KirKruglov/claude-skills-kit --skill metrics-anomaly-investigatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Investigate metric anomalies — build a ranked hypothesis framework and stakeholder narrative from a plain-language description. Use when a dashboard number drops or spikes unexpectedly. Triggers: 'investigate metric anomaly', 'my metric dropped', 'расследуй аномалию метрики', 'у меня упала метрика'.
SKILL.md
7.1 KB, as published. Nobody here has run it
Metrics Anomaly Investigator
This skill takes a plain-language description of a metric anomaly (metric name, time period, delta, and any available context) and produces a structured investigation framework with ranked hypotheses and a ready-to-send stakeholder narrative. No database access or code required — designed for product managers working in Cowork.
Input:
- Free-form description of the anomaly: metric name, observed period, magnitude of change, and any context (recent releases, campaigns, external events)
Output:
- Markdown response with Anomaly Summary, Investigation Framework table, Priority Checks, and Draft Stakeholder Narrative
Language Detection
Detect the user's language from their message:
- If Russian (or contains Cyrillic): respond in Russian
- If English (or other Latin-script language): respond in English
- If ambiguous: respond in the language of the trigger phrase used
Instructions
Step 1: Validate Input
-
Check that the user provided at minimum:
- A metric name (or description of what was measured)
- An observed change (delta, direction, or time period)
- If either is missing: stop and respond: "To investigate the anomaly I need at minimum: (1) metric name, (2) time period, (3) observed change. Please provide these details." Do not generate a framework.
-
If the input is vague (e.g., "our metrics are bad" with no specific anomaly):
- Ask the user to identify one specific metric and its observed change before proceeding.
-
Note what context is available:
- Recent product changes, feature releases, or experiments
- Marketing campaigns or traffic source changes
- Seasonality or external events
- Related metrics (correlated changes)
- If no context provided: proceed, flag assumptions explicitly in output, and add a closing line at the end of the response asking the user to share any recent product changes, campaigns, or external events that may be relevant.
Step 2: Classify the Anomaly
-
Determine the anomaly type:
- Direction: spike (unexpected increase) vs. drop (unexpected decrease)
- Shape: sharp (1–2 day change) vs. gradual (trend over days/weeks)
- Scope: isolated (single metric) vs. correlated (multiple metrics moving together)
-
If the user describes a gradual trend: note that short-term hypotheses (e.g., tracking bug, one-off event) are lower priority; focus on structural factors.
-
If multiple metrics changed simultaneously: reframe as a systemic investigation and add cross-metric hypotheses.
Step 3: Generate Investigation Framework
Generate 5–7 ranked hypotheses covering four investigation axes:
Axis 1 — Data / Tracking issues (always include, check first)
- Tracking code broken or missing on key pages
- Metric definition or aggregation logic changed
- Data pipeline delay or processing error
- Segment filter or attribution window changed
Axis 2 — Product changes
- Feature release or rollback in the relevant period
- A/B test or experiment affecting the metric
- UI change affecting user flow
- Pricing or access change
Axis 3 — External / Traffic factors
- Organic traffic source change (SEO, social, referral)
- Marketing campaign launched or paused
- Competitor action, press coverage, or viral event
- Platform algorithm change (App Store, Google, social)
Axis 4 — User behaviour shifts
- Seasonal pattern or day-of-week effect
- User cohort mix shift (new vs. returning users ratio)
- Device or geography mix change
- Onboarding or activation funnel change upstream
For each hypothesis:
- Assign likelihood: High / Medium / Low (based on context provided)
- Specify one concrete validation step
Step 4: Identify Priority Checks
- Select the top 2–3 hypotheses most consistent with the provided context.
- For each, write one sentence explaining why this is a priority given the specific anomaly described.
- If no context was provided: default priority order is Data/Tracking → Product changes → External factors → Behaviour shifts.
Step 5: Draft Stakeholder Narrative
Write a 5–8 sentence narrative in Slack/email format covering:
- What happened (metric, period, magnitude)
- Current status of investigation (just started / hypotheses identified / root cause found)
- Top hypotheses being checked
- Next steps and who is responsible (use placeholder [owner] if not specified)
- ETA for the next update
Edge Cases:
- If anomaly is a gradual trend (weeks): prioritise structural hypotheses (cohort mix, SEO, product flow); downweight single-event hypotheses.
- If multiple metrics changed: add a "Correlated pattern" note to the Anomaly Summary; include cross-metric hypotheses in the framework.
- If delta is small (<5%): note that significance depends on baseline variance; prioritise Data/Tracking hypotheses first.
- If no context provided: proceed with full hypothesis set and explicitly state "No context provided — all four axes are equally prioritised." At the end of the response, add: "To help narrow down the hypotheses, please share any recent product changes, campaigns, or external events that occurred around the time of the anomaly."
Negative Cases
- No metric name or delta: Do not generate a framework. Respond with a clear request for the minimum required information.
- Input is only "metrics are bad" or similarly vague: Ask the user to name one specific metric and its observed change before proceeding.
Output Format
## Anomaly Summary
- **Metric:** [metric name]
- **Period:** [time range]
- **Change:** [delta — e.g., "-23% vs. prior week"]
- **Type:** [spike / drop] — [sharp / gradual] — [isolated / correlated]
- **Context provided:** [summary of user-provided context, or "none"]
---
## Investigation Framework
| # | Hypothesis | Axis | Likelihood | How to validate |
|---|-----------|------|------------|-----------------|
| 1 | [hypothesis] | Data/Tracking | High | [specific check] |
| 2 | [hypothesis] | Product | Medium | [specific check] |
| 3 | [hypothesis] | External | Low | [specific check] |
| ... | | | | |
---
## Priority Checks
1. **[Hypothesis name]** — [1 sentence: why this is most consistent with the described anomaly]
2. **[Hypothesis name]** — [1 sentence rationale]
3. **[Hypothesis name]** — [1 sentence rationale]
---
## Draft Stakeholder Narrative
**To:** [channel / team]
**Status:** Investigating
We noticed [metric] [dropped/increased] by [delta] over [period]. We are currently investigating the root cause and have identified [N] hypotheses. The most likely causes are [top 2 hypotheses]. [Owner] is checking [specific validation steps] and we expect initial findings by [timeframe]. We will share an update by [date/time]. No action required from your side at this stage.