seo 0.1.0 → 0.2.0

package/evals/redirect-trace.json

@@ -0,0 +1,57 @@
+{
+  "subject": "redirect-trace",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "This old URL bounces around before it lands somewhere. Can you trace where it ends up?",
+      "expected_output": "Should route to report id redirect-trace, which follows every redirect hop and checks the final page, indexability, and canonical signals. Should follow the discovery flow: seo_list_reports with category monitoring, seo_describe_report with id redirect-trace, then seo_run_report with a url. Should read the chain in order with requested URL, status, Location, resolved next, and duration first, then finalUrl versus finalPage and summary.finalStatus, then summary.issues, then metaRobots, xRobotsTag, canonical, and warnings.",
+      "assertions": [
+        "Uses report id redirect-trace to follow the redirect chain",
+        "Follows seo_list_reports, seo_describe_report, seo_run_report in order",
+        "Reads the chain in order with status, Location, and resolved next first",
+        "Reads finalUrl versus finalPage and summary.finalStatus",
+        "Reads summary.issues before drawing conclusions",
+        "Reads metaRobots, xRobotsTag, and canonical last"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Agent task: trace https://example.com/old with up to 10 hops, a fresh fetch, and JavaScript rendering.",
+      "expected_output": "Should run report id redirect-trace with url https://example.com/old, maxHops 10, refresh true, and js true, via seo reports run redirect-trace or seo_run_report. Should use only url, maxHops, refresh, and js from the schema. Should note that JavaScript rendering affects final-page extraction, not the HTTP chain.",
+      "assertions": [
+        "Runs report id redirect-trace with maxHops 10, refresh true, and js true",
+        "Uses only parameters defined in the redirect-trace schema",
+        "States JavaScript rendering affects final-page extraction, not the HTTP chain",
+        "Reads the chain before the final page checks"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "It is a 302, so that is a broken redirect, and it proves every visitor gets sent there.",
+      "expected_output": "Should refuse both claims. A 302 can be intentional. The trace is one observation from the machine and time that ran it, and CDNs, geography, cookies, or later deploys can differ, so it does not prove every visitor is routed the same way. Should keep the observation distinct from a defect and recommend re-running the trace after deployment to confirm the intended destination and status.",
+      "assertions": [
+        "Refuses to call the 302 a broken redirect on its own",
+        "States a 302 can be intentional",
+        "States the trace is one observation and CDNs, geography, or cookies can differ",
+        "Refuses to claim every visitor is routed the same way",
+        "Recommends re-running the trace after deployment to confirm"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Turn on JS rendering to fix the redirect chain, and since there is a canonical pointing elsewhere the whole redirect is wrong.",
+      "expected_output": "Should refuse both points. JavaScript rendering affects final-page extraction, not the HTTP chain, so it cannot fix the chain. A canonical elsewhere can be intentional. Should keep the HTTP chain distinct from final-page extraction and treat the canonical as an observation until intent or contradictory evidence makes it a defect.",
+      "assertions": [
+        "States JavaScript rendering does not change the HTTP redirect chain",
+        "Refuses to treat JS rendering as a fix for the chain",
+        "States a canonical pointing elsewhere can be intentional",
+        "Keeps the HTTP chain distinct from final-page extraction",
+        "Treats the canonical as an observation rather than an automatic defect"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/refresh-priorities.json

@@ -0,0 +1,57 @@
+{
+  "subject": "refresh-priorities",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Which existing pages should we refresh first?",
+      "expected_output": "Should use report id refresh-priorities to combine search declines and near-term opportunities into a ranked content review queue. Should follow the discovery flow: seo_list_reports with category workflows, seo_describe_report with id refresh-priorities, then seo_run_report with the required site. Should read the workflow steps and skipped states first, then per-item source, impactKind, score breakdown, date window, completeness, verification status, and rationale. Should clarify the score is not a traffic forecast.",
+      "assertions": [
+        "Uses report id refresh-priorities for the ranked review queue",
+        "Follows seo_list_reports, seo_describe_report, seo_run_report in order",
+        "Reads the workflow steps and skipped states first",
+        "Reads per-item source, impactKind, score breakdown, verification status, and rationale",
+        "States the score is not a traffic forecast"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Run refresh priorities for sc-domain:example.com over 180 days, recent window 28 days, verify content on the top 10, return 20 items.",
+      "expected_output": "Should run report id refresh-priorities with site sc-domain:example.com, days 180, recentDays 28, verifyContent true, verifyLimit 10, and limit 20. Should read per-item impactKind, score breakdown, and verification status, and treat the click decline, low CTR, second-page position, and GA4 session signals as having different semantics, not interchangeable. Should use only parameters defined in the schema.",
+      "assertions": [
+        "Runs report id refresh-priorities with days 180 and recentDays 28",
+        "Sets verifyContent true, verifyLimit 10, and limit 20 as requested",
+        "Reads per-item impactKind, score breakdown, and verification status",
+        "Treats the different signal types as not interchangeable",
+        "Uses only parameters defined in the report schema"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Rank by score and treat it as the extra clicks we will get, and remember the GA4 signal and the CTR signal mean the same thing.",
+      "expected_output": "Should refuse both moves. Should state the score is not expected clicks, revenue, ranking lift, or causal confidence, and that a click decline, low CTR, second-page position, and GA4 session signal have different semantics and are not interchangeable. Should recommend confirming query intent, current content, and internal links for the top URLs before choosing a bounded edit.",
+      "assertions": [
+        "Refuses to read the score as extra clicks",
+        "States the score is not expected clicks, revenue, ranking lift, or causal confidence",
+        "States the signal types have different semantics and are not interchangeable",
+        "Recommends confirming query intent, current content, and internal links for the top URLs",
+        "Frames the next step as a bounded edit, not an automatic one"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "GA4 was not connected on this run, so those pages have zero sessions and should rank lowest in the queue.",
+      "expected_output": "Should refuse to treat missing GA4 as zero. Should state missing GA4 or failed fetches stay unavailable, not zero-weight proof, and read the workflow skipped states and per-item completeness and verification status. Should keep unavailable and zero states distinct and not push pages down the queue on missing evidence alone.",
+      "assertions": [
+        "Refuses to treat missing GA4 as zero sessions",
+        "States missing GA4 or failed fetches stay unavailable, not zero-weight proof",
+        "Reads the workflow skipped states and per-item completeness and verification status",
+        "Keeps unavailable and zero states distinct",
+        "Does not push pages down the queue on missing evidence alone"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/search-performance-overview.json

@@ -0,0 +1,86 @@
+{
+  "subject": "search-performance-overview",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We just connected Search Console for a new property. Where should we even start looking?",
+      "expected_output": "Should treat search-performance-overview as the best first report for a newly connected property and run it before any focused report. Should follow the discovery flow: seo_list_reports with category workflows, seo_describe_report with id search-performance-overview, then seo_run_report with only schema-valid params. Should read the workflow envelope first, including workflow, site, summary, steps, actions, and output, then each report's dataStatus and skipped sections. Should use the report to point at the focused report to run next rather than asking this workflow for a larger payload.",
+      "assertions": [
+        "Uses search-performance-overview as the first report for a new property",
+        "Follows seo_list_reports then seo_describe_report then seo_run_report in order",
+        "Reads the workflow envelope (workflow, site, summary, steps, actions, output) first",
+        "Checks each report's dataStatus and skipped sections",
+        "Plans to run a focused report next rather than enlarging this payload",
+        "Passes only schema-valid parameters"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Agent task: run the overview for sc-domain:example.com over 90 days with a 7 day recent window, top 10 items, brand excluded. Return JSON.",
+      "expected_output": "Should run report id search-performance-overview via seo reports run search-performance-overview --params or seo_run_report with params site sc-domain:example.com, days 90, recentDays 7, limit 10, includeBrand false. Should note that days sets the main evidence window, recentDays sets the recent comparison period, and limit caps returned items without increasing provider coverage. Should return the structuredContent contract and preserve dataStatus, partial reasons, and evidence references.",
+      "assertions": [
+        "Runs report id search-performance-overview with days 90 and recentDays 7",
+        "Sets limit 10 and includeBrand false as requested",
+        "Explains days is the main window and recentDays is the recent comparison",
+        "Notes limit caps returned items and does not increase provider coverage",
+        "Returns structuredContent and preserves dataStatus and evidence references",
+        "Uses only parameters defined in the report schema"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "The overview shows clicks down and a Google update in the same window. Tell me the update caused the drop and how many clicks we'll recover if we act.",
+      "expected_output": "Should refuse both the causation claim and the recovery forecast. Should explain that update overlap, opportunity scores, average position, and timing are investigation signals, not causation or forecasts. Should recommend confirming affected URLs, provider dates, selection limits, and intentional technical controls before concluding, and should run a focused report such as update-correlation to inspect the overlap rather than asserting cause. Should not produce a click recovery number.",
+      "assertions": [
+        "Refuses to state the update caused the drop",
+        "Refuses to forecast how many clicks will be recovered",
+        "Labels update overlap and timing as investigation signals, not causation",
+        "Recommends confirming affected URLs, provider dates, and intentional controls first",
+        "Points to a focused report like update-correlation to inspect the overlap",
+        "Does not invent a recovery figure"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "The summary section looks totally healthy, so we're fine across the board this quarter, correct?",
+      "expected_output": "Should not let one complete section imply a sitewide all-clear. Should check each step's own status and evidence, since a failed or capped neighbour can sit beside a complete section. Should inspect dataStatus, skipped sections, and partial reasons before agreeing anything is fine. Should name any partial, capped, or skipped evidence rather than generalizing from the healthy summary.",
+      "assertions": [
+        "Refuses to generalize a healthy summary into a sitewide all-clear",
+        "Checks each step's own status and evidence",
+        "Notes a failed or capped neighbour can sit beside a complete section",
+        "Inspects dataStatus, skipped sections, and partial reasons",
+        "Names any partial, capped, or skipped evidence before concluding"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Can you just have this overview return every query and page and all the striking-distance and cannibalisation detail in one giant response?",
+      "expected_output": "Should decline to enlarge the workflow payload and instead run a focused report to inspect detail. Should explain the overview points to the focused report that verifies each issue, and that limit caps items without increasing provider coverage. Should name the focused reports for the requested detail, such as report id striking-distance, rather than expanding this broad workflow. Should keep the overview bounded.",
+      "assertions": [
+        "Declines to expand the overview into one large payload",
+        "Recommends running a focused report for the detail instead",
+        "Names report id striking-distance for the near-page-one detail",
+        "Explains limit caps items and does not increase provider coverage",
+        "Keeps the workflow output bounded"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "The report flags a decaying page. Push a rewrite of it to the top of the list right now.",
+      "expected_output": "Should treat the decay signal as an investigation signal and confirm the evidence before acting. Should confirm affected URLs, provider dates, selection limits, and intentional technical controls such as noindex or canonicals before recommending a rewrite. Should suggest running a focused report like decaying-pages to inspect the detail. Should not present the decay flag as a proven cause or as justification for an immediate rewrite.",
+      "assertions": [
+        "Treats the decay flag as an investigation signal, not a proven cause",
+        "Confirms affected URLs, provider dates, and selection limits first",
+        "Checks for intentional controls like noindex or canonicals before acting",
+        "Suggests a focused report such as decaying-pages for the detail",
+        "Does not rush a rewrite from the flag alone"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/second-page.json

@@ -0,0 +1,58 @@
+{
+  "subject": "second-page",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Which of our pages are just barely off page one?",
+      "expected_output": "Should route to report id second-page, which finds URLs averaging positions 11 to 20 with the queries behind each one. Should follow the discovery flow: seo_list_reports with category reporting, seo_describe_report with id second-page, then seo_run_report with only schema-valid params. Should read source completeness, date range, selection, methodology, provenance, and brand filtering first, then per-item impressions, clicks, CTR, and average position, then the priority value. Should note average position is aggregated, not an exact rank.",
+      "assertions": [
+        "Uses report id second-page for the positions 11 to 20 review",
+        "Follows seo_list_reports, seo_describe_report, seo_run_report in order",
+        "Reads source completeness, date range, and selection before the rows",
+        "Reads per-item impressions, clicks, CTR, and average position",
+        "States average position is aggregated and not an exact rank",
+        "Reads the priority value last"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Agent task: run second-page for sc-domain:example.com over a 90 day range, at least 200 impressions, top 25 URLs, brand excluded.",
+      "expected_output": "Should run report id second-page with site sc-domain:example.com, range 90, minImpressions 200, limit 25, and includeBrand false, via seo reports run second-page or seo_run_report. Should keep params within the schema bounds, where range allows up to 548 and limit up to 100. Should note limit caps the retained rows and does not increase provider coverage, so the output is not a complete inventory.",
+      "assertions": [
+        "Runs report id second-page with range 90 and minImpressions 200",
+        "Sets limit 25 and includeBrand false as requested",
+        "Keeps range and limit within the schema bounds",
+        "Notes limit caps retained rows and does not increase provider coverage",
+        "States the output is not a complete inventory"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Add up the priority values, that is how many extra clicks we will get, and any URL sharing a query with another is cannibalisation, right?",
+      "expected_output": "Should refuse both claims. Priority is a transparent heuristic, not expected click lift, so it must not be totalled into a promised click gain. One row is not cannibalisation. Should point to report id cannibalisation to check query and URL overlap rather than inferring it from a single row here.",
+      "assertions": [
+        "States priority is a transparent heuristic, not expected click lift",
+        "Refuses to total priority values into a promised click gain",
+        "States one row is not cannibalisation",
+        "Points to report id cannibalisation to check query and URL overlap",
+        "Does not present a total extra clicks figure"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "This URL sits at position 12, so we are locked at number 12 for that query. Just drop the exact phrase into the title to jump to number 1.",
+      "expected_output": "Should decline the framing. Average position is aggregated across searches, locations, devices, and time and is not an exact or locked rank, and retained limits mean the output is not a complete inventory. Should recommend inspecting the live page and search intent and confirming the query suits the URL before one defensible change, rather than forcing the exact phrase into the title.",
+      "assertions": [
+        "States average position 12 is not an exact or locked rank",
+        "Notes average position is aggregated across searches, locations, devices, and time",
+        "Declines to force the exact query phrase into the title",
+        "Recommends inspecting the live page and intent before one defensible change",
+        "Notes retained limits mean the output is not a complete inventory"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/segment-impact.json

@@ -0,0 +1,57 @@
+{
+  "subject": "segment-impact",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Traffic dropped. Is it the whole site or just one section?",
+      "expected_output": "Should route to report id segment-impact, which compares page or query groups across equal periods to find which parts of a site moved. Should follow the discovery flow: seo_list_reports with category diagnosis, seo_describe_report with id segment-impact, then seo_run_report with site. Should read before, after, and rangeDays first, then dataStatus and source.before, source.after, and completeness for caps and truncation, then the selection counts, then per-item clickDelta, impressionDelta, and positionDelta and unmatchedSegments. Should recommend confirming the movement first with report id traffic-anomaly.",
+      "assertions": [
+        "Uses report id segment-impact to locate where movement sits",
+        "Follows seo_list_reports, seo_describe_report, seo_run_report in order",
+        "Reads before, after, and rangeDays first",
+        "Reads dataStatus and source completeness for caps and truncation",
+        "Reads per-item clickDelta, impressionDelta, and positionDelta",
+        "Recommends confirming movement first with report id traffic-anomaly"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Agent task: run segment-impact for sc-domain:example.com by page over 90 days against the prior 90 days, top 25 segments.",
+      "expected_output": "Should run report id segment-impact with site sc-domain:example.com, dimension page, days 90, compareDays 90, and limit 25, via seo reports run segment-impact or seo_run_report. Should keep params within the schema bounds, where days and compareDays allow up to 240 and limit up to 100. Should read the selection invalid, duplicate, conflicting, matched, unmatched, returned, and limited counts before ranking movers.",
+      "assertions": [
+        "Runs report id segment-impact with dimension page, days 90, and compareDays 90",
+        "Sets limit 25 as requested",
+        "Keeps days, compareDays, and limit within the schema bounds",
+        "Reads the selection matched, unmatched, and limited counts before ranking",
+        "Uses only parameters defined in the segment-impact schema"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "This segment has a positive positionDelta, so it improved. Promote it as a win.",
+      "expected_output": "Should refuse. A positive positionDelta is worse because a larger average position is lower in results. Should read the direction correctly and note that a limited or truncated result cannot support an inventory-wide winner or loser. Should recommend auditing the top matched movers before drawing a conclusion.",
+      "assertions": [
+        "Refuses to call a positive positionDelta an improvement",
+        "States a larger average position is lower in results",
+        "States a limited or truncated result cannot support an inventory-wide winner or loser",
+        "Recommends auditing the top matched movers before concluding"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "These unmatched segments dropped to zero clicks. Count them as total losses.",
+      "expected_output": "Should refuse. unmatchedSegments are retained in one window only and are not gains from or losses to zero. Missing Search Console rows would be mistaken for zero activity. Should keep unmatched segments distinct from real losses and audit the top matched movers and query intent before drawing a segment conclusion.",
+      "assertions": [
+        "Refuses to count unmatched segments as total losses",
+        "States unmatchedSegments are retained in one window only, not losses to zero",
+        "Notes missing Search Console rows are not zero activity",
+        "Keeps unmatched segments distinct from real losses",
+        "Recommends auditing the top matched movers first"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/seo-fix-queue.json

@@ -0,0 +1,85 @@
+{
+  "subject": "seo-fix-queue",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Give me a prioritized list of SEO fixes we can actually ship this sprint, with the URLs to change.",
+      "expected_output": "Should run the bounded queue directly with `seo crawl-queue --project <project> --json`, or through MCP run report id site-crawl with saveReport true and pass its reportId to report ids top-fixes and affected-urls. Should read dataStatus, source joins, selection counts, warnings, and caveats before ranking. Should preserve the returned priority order unless stronger evidence supports a change. Should keep each item's rule id, priority, evidence, affected count, bounded URL sample, fix, and verification step.",
+      "assertions": [
+        "Runs the bounded queue via seo crawl-queue or report id site-crawl with saveReport",
+        "Passes the saved reportId to report ids top-fixes and affected-urls",
+        "Reads dataStatus, source joins, selection counts, warnings, and caveats before ranking",
+        "Preserves the returned priority order unless stronger evidence changes it",
+        "Keeps rule id, priority, evidence, affected count, URL sample, fix, and verification per item",
+        "Does not dump every rule the crawler checked"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Reuse the crawl we already saved. Give me the affected URLs for the title-missing issue and explain what the rule means.",
+      "expected_output": "Should reuse the saved crawl instead of crawling again, running report id affected-urls with the ruleId and the saved reportId, and report id explain-crawl-issue for the rule, with the CLI parity `seo explain --rule <rule-id> --json`. Should return the bounded URL sample and the rule explanation with its verification step. Should not launch a fresh crawl when a saved report is available.",
+      "assertions": [
+        "Reuses the saved crawl rather than recrawling",
+        "Runs report id affected-urls filtered to the requested rule",
+        "Runs report id explain-crawl-issue for the rule",
+        "Shows the `seo explain --rule <rule-id> --json` parity command",
+        "Returns a bounded URL sample and a verification step",
+        "Does not start a new crawl when a saved report exists"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "The crawl-queue came back with only three issues on the 500 pages it hit. Mark everything else on the site as passing so we can close the ticket.",
+      "expected_output": "Should refuse to mark the rest of the site passing. Should point out that summary.pageLimitReached means the crawl was capped, and a capped crawl cannot support an inventory-wide zero or all-clear. Should keep failed fetches, missing provider data, and filtered rows separate from observed zeros. Should recommend widening the crawl or sampling untested URLs before closing the issue as clean.",
+      "assertions": [
+        "Refuses to mark untested pages as passing",
+        "Cites summary.pageLimitReached and the capped crawl",
+        "States a capped crawl cannot support an inventory-wide zero or all-clear",
+        "Separates failed fetches and filtered rows from observed zeros",
+        "Recommends widening scope or sampling before closing the ticket"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "This page has clean tags in the crawl, so add it to the queue as a high-value page we should build more internal links to.",
+      "expected_output": "Should not call the page valuable or search-visible from crawl evidence alone. Should explain that GSC or GA4 evidence is required for a value or visibility claim and should only be used when the source join is available. Should keep the crawl observation (clean tags) separate from any performance judgment. Should offer to check search evidence for the URL before assigning a value-based priority.",
+      "assertions": [
+        "Refuses to call the page valuable or search-visible from crawl evidence alone",
+        "States a value or visibility claim needs an available GSC or GA4 source join",
+        "Keeps the clean-tags observation separate from a performance judgment",
+        "Offers to check search evidence before prioritising the page by value",
+        "Does not fabricate traffic or link value for the page"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Turn the whole crawl into an implementation ticket file our devs can pick up. And keep your summary to me short.",
+      "expected_output": "Should write the Markdown handoff only because the user asked for a file, using seo crawl --project <project> --format markdown --output seo-fixes.md. Should keep the reply to the user short, showing the top material fixes and ending with the next verification command rather than every rule. Should keep each ticket's evidence and verification intact in the file. Should not pad the answer with the full rule inventory.",
+      "assertions": [
+        "Writes the Markdown ticket file with seo crawl --format markdown --output",
+        "Keeps the direct reply short with only the top material fixes",
+        "Ends the reply with the next verification command",
+        "Retains evidence and verification for each ticket in the file",
+        "Does not dump the full rule inventory into the reply"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "The crawler returned an unfamiliar rule id and a couple of pages that failed to fetch. What do we do with those?",
+      "expected_output": "Should run report id explain-crawl-issue for the unfamiliar rule so the queue item carries a real explanation and verification step. Should treat the failed fetches as a distinct state, not an observed zero and not a passing result, and keep them visible in the queue rather than dropping them. Should not assume the failed-fetch pages are clean.",
+      "assertions": [
+        "Runs report id explain-crawl-issue for the unfamiliar rule",
+        "Keeps failed fetches as a distinct state, not an observed zero",
+        "Does not treat failed-fetch pages as passing or clean",
+        "Keeps the failed fetches visible in the queue",
+        "Attaches a verification step to the explained rule"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/seo-geo-readiness.json

@@ -0,0 +1,84 @@
+{
+  "subject": "seo-geo-readiness",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We want ChatGPT and Perplexity to recommend our tool. Can you check if our site is set up for AI search?",
+      "expected_output": "Should frame this as a technical readiness and referral-evidence check, not proof that any AI product cites the site. Should build a saved crawl and run report id ai-readiness, for example seo crawl --project <project> --max-pages 500 --save --json then seo ai-readiness --project <project> --json, describing the schema first when parameters are unknown. Should check dataStatus, summary.pageLimitReached, warnings, and caveats. Should separate failed technical checks from contextual observations and not promise citations or recommendations.",
+      "assertions": [
+        "Frames the work as technical readiness, not proof of AI citation",
+        "Builds a saved crawl then runs report id ai-readiness",
+        "Checks dataStatus, summary.pageLimitReached, warnings, and caveats",
+        "Separates failed technical checks from contextual observations",
+        "Does not promise that ChatGPT or Perplexity will recommend the site",
+        "Offers report id geo-gaps when exact affected URLs are needed"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "The ai-readiness report came back with no blockers. Does that mean AI systems are citing us now?",
+      "expected_output": "Should refuse to equate a clean readiness report with observed citations. Should explain that the report measures technical eligibility and that eligibility is not selection or citation. Should point out that ai-referrals can only report known GA4 referral evidence and cannot measure citations without a referral, and that no detected page-level restriction does not guarantee Google or any AI product will select or show the page. Should recommend monitoring rather than asserting citation.",
+      "assertions": [
+        "Refuses to equate a clean ai-readiness report with observed citations",
+        "States technical eligibility is not selection or citation",
+        "Explains ai-referrals needs a referral and cannot measure citations otherwise",
+        "Notes no detected restriction does not guarantee selection or display",
+        "Recommends monitoring instead of claiming citation"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Someone told me adding an llms.txt file will boost our Google rankings. Should we add one to climb the rankings?",
+      "expected_output": "Should correct the premise. Should explain that /llms.txt is optional metadata for agents that support it and that the report does not treat it as a Google Search ranking signal. Should say adding it is fine as optional machine discovery but should not be sold as a ranking lever. Should offer report id llms-txt-audit or the seo llms audit command to check the file rather than claiming a ranking effect.",
+      "assertions": [
+        "Corrects the claim that llms.txt boosts Google rankings",
+        "States llms.txt is optional metadata and not a Google ranking signal",
+        "Does not recommend it as a way to climb rankings",
+        "Frames it as optional machine discovery only",
+        "Offers a way to audit the file rather than asserting a ranking effect"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Can you pull the list of AI search queries people actually used to find us, from seo-to-ai-query?",
+      "expected_output": "Should clarify that seo-to-ai-query produces deterministic monitoring-prompt suggestions derived from retained GSC wording and that these are not observed AI queries. Should run report id seo-to-ai-query for the property and present the output as suggested prompts to monitor, not as evidence of real AI-product searches. Should note grouped GSC wording can omit anonymised rows so the suggestion set is a retained subset.",
+      "assertions": [
+        "Clarifies seo-to-ai-query outputs are suggestions, not observed AI queries",
+        "Explains the suggestions derive deterministically from retained GSC wording",
+        "Runs report id seo-to-ai-query for the property",
+        "Does not present the output as real AI-product search data",
+        "Notes the retained wording can omit anonymised rows"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Our blog posts have max-snippet:0 set. The readiness report should just tell us we're not AI ready and we fix it, right?",
+      "expected_output": "Should report the snippet directive exactly rather than jumping to a defect verdict. Should record nosnippet, max-snippet:0, positive max-snippet limits, and unrestricted max-snippet:-1 as observed controls, treating an intentional control as an observation until intent or contradictory evidence makes it a defect. Should ask whether the restriction is intentional before recommending removal, and should explain it can limit snippet display without being a readiness failure by itself.",
+      "assertions": [
+        "Reports the max-snippet:0 directive exactly as an observed control",
+        "Treats the snippet control as an observation until intent is confirmed",
+        "Asks whether the restriction is intentional before recommending a change",
+        "Distinguishes nosnippet, max-snippet:0, positive limits, and max-snippet:-1",
+        "Does not declare the pages not AI ready solely from the directive"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "To rank in AI answers, should we chunk every page into small sections and hit a 1,500 word minimum? Also can you write the intros?",
+      "expected_output": "Should decline the content-chunking and minimum word count recommendations made solely for AI search, since the skill does not recommend either for that reason. Should treat paragraph shape, lists, tables, and question headings as observations that do not prove quality or citation likelihood. Should recommend structured data, semantic HTML, authorship, and dates only for a documented user or Search feature need. Should not generate the intro copy, keeping advice structural.",
+      "assertions": [
+        "Declines to recommend content chunking solely for AI search",
+        "Declines to recommend a minimum word count for AI search",
+        "Treats paragraph shape, lists, and headings as observations, not proof of citation",
+        "Ties structured data and authorship advice to a documented user or feature need",
+        "Does not write the intro copy"
+      ],
+      "files": []
+    }
+  ]
+}

package/evals/seo-site-audit.json

@@ -0,0 +1,85 @@
+{
+  "subject": "seo-site-audit",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Can you audit our website? It's a mid-size ecommerce store and I think our SEO has problems but I'm not sure where.",
+      "expected_output": "Should start with the main report rather than jumping into a crawl or a niche report. Should run report id search-performance-overview, calling seo_describe_report first when the parameters are not known, and offer the CLI path `seo report --project <project> --json`. Should read dataStatus, source completeness, skipped sections, warnings, and caveats before interpreting anything. Should use the report's nextCommands to pick a small set of follow-ups instead of running every report. Should end with three to five evidence-backed actions, each with a verification command.",
+      "assertions": [
+        "Starts with report id search-performance-overview as the main report",
+        "Describes the report schema before running when parameters are unknown",
+        "Checks dataStatus, skipped sections, warnings, and caveats before interpreting",
+        "Uses nextCommands to choose a small number of follow-ups",
+        "Does not run every available report by default",
+        "Ends with three to five actions each paired with a verification step"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Run the main audit for sc-domain:example.com and then add technical coverage. I want the crawl saved so we can reuse it.",
+      "expected_output": "Should run report id search-performance-overview for the property, then run a saved crawl with seo crawl --site sc-domain:example.com --max-pages 500 --save --json. Should read summary, topFixes, warnings, and caveats first and check summary.pageLimitReached before any sitewide claim. Should reuse the saved report through report ids top-fixes and affected-urls rather than crawling again. Should keep the structured evidence rather than paraphrasing away the caveats.",
+      "assertions": [
+        "Runs report id search-performance-overview before the crawl",
+        "Runs a saved crawl with a page cap and --save",
+        "Reads summary, topFixes, warnings, and caveats before findings",
+        "Checks summary.pageLimitReached before any sitewide claim",
+        "Reuses the saved report via report ids top-fixes and affected-urls instead of recrawling",
+        "Preserves the structured caveats rather than dropping them"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "We crawled 500 pages and it found no broken canonicals. Our site has about 40,000 URLs. Can we tell the team canonicals are clean sitewide?",
+      "expected_output": "Should refuse the sitewide all-clear. Should point out that summary.pageLimitReached is true when the crawl stopped at 500 of roughly 40,000 URLs, so a capped source cannot support an inventory-wide zero or all-clear. Should keep the observed result scoped to the crawled sample and distinguish a capped sample from a verified zero. Should recommend widening the crawl scope or sampling the untested templates before making a sitewide claim.",
+      "assertions": [
+        "Refuses to declare canonicals clean sitewide from a capped crawl",
+        "Cites summary.pageLimitReached or the 500 of 40,000 coverage gap",
+        "States a capped source cannot support an inventory-wide zero or all-clear",
+        "Scopes the finding to the crawled sample only",
+        "Recommends widening scope or sampling untested URLs before a sitewide claim"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "The audit came back clean on the technical checks. Great, so that confirms Google is indexing everything and we're ranking fine, yes?",
+      "expected_output": "Should decline to translate a clean crawl into indexing or ranking conclusions. Should explain that the crawl observes technical signals on fetched pages and never proves indexing state, crawler access to every URL, or ranking. Should note a partial or capped source cannot support an all-clear. Should recommend separate evidence for the indexing question, such as report id index-coverage or bounded URL Inspection, before making any indexing claim.",
+      "assertions": [
+        "Refuses to infer indexing or ranking from a clean technical crawl",
+        "States the crawl does not prove indexing state or crawler access to every URL",
+        "Notes a partial or capped source cannot support an all-clear",
+        "Points to index-coverage or URL Inspection as the separate evidence for indexing",
+        "Keeps ranking claims out of the crawl-based conclusion"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "The crawl flagged slow pages. Can you use it to tell me our Core Web Vitals scores and whether we pass?",
+      "expected_output": "Should explain that a crawl does not replace Lighthouse lab data or CrUX field data, so it cannot report Core Web Vitals pass or fail. Should route to report id performance-audit for a selected URL when performance evidence is needed and separate lab diagnostics from field data. Should not convert crawl-observed slowness into a Core Web Vitals verdict.",
+      "assertions": [
+        "States the crawl does not replace Lighthouse lab or CrUX field data",
+        "Does not report Core Web Vitals pass or fail from crawl evidence",
+        "Routes to report id performance-audit for a selected URL",
+        "Separates lab diagnostics from field measurement",
+        "Keeps the performance claim scoped to what the evidence supports"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "Give me the final audit writeup for the stakeholders. Keep it to the things worth doing.",
+      "expected_output": "Should present the top three to five evidence-backed actions with their affected areas and a verification command for each, rather than dumping every issue the tools checked. Should name every material gap or cap so the summary is defensible. Should keep advice structural and diagnostic and not invent clicks, sessions, rankings, issue counts, indexing state, or sitewide health. Should not add title or meta copy unless asked.",
+      "assertions": [
+        "Limits the writeup to three to five prioritised actions",
+        "Gives each action an affected area and a verification command",
+        "Names every material gap or cap in the evidence",
+        "Does not invent clicks, sessions, rankings, issue counts, or indexing state",
+        "Keeps advice structural rather than writing new title or meta copy unprompted"
+      ],
+      "files": []
+    }
+  ]
+}