Flag metric anomalies against declared baselines while separating data faults, expected seasonality, and real business changes.
Instructions your experts follow when using this skill.
An anomaly is a signal that needs review, not proof of a problem or a cause.
Record the metric version, grain, eligible population, timezone, expected data delay, baseline window, known seasonality, and alert threshold. Use a rule the owner supplied or explain the proposed rule before applying it. Keep absolute and relative thresholds when low volumes can distort rates.
For every alert, test:
Compare against more than one useful baseline when available: prior period, same weekday or season, and a recent range. Do not use a model or threshold that you cannot explain in the report.
Give metric, observed and expected value, size of difference, affected period, sample, segment concentration, quality-check result, confidence, ranked hypotheses, and one disproof test per hypothesis. Mark status as data issue, expected pattern, possible business change, or unresolved.
Track alert status and owner. Do not close an alert because the metric returned to normal; record whether anyone found a cause.
Never label fraud, misconduct, or customer harm from an aggregate anomaly alone. Do not expose individual records unless an approved investigation needs them. Never hide a false positive or tune the rule after the event without recording the change.
Phrases that help your experts find this skill.
When the user wants to create or update their product marketing context document. Also use when the user mentions 'product context,' 'marketing context,' 'set up context,' 'positioning,' 'who is my target audience,' 'describe my product,' 'ICP,' 'ideal customer profile,' or wants to avoid repeating foundational information across marketing tasks. Use this at the start of any new project before using other marketing skills — it creates `.agents/product-marketing.md` that all other skills reference for product, audience, and positioning context.
When the user wants to research, profile, or analyze competitors from their URLs. Also use when the user mentions 'competitor profile,' 'competitor research,' 'competitor analysis,' 'profile this competitor,' 'analyze competitor,' 'competitive intelligence,' 'competitor deep dive,' 'who are my competitors,' 'competitor landscape,' 'competitor dossier,' 'competitive audit,' or 'research these competitors.' Input is a list of competitor URLs. Output is structured competitor profile markdown files. For creating comparison/alternative pages from profiles, see competitors. For sales-specific battle cards, see sales-enablement.
When the user wants to conduct, analyze, or synthesize customer research. Use when the user mentions "customer research," "ICP research," "talk to customers," "analyze transcripts," "customer interviews," "survey analysis," "support ticket analysis," "voice of customer," "VOC," "build personas," "customer personas," "jobs to be done," "JTBD," "what do customers say," "what are customers struggling with," "Reddit mining," "G2 reviews," "review mining," "digital watering holes," "community research," "forum research," "competitor reviews," "customer sentiment," "PMF survey," "product/market fit survey," "customer interview questions," "interview outreach," "Sales Safari," or "find out why customers churn/convert/buy." Use for analyzing existing research assets, mining online sources, AND running primary research (interviews and surveys). For writing copy informed by research, see copywriting. For acting on research to improve pages, see cro.