{"id":16274,"plugin_id":"plugin_asdk_app_6aa5672de100819198bb079e9546ee0e","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:07.403Z","digest":"278ca65bae4a86add34bf25b93244ac72e096f0f55fc06db2cdfc0173f3124c9","against":null,"payload":{"description":"Root-cause diagnosis for a drop or spike in Sealmetrics metrics. Trigger on: \"why did conversions drop\", \"why did sales fall\", \"traffic spiked, why\", \"what happened yesterday/this week\", \"qué ha pasado con\", \"revenue is down\", or any cause-seeking question about a metric change.\n","included_files":[{"relative_path":"examples/output.md","size_in_bytes":1932}],"name":"diagnose-drop","skill_md_contents":"---\nname: diagnose-drop\ndescription: >\n  Root-cause diagnosis for a drop or spike in Sealmetrics metrics. Trigger\n  on: \"why did conversions drop\", \"why did sales fall\", \"traffic spiked,\n  why\", \"what happened yesterday/this week\", \"qué ha pasado con\", \"revenue\n  is down\", or any cause-seeking question about a metric change.\nargument-hint: \"[metric] [period]\"\nshort-description: 'Root-cause diagnosis of a drop or spike. Use for \"why did conversions drop\", \"sales fell\", \"traffic spiked, why\", \"what happened this week\", \"qué ha pasado con\", \"revenue is down\".'\n---\n\n# Diagnose Drop (or Spike)\n\nBefore writing your answer, read `examples/output.md` in this skill directory\nand match its density, structure and tone. It is the reference for what a good\nrun of this skill looks like.\n\nIsolate the root cause of a metric change. Budget: ≤12 tool calls.\nFollow the cause hierarchy from\n`skills/seal-copilot/references/methodology.md` strictly — work down,\nstop at the first isolated cause.\n\n## Procedure\n\n0. Confirm the change: `get_overview` for the affected period with\n   `compare=previous`. Totals are under `traffic` / `conversions`; the delta\n   is `traffic_change` / `conversions_change`; the daily `*_series` show\n   exactly which day it broke. If the user's claim is not visible in data, say so\n   and show what you see instead.\n1. **Bots/tracking:** `get_bot_stats(days=30)`. Read it with the\n   three-outcome rule in `methodology.md` — an empty result means agent\n   analytics is off, not 0% bots. **When bots are the cause the diagnosis is\n   not finished until you have named the source.** Call `get_top_referrers`\n   yourself — a single referrer at 90%+ bounce is the usual shape — and put\n   its name in the cause statement. Do not tell the user to go and look:\n   \"it is bots\" is an observation, \"it is bots from cheap-traffic.example,\n   block it at the CDN\" is the finding they asked for. That call takes\n   priority over every optional one, including anything gathered only to fill\n   `profile.json`. Sudden near-zero on one page →\n   check `get_pages(path_filter=...)` for a tag lost in a deploy. For a\n   broken microconversion event (cart, checkout), compare\n   `get_microconversions(period=30d, compare=previous)` per type — a single type\n   collapsing while others hold is an instrumentation regression, not a\n   demand problem. Cross-reference the `cart-watchdog` baseline if AtC is\n   the affected metric.\n2. **Channel:** `get_top_channels(period=this_week)` vs\n   `get_top_channels(period=last_week)` (or the `this_month`/`last_month` pair for\n   a monthly drop) — `get_top_channels` has no `compare`, so diff the pair\n   yourself. All channels down evenly → jump to step 7.\n3. **Campaign:** `get_campaigns(compare=previous, utm_source/medium filters)`.\n4. **Landing/term:** `get_landing_pages(compare=previous)` and/or\n   `get_terms(compare=previous)` filtered to the campaign.\n5. **Device/country/browser:** `get_devices(compare=previous)` returns\n   `by_device`, `by_browser` and `by_os` in one response, each row with\n   `*_prev` twins — no separate browser or OS call needed. Add\n   `get_countries(compare=previous)`. A collapse isolated to Safari, or to\n   one iOS version, points at ITP or a rendering bug, not at demand.\n   Country is timezone-derived — treat a country-only signal as directional.\n6. **Product/SKU** (ecommerce only): if the drop concentrates on\n   purchases but channels look uniform, run `get_property_breakdown` on\n   the product identifier from `list_property_keys` for the affected vs\n   prior period — a single SKU going out of stock or losing a top\n   variant can move overall revenue noticeably.\n7. **Seasonality — addressed, never skipped.** Re-run `get_overview` with\n   `compare=yoy`: flat year over year means seasonal, so say so and stop. You\n   may skip that call **only** when the isolation itself excludes seasonality —\n   a single campaign or channel collapsed while its neighbours held flat, and\n   no season does that to one line and not the others. Then say which of the\n   two ruled it out. Seasonality does not get to go unmentioned because the\n   cause looked obvious.\n8. **Market-wide:** if nothing isolates, state it plainly.\n\n## Output format\n\nAll four sections are **mandatory**, in this order. A one-line summary is not\nan acceptable answer to this skill even when the cause is obvious: the user\ncannot act on \"it was campaign X\" without the evidence, the fix and the check.\n\n1. **Cause statement** — one sentence: \"The drop is isolated to [X]:\n   [numbers].\" State confidence (high/medium/low per sample size).\n2. **Evidence chain** — the 2–4 data points that led there, with numbers.\n3. **Action** — what to do about it, with estimated recovery impact.\n4. **Verification** — what to re-check and when. Never omit this. A diagnosis\n   the user cannot confirm in a week is an opinion, not a finding.\n\nDo not report how many tool calls you used. The budget is an internal\nconstraint on you, not information for the user.\n\nIf the change is a spike, validate bots first (rule 1) before celebrating.\nNever speculate beyond the data — if two causes remain plausible, present\nboth with their evidence.\n\n---\n\nLog the run in `<state-dir>/<site_id>/runs.jsonl` with exactly these fields\nand no others: `ts` (ISO timestamp, UTC), `skill`, `calls` (the number of\nSealmetrics calls you made, counted), `budget` (this skill's documented\nceiling, a number — `12` here), `verdict` (one of `on_track`, `watch`, `act`,\n`kpis_only`, `refused`, `error`, or the score for an audit), `scheduled`\n(boolean), `notes` (one line). The first real audit wrote `calls_used` and a\nfree-text verdict because this footer said \"calls used\" in prose; the field\nnames are the contract. Skip silently if the path is not writable.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}