# Evals: data-scraper

These cases are routing and coverage checks, not an automated pass/fail suite. Read `cases.yaml` against `SKILL.md`. For each `should_trigger` prompt, confirm the description and body would plausibly fire this skill rather than a sibling — note the two non-obvious symptom cases (429/IP-ban and selectors-break-on-redesign, which read as ops problems but are core here) and the Spanish and Catalan triggers. For each `should_not_trigger` prompt, confirm the named `route_to` sibling is the better home and that the boundary in the description would defer to it (structured-extraction once you hold bytes, api-connector-builder when an API exists, data-cleaning for normalization, e2e-testing for UI flow automation, gdpr-privacy for a pure lawful-basis question). For the `capability` case, have a human or a harness LLM produce the response and check it hits every `must_include` item — above all that it runs the legal gate first, walks the extraction path before reaching for a browser, paces per host with backoff and honors 429, uses a resumable queue, fails loud on missing fields, and refuses to bypass a CAPTCHA or hard block. There is no scripted assertion here. The separate `scripts/verify.sh` is the only automated check, and it statically lints an emitted scraper file for a compliance preflight, a rate limit/concurrency cap, retry/backoff, and the absence of CAPTCHA-solver / auth-bypass calls — not these cases.
