{"id":16268,"plugin_id":"plugin_asdk_app_6aa5672de100819198bb079e9546ee0e","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:07.301Z","digest":"cd804781aea1ecf03bd4b67fd70986e82e8af4c43d3bfd1b5d46751d7e533b15","against":null,"payload":{"description":"Intraday watchdog for add-to-cart activity. Detects unusual silence or spikes vs the site's own learned hour-of-week baseline (not a fixed threshold) and rules out bots before alerting. Requires a baseline from the `calibrate-watchdog` skill. Trigger on: \"is my cart alive\", \"check add to cart\", \"carrito parado\", \"cart watchdog\", \"no estamos vendiendo\", \"intraday alert\", \"checkout watchdog\", or when run from a scheduled task. For hotels, substitutes `booking_start` for `add_to_cart`.\n","included_files":[{"relative_path":"examples/output.md","size_in_bytes":1192}],"name":"cart-watchdog","skill_md_contents":"---\nname: cart-watchdog\ndescription: >\n  Intraday watchdog for add-to-cart activity. Detects unusual silence or\n  spikes vs the site's own learned hour-of-week baseline (not a fixed\n  threshold) and rules out bots before alerting. Requires a baseline from the\n  `calibrate-watchdog` skill. Trigger on: \"is my cart alive\", \"check add to\n  cart\", \"carrito parado\", \"cart watchdog\", \"no estamos vendiendo\", \"intraday\n  alert\", \"checkout watchdog\", or when run from a scheduled task. For hotels,\n  substitutes `booking_start` for `add_to_cart`.\ndisable-model-invocation: true\nshort-description: 'Intraday check of add-to-cart against the learned baseline. Silent when healthy. Use for \"check the cart\", \"is the cart working\", \"cómo va el carrito\", or hourly runs.'\n---\n\n# Cart Watchdog\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\nCatch live problems — broken AtC button, payment outage, tracking gap —\nbefore the daily report does. Budget: ≤6 tool calls. Designed for\n**scheduled execution**, hourly during business hours.\n\n## Step 0 — Load the baseline\n\nRead `<state-dir>/<site_id>/watchdog-baseline.json`.\n\n- **No file** → do not improvise a threshold. Reply in one line: *\"No baseline\n  yet — run `calibrate-watchdog` once and I can watch this properly.\"* Stop.\n- **Expired** (`expires_at` in the past) → still run, but prefix the status\n  with \"baseline stale, recalibrate\" and widen every threshold by half.\n- **Mode C** (daily-only baseline) → skip the hourly logic below and judge on\n  the day-to-date total alone. Say that hour-level detail is unavailable.\n\nThe file also carries `last_status` from the previous run. You need it: a 🔴\nrequires two consecutive bad checks, and this is the only way to know about\nthe previous one.\n\n## Step 1 — Today's volume so far (1 call)\n\n`get_microconversions(conversion_type=<event>, period=today)`\n\nThis returns the day total, not an hourly series. Compare it against the\nbaseline's `cumulative[day_of_week][current_hour]` — the expected count for\nthe hours elapsed so far today, in the site's timezone.\n\n**Status from the ratio** `actual / expected_to_date`:\n\n- 🟢 **Healthy** — ratio ≥ 0.5\n- ⚠️ **Watch** — ratio between 0.2 and 0.5\n- 🔴 **Act** — ratio < 0.2 **and** `last_status` was already ⚠️ or 🔴\n\nA single low reading is never 🔴 on its own. Two consecutive are.\n\nFor spikes, mirror it: ratio ≥ 3 is 🔴 (likely bots), ≥ 2 is ⚠️.\n\n**Quiet cells are not incidents.** If the sum of medians for the elapsed\nhours is below 5 events, there is not enough signal — report 🟢 and say the\nwindow is too quiet to judge.\n\n## Step 2 — Locate the silence (1–2 calls, only if not 🟢)\n\n`get_microconversions_raw(conversion_type=[<event>], period=today, limit=100)`\n\nRows carry `hour` (local, 0–23) and `timestamp_local`. Use `hour` to bucket\nand `timestamp_local` for the most recent event. Page once more only if the\nfirst page does not contain the latest activity.\n\nTwo extra signals from this:\n\n- **Time since last event** vs the current cell's `gap`: more than 2× gap\n  supports ⚠️, more than 3× gap supports 🔴.\n- **When the drop started** — the last hour with normal-looking volume is the\n  incident start time. Name it; it is what the user needs to match against\n  their deploy log.\n\n## Step 3 — Rule out bots (1 call, mandatory before any 🔴)\n\n`get_bot_stats(days=1)`\n\n- Drop coinciding with a bot spike → the drop is real but the metric was\n  previously inflated. Say so and recommend recalibrating.\n- Spike that is bots → demote 🔴 to ⚠️ \"bot inflation\" and explain.\n- **Empty result** → agent analytics is off, not 0% bots. Keep the status but\n  mark it \"unvalidated for bots\" (see `methodology.md`).\n\n## Step 4 — Isolate the cause (≤2 calls, only if 🔴)\n\nOne call is enough — `get_microconversion_details(conversion_type=<event>,\nperiod=today)` returns `by_device`, `by_source`, `by_country` and\n`by_landing_page` together, each with `count` and `percentage`. Compare the\ndevice and source splits against the baseline's usual mix.\n\nMobile-only drop after a deploy → tracking probably broken on the mobile\nbuild. One-source drop with no other anomalies → that source paused or\nblocked. Uniform drop → payment or cart outage; tell the user to test\nmanually now.\n\n## Step 5 — Persist the status\n\nWrite `last_status` and the check timestamp back into the baseline file so the\nnext run can apply the two-consecutive-checks rule. If the file is not\nwritable, say once that consecutive-check escalation is unavailable.\n\n## Output format\n\n**One status line first:** `🟢 Healthy` / `⚠️ Watch — <reason>` / `🔴 Act\nnow — <reason>`.\n\nIf 🟢 and the run is scheduled: that single line is the entire response.\nDo not pad. Silence on a healthy run is correct.\n\nIf ⚠️ or 🔴: add the evidence (today's count vs expected-to-date, time since\nlast event), the incident start time, the suspected cause from Step 4, and\none concrete action — e.g. \"open a product page on mobile and try to add to\ncart now\".\n\n## Scheduling guidance\n\nRecommend hourly during business hours: *\"Run cart-watchdog every hour from\n8 am to midnight in [site timezone].\"* The skill is silent when healthy, so\nit will not become noise. Offer the schedule once, after a successful run.\n\n## What you do NOT do\n\n- Do not run without a baseline. Recommend `calibrate-watchdog` instead.\n- Do not alert on a single quiet hour. Two consecutive checks, or nothing.\n- Do not rebuild the baseline here — that is `calibrate-watchdog`'s job and it\n  costs up to 40 calls.\n- Do not page the user during scheduled night hours unless they opted in.\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 — `6` 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":{}}