{"id":66322,"plugin_id":"plugin_asdk_app_6a258ab1e0908191aa647c33299ad14c","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-28T12:05:39.399Z","digest":"469fa2dac62a807d8caf8d04c95115b7b920d1487d8ac7d130c57f34c83b0af2","against":null,"payload":{"description":"Quiet daily or weekly health check for one Search Console property, built to run unattended from a scheduler with the GSC Wizard MCP tools and a read-only connection. Scans clicks and impressions for severe anomalies and downward level shifts, compares the last settled week with the one before, checks the indexing tracker for lost pages, and overlaps findings with Google updates. Stays silent with one fixed line unless a threshold is crossed, then reports the dated finding, cause class and next skill to run. Use when the user asks \"check my site for anomalies\", \"anything wrong today\", \"daily SEO check\", \"monitor my property\", or sets up a scheduled check.","included_files":[],"name":"anomaly-check","skill_md_contents":"---\nname: anomaly-check\ndescription: Quiet daily or weekly health check for one Search Console property, built to run unattended from a scheduler with the GSC Wizard MCP tools and a read-only connection. Scans clicks and impressions for severe anomalies and downward level shifts, compares the last settled week with the one before, checks the indexing tracker for lost pages, and overlaps findings with Google updates. Stays silent with one fixed line unless a threshold is crossed, then reports the dated finding, cause class and next skill to run. Use when the user asks \"check my site for anomalies\", \"anything wrong today\", \"daily SEO check\", \"monitor my property\", or sets up a scheduled check.\n---\n\n# Anomaly Check\n\nRun a quiet health check on one property and speak only when something needs a human. It is meant for a scheduler: it calls no write tool, works with a read-only connection, and its quiet-case reply is one fixed line so a log stays readable. The user's request may contain a property (or several, checked one after another with the same rules), a cadence (daily or weekly; daily is the default) and a metric to focus on; nothing else is needed.\n\n## Workflow\n\n1. **Resolve the property.** If the user's request or the conversation names a property, use it. Site URLs use GSC formats: `sc-domain:example.com` or `https://www.example.com/`. Otherwise call `list_sites` and pick the obvious match. If several plausible properties exist, ask the user which one before continuing; a scheduled run with no clear match reports that as its finding. GSC data lags about 2 to 3 days: the tools end at the latest settled date, so the check window is the last 7 settled days for a daily run and the last 14 for a weekly one; never treat the most recent 2 days as complete.\n\n2. **Single-day anomalies.** Call `detect_anomalies` with `metric: \"clicks\"`, `days: 28` (minimum 21) and the default `sensitivity` (3.5; the range is 2 to 6 and lower finds more). Repeat with `metric: \"impressions\"`.\n   - Keep only `anomalies` whose `date` falls inside the check window; read `severity` (`critical`, `high`, `medium`, `low`, `info`), `direction` (`up` or `down`), `actual`, `expected` and `deviationPercent`.\n   - `summary` carries the counts per severity. `coverage.zeroFilledDays` says how many days had no rows at all; a drop to zero is flagged, which is also what a data gap looks like.\n\n3. **Level shift.** Call `detect_change_points` with `metric: \"clicks\"`, `days: 60` and the default `sensitivity` of 2.\n   - Read `changePoints` (`date`, `direction`, `beforeMean`, `afterMean`, `changePercent`) and keep entries dated within the last 14 days.\n   - When `count` is 0, `trendSummary.direction` and `trendSummary.ratio` describe the slope. A gradual slide is not a finding for this check, but mention it in a weekly run when `ratio` is below 0.8.\n\n4. **Week over week.** Call `get_site_summary` with `days: 7` (`days: 14` for a weekly run).\n   - Compare `current` with `previous` on `clicks` and `impressions`; derive the percentage change yourself and say so.\n   - `ctr` is already a percentage on a 0-100 scale, never multiply it by 100; `avgPosition` is lower-is-better, so a move toward a lower number is an improvement.\n\n5. **Lost pages.** Call `get_indexing_tracker_report` with `days: 7` (`days: 14` weekly; max 90).\n   - `configured: false` means no tracker exists for the property: skip this signal without comment.\n   - Otherwise read `lostPagesTotal`, the first entries of `lostPages` (`url`, `changedAt`, `coverageState`) and `healthScore`; a failed check is not counted as a lost page, so the figure is conservative.\n\n6. **Context, not a trigger.** Call `list_algo_updates` with `startDate` 21 days ago.\n   - An entry in `updates` whose `beginISO` to `endISO` span overlaps a fired signal is its likely cause class.\n   - An update on its own, with nothing else firing, stays quiet; an empty list is not proof that nothing changed, since only confirmed updates are listed.\n\n## Thresholds\n\nReport when any row below is true; otherwise stay quiet. Judge by volume as well: when `previous.clicks` from `get_site_summary` is under 100, the percentage rules fire only at twice the stated size, because small numbers swing on their own.\n\n| Signal | Tool | Report when | Stay quiet when |\n|---|---|---|---|\n| Day anomaly | `detect_anomalies` | `severity` is `critical` or `high` with `direction` `down`; or `critical` with `direction` `up` (a spike to verify) | `medium` and below; an anomaly only on the newest 2 settled days (likely lag) unless it is `critical` |\n| Level shift | `detect_change_points` | `direction` `down`, dated in the last 14 days, `changePercent` at or below -15 | `direction` `up`; older breaks; no change point |\n| Week over week | `get_site_summary` | `clicks` or `impressions` down 20% or more against `previous` | smaller moves, or a gain |\n| Lost pages | `get_indexing_tracker_report` | `lostPagesTotal` of 1 or more | 0, or `configured: false` |\n\n## Output\n\nQuiet case: reply with exactly this one line and nothing else, filling in the property and the check window's first and last date:\n\n`All clear for <siteUrl> (<first date> to <last date>): no signal crossed the reporting threshold.`\n\nDo not add a greeting, a summary of what was checked, or a table to the quiet reply; that line is the whole message, so a scheduler can match it.\n\nWhen something fires, keep the reply under 15 lines and give, in this order:\n\n1. One dated sentence per fired signal with the tool, the dates and the numbers, for example \"clicks 412 against an expected 980 on 2026-10-13, severity high (`detect_anomalies`, 2026-09-16 to 2026-10-13)\". Present several fired signals as a compact markdown table rather than a list:\n\n   | Signal | Date(s) | Numbers | Tool |\n   |---|---|---|---|\n\n   Do not fabricate rows the tools did not return.\n2. The likely cause class, one of: reporting lag or data gap (the anomaly sits on the newest days, or `zeroFilledDays` grew), Google update (an overlap from `list_algo_updates`), deindexing (lost tracked pages), or site change or ranking loss (none of the above fits).\n3. The next skill to run: traffic-drop for a fall in clicks or impressions, indexing-health for lost pages, weekly-report when the move is small but the user wants the full picture.\n\nNever call a write tool from this skill, and never log an annotation on the user's behalf; a scheduled run has nobody to confirm it.\n\n## Error handling\n\nIf any tool call fails with an authentication or subscription error, tell the user to reconnect the GSC Wizard app from their app or connector settings, and that a GSC Wizard account with an active plan or trial plus a connected Google Search Console account is required. If the property is not found, re-run `list_sites` and offer the closest matches instead of guessing a URL format. If a single tool fails for another reason, report the gap in the relevant section and complete the rest of the workflow with the remaining data.\n\n## Grounding\n\nEvery number you report must name the tool it came from and the date range it covers, for example \"clicks 12,340 (`get_site_summary`, 2026-09-21 to 2026-09-27)\". For a table, state the tool and date range once on the line above it. If you derive a figure yourself (a delta, a sum, a share), say so and name the tool outputs it was computed from. Never report a number no tool returned.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}