Update to Ubersuggest

{
  "description": "Crawl a site for technical SEO problems and report prioritised fixes with Core Web Vitals. Use when the user asks for a site audit, a technical SEO check, why their site is slow, whether their site has SEO errors, about broken links, missing titles or H1s, duplicate content, Core Web Vitals, PageSpeed or a health score.\n",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 646
    }
  ],
  "name": "site-audit",
  "skill_md_contents": "---\nname: site-audit\ndescription: >\n  Crawl a site for technical SEO problems and report prioritised fixes with\n  Core Web Vitals. Use when the user asks for a site audit, a technical SEO\n  check, why their site is slow, whether their site has SEO errors, about\n  broken links, missing titles or H1s, duplicate content, Core Web Vitals,\n  PageSpeed or a health score.\nargument-hint: \"<domain>\"\n---\n\n# Site audit\n\n**Input:** `$ARGUMENTS` — the domain to crawl. If that placeholder is empty or\nstill literal, take the domain from what the user asked; if they named none, ask\nwhich domain.\n\n## Before you start: this needs a login\n\n`site_audit`, `site_audit_status`, `site_audit_results` and `site_audit_pages`\nall require an authenticated Ubersuggest account. **Call `auth_status` first.**\n\nIf the user is not logged in: tell them the crawl needs a connected Ubersuggest\naccount, ask for the connection, then offer `pagespeed_audit` — it is *not*\nlogin-gated and still delivers Core Web Vitals for the domain. Do not fire the\naudit tools just to surface a raw auth error, and do not stand in for the crawl\nby fetching pages yourself: a crawl of 340 pages is not something you can eyeball.\n\n## Steps\n\n1. **Validate the domain.** `validate_site` if the input is at all doubtful.\n   Pass the root domain (`example.com`). To audit a single page instead, pass\n   the domain plus the page path in `path` — and then use that same `path` in\n   *every* subsequent call.\n\n2. **Start the crawl.** `site_audit` with the domain. `crawlMaxPages` defaults\n   to 150 (free tier); pass a higher value only if the user's plan allows it.\n   Use `recrawl: true` only when the user explicitly wants fresh data — it\n   bypasses the cache and costs a full crawl.\n\n3. **Poll until done.** `site_audit_status` with the *same* `domain`, `path` and\n   `crawlMaxPages` you passed in step 2 — mismatched arguments look up a\n   different report. Watch two fields:\n   - `result.done` — `false` while crawling, `true` when the report is ready.\n   - `result.status` — `'no_errors'` on success; **any other value means the\n     crawl failed**, so stop and report it rather than polling on.\n\n   Wait several seconds between polls and **cap at ~10 attempts**. If it is\n   still crawling, hand over the partial report (the payload is populated while\n   crawling) and say the crawl had not finished.\n\n4. **Read the issue breakdown.** The finished report gives:\n   - `overview` — health score and totals.\n   - `issues_per_category` — `{errors, warnings, recommendations}`, each with\n     issue **ids** and counts.\n\n5. **Drill into what matters.** `site_audit_results` with the domain and an\n   `issue` id. The id must come from `issues_per_category` (e.g.\n   `seo_missing_h1`) — it is not a free-text label, so never invent one. Pull\n   the top 3–6 issues by impact, not all of them. Each call returns the\n   affected URLs with issue-specific detail.\n\n6. **Add performance.** `pagespeed_audit` for Core Web Vitals. Pass `devices`\n   if the user cares specifically about mobile or desktop; mobile is the more\n   common problem. This is async — poll within the same cap.\n\n7. **Optional inventory.** `site_audit_pages` lists every crawled URL. Only\n   worth pulling if the user asks what was crawled or suspects pages are\n   missing from the crawl.\n\n## Prioritising the findings\n\nDo not dump the issue list. Rank by real impact:\n\n1. **Blocks indexing** — noindex in production, robots.txt blocks, broken\n   canonicals, 5xx. Nothing else matters until these are clear.\n2. **Breaks pages or links** — 4xx, broken internal links, redirect chains.\n3. **Costs rankings at scale** — missing/duplicate titles and meta\n   descriptions, missing H1s, thin or duplicate content, especially where the\n   affected count is high.\n4. **Core Web Vitals** — poor LCP or CLS, worst on mobile.\n5. **Hygiene** — image alt text, minor markup issues. Batch them in one line.\n\nWeight each by how many URLs it hits: one missing H1 is noise, 400 missing H1s\nis a template bug and a top finding.\n\n## Deliverable\n\n- **Health score** and totals (errors / warnings / recommendations), plus the\n  page count crawled.\n- **Top findings table:**\n\n| # | Issue | Severity | Pages affected | Why it matters | Fix |\n| --- | --- | --- | --- | --- | --- |\n\n- **Core Web Vitals** — LCP, CLS, INP per device, with pass/fail read out.\n- **Fix order** — a short numbered list, quick wins first, calling out anything\n  that is one template change fixing hundreds of URLs.\n- Example URLs for each finding, so the user can verify it themselves.\n\n## When something fails\n\n- `result.status` is not `'no_errors'` → the crawl failed. Report the status\n  value; do not present partial data as a completed audit.\n- Poll cap reached with `done: false` → deliver the partial report, labelled as\n  partial.\n- Not logged in → the fallback in *Before you start*.\n- Quota / plan error → say which limit was hit and that the crawl did not run.\n"
}