seo 0.1.0 → 0.2.1

package/skills/quick-wins/SKILL.md

@@ -1,31 +0,0 @@
----
-name: quick-wins
-description: Rank retained position 4-10 GSC query-page rows below a site-aware CTR target; use when an agent needs a bounded opportunity queue with optional live-content verification.
----
-
-# Quick wins
-
-Use this report to prioritise retained query/page rows with meaningful impressions, average positions from 4 through 10, and CTR below a leave-target-out site benchmark or documented fallback curve. Optional page verification checks whether the live page covers the query or presents technical evidence before recommending a content action. “Quick win” describes the review queue, not effort, certainty, or expected traffic.
-
-## Run the report
-
-Use the compact MCP flow:
-
-1. Call `seo_list_reports` with `{"category":"opportunities"}`.
-2. Call `seo_describe_report` with `{"id":"quick-wins"}`.
-3. Call `seo_run_report` with `{"id":"quick-wins","params":{"site":"sc-domain:example.com","days":90,"limit":20,"minImpressions":100,"verifyContent":true,"verifyLimit":5}}`.
-
-The CLI calls the same definition:
-
-```sh
-seo reports describe quick-wins --json
-seo reports run quick-wins --params '{"site":"sc-domain:example.com","days":90,"limit":20,"minImpressions":100,"verifyContent":true,"verifyLimit":5}' --json
-```
-
-`site` is required. `limit` bounds returned rows and `verifyLimit` bounds live page checks. Use `js:true` and higher fetch rates only when needed and permitted.
-
-## Interpret and act
-
-Check `dataStatus`, date range, source row cap, `possiblyTruncated`, `selection.invalidRows`, filters, and limited rows. Read `methodology` and each item's benchmark confidence before using `targetCtr`. `estimatedCtrClickShortfall` and priority score are heuristics, explicitly not estimated lift. Inspect `verification.requested`, attempted, verified, failed, and technical counts. An unverified item still has GSC evidence but cannot support a content-coverage conclusion. Review groups and template patterns for repeated hypotheses without converting their sums into forecasts.
-
-Safe actions are to inspect the live SERP, resolve technical conflicts, test clearer snippet framing, improve a genuinely missing answer, or add a relevant internal link. Record the change and compare a later complete window. Do not promise clicks, force query wording into copy, treat average position as a stable rank, or call filtered or capped evidence an all-clear.

package/skills/quick-wins/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Quick wins"
-  short_description: "Find high-impression ranking and CTR review candidates"
-  default_prompt: "Use $quick-wins to run the quick-wins report and explain its evidence and limits."

package/skills/redirect-trace/SKILL.md

@@ -1,51 +0,0 @@
----
-name: redirect-trace
-description: Record every HTTP redirect hop and inspect the final page's indexability signals; use it to debug loops, broken chains, and destination mismatches for one URL.
----
-
-# Trace one redirect path
-
-Use `redirect-trace` when a specific URL behaves unexpectedly after a move,
-canonical change, or routing release. It follows HTTP redirects manually,
-records each response, and audits the final destination for basic indexability
-and canonical evidence. The trace is one observation from the machine and time
-that ran it; CDNs, geography, cookies, user agents, and later deploys can differ.
-
-## Run the report
-
-With MCP, call `seo_list_reports` with `{"category":"monitoring"}`. Call
-`seo_describe_report` with `{"id":"redirect-trace"}`, then call
-`seo_run_report`, for example
-`{"id":"redirect-trace","params":{"url":"https://example.com/old-page","maxHops":8,"js":false,"refresh":true}}`.
-
-The CLI uses the same registry:
-
-```sh
-seo reports describe redirect-trace --json
-seo reports run redirect-trace --params '{"url":"https://example.com/old-page","maxHops":8,"refresh":true}' --json
-```
-
-`maxHops` is currently a broad number in discovery. Pass a small positive whole
-number; very large chains are not a useful success condition.
-
-## Interpret the output
-
-Read `chain` in order. Each step contains the requested URL, status, `Location`,
-resolved next URL, and duration. Then compare `finalUrl` with `finalPage` and
-`summary.finalStatus`. `summary.issues` can identify a loop, hop limit,
-redirect without location, final 4xx or 5xx, non-indexable final page, or a
-canonical mismatch.
-
-Inspect `metaRobots`, `xRobotsTag`, canonical, and `warnings` as observations.
-A missing `finalPage` or fetch warning limits indexability conclusions.
-JavaScript rendering affects final-page extraction, not the HTTP redirect chain.
-A canonical pointing elsewhere can be intentional; a 302 can also be
-intentional. The report does not know the desired destination.
-
-## Act safely
-
-Confirm the intended URL map before editing redirects. Prefer one direct
-permanent redirect for a genuine move, remove loops, restore missing locations,
-and align the final canonical only when the destination is correct. Re-run the
-trace after deployment. Do not declare an SEO defect or ranking impact from a
-chain difference without intent and search evidence.

package/skills/redirect-trace/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Redirect trace"
-  short_description: "Trace one redirect chain"
-  default_prompt: "Use $redirect-trace to run the redirect-trace report and explain its evidence and limits."

package/skills/refresh-priorities/SKILL.md

@@ -1,48 +0,0 @@
----
-name: refresh-priorities
-description: Combine several first-party opportunity reports into a bounded refresh queue. Use it to prioritize investigation while preserving each source's distinct meaning and limits.
----
-
-# Refresh priorities workflow
-
-This workflow helps choose what to inspect next by combining decay, position,
-CTR, exposure, diagnosis, content verification, and optional GA4 signals. It
-does not make those signals interchangeable or predict the benefit of an edit.
-The queue is a deterministic prioritization aid, not an autonomous content
-brief.
-
-## Run it
-
-Use the exact MCP discovery flow:
-
-1. Call `seo_list_reports` with `category: "workflows"` and select `refresh-priorities`.
-2. Call `seo_describe_report` with `id: "refresh-priorities"`; inspect all bounds.
-3. Call `seo_run_report` with that id and schema-valid parameters.
-
-CLI parity:
-
-```sh
-seo reports describe refresh-priorities --json
-seo reports run refresh-priorities --params '{"site":"sc-domain:example.com","days":90,"recentDays":7,"limit":10,"includeBrand":false,"verifyContent":true,"verifyLimit":5}' --json
-```
-
-Add `ga4PropertyId` only when that property's sessions are needed and accessible.
-`verifyLimit` caps fetched content checks; it does not verify every queued URL.
-
-## Interpret and act
-
-Read the workflow's steps and skipped states before its queue. For each queued
-item preserve `source`, `impactKind`, score breakdown, date window, completeness,
-verification status, and rationale. A click decline, low CTR, second-page
-average position, and GA4 session signal have different semantics. Missing GA4
-or failed content fetches must remain unavailable, not become zero-weight proof.
-
-Inspect the top few URLs manually. Confirm query intent, current content,
-technical accessibility, internal links, competing pages, and whether a recent
-change already explains the observation. Choose a bounded edit only when the
-evidence supports it, record the change date, and measure later. Never delete,
-merge, or rewrite content solely from the combined score. Do not present the
-score as expected clicks, revenue, ranking lift, or causal confidence.
-
-MCP `structuredContent` is the machine contract. Use Markdown for a concise
-human queue while retaining the underlying evidence fields for agents.

package/skills/refresh-priorities/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Refresh priorities workflow"
-  short_description: "Rank several first-party opportunity reports into one action queue"
-  default_prompt: "Use $refresh-priorities to run the refresh-priorities report and explain its evidence and limits."

package/skills/search-performance-overview/SKILL.md

@@ -1,48 +0,0 @@
----
-name: search-performance-overview
-description: Find where Google Search clicks and impressions changed, which pages or queries explain the movement, and which focused report to run next. Use when search performance moved or an agent needs a first-party baseline but does not yet know where to investigate.
----
-
-# Search performance overview
-
-Use this when organic search performance changed and you do not yet know which
-pages, queries, countries, or devices explain it. It is also the best first
-report for a newly connected Search Console property. The report finds where
-the movement sits, then points to the focused report that can verify the issue.
-
-## Run it
-
-Use the exact MCP discovery flow:
-
-1. Call `seo_list_reports` with `category: "workflows"` and select `search-performance-overview`.
-2. Call `seo_describe_report` with `id: "search-performance-overview"` and inspect its schema.
-3. Call `seo_run_report` with that id and only schema-valid parameters.
-
-CLI parity:
-
-```sh
-seo reports describe search-performance-overview --json
-seo reports run search-performance-overview --params '{"site":"sc-domain:example.com","days":90,"recentDays":7,"limit":10,"includeBrand":false}' --json
-```
-
-`days` sets the main evidence window and `recentDays` sets the recent comparison
-period. `limit` caps the items returned; it does not increase provider coverage.
-
-## Interpret and act
-
-Read the workflow envelope first: `workflow`, `site`, `generatedAt`, `summary`,
-`steps`, `actions`, and `output`. Every step has its own status and evidence.
-Then inspect the report's `dataStatus`, skipped sections, partial reasons,
-priorities, and nested anomaly, update, segment, decay, cannibalisation,
-striking-distance, and quick-win results. Do not let one complete section hide a
-failed or capped neighbour.
-
-Start with actions that cite reproducible evidence. Confirm affected URLs,
-provider dates, selection limits, and intentional technical controls before
-editing anything. Run a focused report to inspect detail rather than asking this
-broad workflow for a larger payload. Sparse data may legitimately skip a
-section. Update overlap, opportunity scores, average position, and timing are
-investigation signals, not causation or forecasts.
-
-Treat MCP `structuredContent` as the machine contract. Use Markdown for the
-human summary while preserving structured evidence references in any handoff.

package/skills/search-performance-overview/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Search performance overview"
-  short_description: "Find where Google Search performance changed"
-  default_prompt: "Use $search-performance-overview to find where Google Search performance changed, explain the pages or queries behind it, and choose the next focused report."

package/skills/second-page/SKILL.md

@@ -1,50 +0,0 @@
----
-name: second-page
-description: Find retained GSC page-query rows with average positions from 10 through 20. Use them as bounded investigation prompts, not promised ranking wins.
----
-
-# Second-page opportunities
-
-This report surfaces page-query combinations near the first-page boundary so an
-agent can inspect whether the page satisfies the observed query. It is a triage
-tool. Average position is aggregated across searches, locations, devices, and
-time; it is not an exact rank, proof of intent mismatch, or evidence that an
-edit will improve performance.
-
-## Run it
-
-Use the exact MCP discovery flow:
-
-1. Call `seo_list_reports` with `category: "reporting"` and select `second-page`.
-2. Call `seo_describe_report` with `id: "second-page"`; inspect bounds and defaults.
-3. Call `seo_run_report` with `id: "second-page"` and matching parameters.
-
-CLI parity:
-
-```sh
-seo reports describe second-page --json
-seo reports run second-page --params '{"site":"sc-domain:example.com","range":28,"minImpressions":50,"limit":10,"includeBrand":false,"verifyContent":true,"verifyLimit":5}' --json
-```
-
-`range` is the analysis window. `minImpressions` removes very sparse candidates.
-`limit` is a retained-output cap. `verifyContent` fetches only up to
-`verifyLimit` candidates, so unverified items remain unknown rather than failed.
-
-## Interpret and act
-
-Check source completeness, date range, `selection`, `methodology`, provenance,
-brand filtering, and caveats before ranking the items. Duplicate provider rows
-should already be aggregated deterministically, but retained limits still mean
-the output is not a complete inventory. Read impressions, clicks, CTR, and
-average position as observed metrics. Treat the priority value as a transparent
-heuristic, not expected click lift.
-
-For a promising item, inspect the live page and search intent, verify that the
-query is appropriate for the URL, review internal linking and competing pages,
-then make one defensible change. Preserve pages already satisfying intent.
-Never add text solely to hit a length threshold, promise a first-page result,
-or infer cannibalisation from one row. If the source is capped, partial, or
-filtered, say so in the recommendation.
-
-Use MCP `structuredContent` as the machine contract and Markdown only to explain
-the evidence and next investigation to a human.

package/skills/second-page/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Second-page opportunities"
-  short_description: "Find URLs with retained GSC average positions above 10 through 20"
-  default_prompt: "Use $second-page to run the second-page report and explain its evidence and limits."

package/skills/segment-impact/SKILL.md

@@ -1,50 +0,0 @@
----
-name: segment-impact
-description: Compare matched retained GSC rows across adjacent periods for one dimension; use it to locate where observed movement is concentrated without treating missing rows as zero.
----
-
-# Compare segment movement
-
-Use `segment-impact` after a property-level change is visible and you need to
-find which pages, queries, countries, or devices moved. It compares equal-length
-adjacent finalized GSC windows. The report deliberately limits conclusions to
-segments retained in both windows, so its deltas are comparable without
-inventing zeros for rows that disappeared from one retained result set.
-
-## Run the report
-
-With MCP, call `seo_list_reports` with `{"category":"diagnosis"}`, then
-`seo_describe_report` with `{"id":"segment-impact"}`. Then call
-`seo_run_report` with the described report, for example
-`{"id":"segment-impact","params":{"site":"sc-domain:example.com","dimension":"page","days":28,"compareDays":28,"limit":20,"maxRows":50000,"unmatchedLimit":10}}`.
-
-The CLI uses the same schema:
-
-```sh
-seo reports describe segment-impact --json
-seo reports run segment-impact --params '{"site":"sc-domain:example.com","dimension":"page","days":28,"compareDays":28,"limit":20,"maxRows":50000,"unmatchedLimit":10}' --json
-```
-
-Use either relative windows or an explicit `startDate` and `endDate` after
-checking the current schema. Do not send undeclared fields.
-
-## Interpret the output
-
-Confirm `before`, `after`, and `rangeDays` before reading movement. Inspect
-`dataStatus`, `source.before`, `source.after`, and `source.completeness` for
-provider calls, row caps, and possible truncation. `selection` explains invalid,
-duplicate, conflicting, matched, unmatched, returned, and limited rows.
-
-In `items`, `clickDelta` and `impressionDelta` are after minus before. A positive
-`positionDelta` is worse because a larger GSC average position is lower in the
-results. `unmatchedSegments` are observations retained in one window only; they
-are not gains from or losses to zero. Read `warnings`, `caveats`, and
-`methodology` before describing a leading segment.
-
-## Act safely
-
-Use the top matched movers to define a smaller investigation: audit affected
-pages, group repeated templates, or compare query intent. Check unmatched rows
-separately with a wider export if they matter. Segment concentration does not
-establish why movement happened, and a limited or possibly truncated result
-cannot support an inventory-wide winner or loser claim.

package/skills/segment-impact/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Segment impact"
-  short_description: "Compare retained GSC movement by page, query, device, or country"
-  default_prompt: "Use $segment-impact to run the segment-impact report and explain its evidence and limits."

package/skills/seo-fix-queue/SKILL.md

@@ -1,50 +0,0 @@
----
-name: seo-fix-queue
-description: Turn seo crawl and report evidence into a prioritized implementation queue. Use when the user wants exact SEO fixes, implementation tickets, affected URLs, verification steps, or a ranked technical SEO and GEO backlog.
----
-
-# SEO fix queue
-
-Run the bounded queue directly:
-
-```bash
-seo crawl-queue --project <project> --json
-seo crawl-queue https://example.com --json
-```
-
-Through MCP, use `seo_run_report` with report id `site-crawl` and
-`saveReport: true`. Pass its `reportId` to report ids `top-fixes` and
-`affected-urls`. Reuse that report instead of crawling again. Call
-`seo_describe_report` before a report when its parameters are not already
-known.
-
-## Check the evidence before ranking work
-
-1. Read `dataStatus`, source joins, selection counts, warnings, and caveats.
-2. Check `summary.pageLimitReached`. A capped crawl cannot support an
-   inventory-wide zero or all-clear.
-3. Preserve the returned priority order unless stronger evidence supports a
-   change.
-4. Use GSC or GA4 evidence only when the source join is available. Do not call a
-   page search-visible or valuable from crawl evidence alone.
-5. Keep failed fetches, missing provider data, and filtered rows separate from
-   observed zeros.
-
-Each queue item should retain its rule id, priority, evidence, affected count,
-bounded URL sample, fix, and verification step. Explain unfamiliar rules with
-structured output:
-
-```bash
-seo explain --rule <rule-id> --json
-```
-
-Use report id `explain-crawl-issue` through `seo_run_report`.
-
-Write Markdown implementation tickets only when the user wants a handoff file:
-
-```bash
-seo crawl --project <project> --format markdown --output seo-fixes.md
-```
-
-Keep the final answer short. Show the top material fixes and end with the next
-verification command. Do not dump every rule the crawler checked.

package/skills/seo-fix-queue/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SEO fix queue"
-  short_description: "Build a bounded evidence-backed SEO backlog"
-  default_prompt: "Use $seo-fix-queue to turn this site's crawl evidence into a prioritized implementation queue."

package/skills/seo-geo-readiness/SKILL.md

@@ -1,60 +0,0 @@
----
-name: seo-geo-readiness
-description: Audit local technical eligibility evidence and supporting website observations for AI search with seo. Use when the user asks about ChatGPT, Claude, Perplexity, Gemini, Google AI Overviews, LLM citations, llms.txt, structured data, authorship, or AI-search visibility.
----
-
-# GEO readiness
-
-This workflow measures technical readiness and referral evidence. It does not
-prove that an AI product cites the site.
-
-## Run the readiness report
-
-Create a saved crawl, then analyze the same report:
-
-```bash
-seo crawl --project <project> --max-pages 500 --save --json
-seo ai-readiness --project <project> --json
-```
-
-Through MCP, use `seo_run_report` with report id `ai-readiness`. Use report id
-`geo-gaps` when exact affected URLs for crawl and indexability rules are
-needed. Call `seo_describe_report` before a report when its parameters are not
-already known.
-
-1. Check `dataStatus`, `summary.pageLimitReached`, warnings, and caveats.
-2. Separate failed technical checks from contextual observations.
-3. Treat local crawl indexability as local evidence. It does not prove that
-   Google indexed the URL.
-4. Use bounded URL Inspection evidence when Google's indexed snapshot changes
-   the decision. It is not a live crawl or a sitewide sample.
-
-## Explain the evidence
-
-- Blocked crawling, publisher `noindex`, snippet restrictions, and non-success
-  HTML responses can prevent or limit technical eligibility.
-- Structured data, semantic HTML, authorship, and dates are contextual
-  observations. Recommend them only for a documented user or Search feature
-  need.
-- Paragraph shape, lists, tables, and question headings do not prove quality or
-  citation likelihood.
-- Do not recommend content chunking or a minimum word count solely for AI
-  Search.
-- `/llms.txt` is optional metadata for agents that support it. The report does
-  not treat it as a Google Search ranking signal.
-
-Useful follow-up reports remain structured for agents:
-
-```bash
-seo seo-to-ai-query --project <project> --json
-seo ai-referrals --project <project> --json
-seo llms audit --project <project> --json
-```
-
-`seo-to-ai-query` creates deterministic monitoring-prompt suggestions from
-retained GSC wording. These are not observed AI queries. `ai-referrals` reports
-known GA4 referral evidence and cannot measure citations without a referral.
-
-Report `nosnippet`, `max-snippet:0`, positive `max-snippet` limits, and
-unrestricted `max-snippet:-1` exactly. No detected page-level restriction does
-not guarantee that Google will select or show the page.

package/skills/seo-geo-readiness/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SEO GEO readiness"
-  short_description: "Review local AI-search readiness evidence"
-  default_prompt: "Use $seo-geo-readiness to review this site's AI-search readiness without overstating citations or visibility."

package/skills/seo-site-audit/SKILL.md

@@ -1,59 +0,0 @@
----
-name: seo-site-audit
-description: Run an evidence-backed site audit with the seo main report, crawler, and focused follow-up reports. Use when the user asks to audit or diagnose a website across Search Console performance, technical SEO, indexability, metadata, schema, internal linking, security, performance, or AI-search readiness.
----
-
-# SEO site audit
-
-Start with the main report. It joins the available first-party evidence and
-returns a small set of follow-up commands.
-
-Through MCP, call `seo_run_report` with report id
-`search-performance-overview`. Call `seo_describe_report` first when its
-parameters are not already known. Use the CLI when MCP is not available:
-
-```bash
-seo report --project <project> --json
-seo report --site sc-domain:example.com --json
-```
-
-## Read the main report
-
-1. Check `dataStatus`, source completeness, skipped sections, warnings, and
-   caveats before interpreting findings.
-2. Read the narrative and priority queue against their evidence references.
-3. Use `nextCommands` to choose a small number of follow-ups. Do not run every
-   report by default.
-4. Keep missing, unavailable, filtered, partial, capped, and complete evidence
-   separate. A partial source cannot support an all-clear.
-
-## Add technical crawl evidence
-
-Run a crawl when the user asks for technical coverage or the main report
-identifies a technical evidence gap:
-
-```bash
-seo crawl --project <project> --max-pages 500 --save --json
-seo crawl https://example.com --max-pages 500 --save --json
-```
-
-Read `summary`, `topFixes`, `warnings`, and `caveats` first. Check
-`summary.pageLimitReached` before making sitewide claims. Reuse the saved report
-for detail instead of crawling again:
-
-- Report id `top-fixes` returns a bounded queue.
-- Report id `affected-urls` returns URLs for one rule.
-- Report id `explain-crawl-issue` explains an unfamiliar rule.
-- Report id `crawl-report` returns requested report detail.
-
-Use report id `performance-audit` for a selected URL when performance evidence
-is needed. A crawl does not replace Lighthouse lab data or CrUX field data.
-
-## Present the result
-
-Give the user the top three to five evidence-backed actions, affected areas,
-and a verification command for each action. Name every material gap or cap.
-
-Never invent clicks, sessions, rankings, issue counts, indexing state, or
-sitewide health. Keep advice structural and diagnostic unless the user asks
-for copy.

package/skills/seo-site-audit/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SEO site audit"
-  short_description: "Audit a site with report and crawl evidence"
-  default_prompt: "Use $seo-site-audit to audit this site and return a bounded evidence-backed action plan."

package/skills/seo-to-ai-query/SKILL.md

@@ -1,31 +0,0 @@
----
-name: seo-to-ai-query
-description: Convert retained GSC query wording into deterministic AI monitoring prompts; use when an agent needs a reproducible prompt seed set without claiming observed AI demand or visibility.
----
-
-# Queries to AI prompts
-
-Use this report to turn first-party GSC query wording into a bounded set of prompts for later manual or automated monitoring. Each source query keeps its clicks, impressions, CTR, and average position, while deterministic templates produce stable prompt suggestions. The output is useful for designing a monitoring corpus. It is not evidence that anyone entered those prompts into an AI product, that an answer mentioned the site, or that the source query has equivalent AI demand.
-
-## Run the report
-
-Use the compact MCP flow:
-
-1. Call `seo_list_reports` with `{"category":"ai-search"}`.
-2. Call `seo_describe_report` with `{"id":"seo-to-ai-query"}`.
-3. Call `seo_run_report` with `{"id":"seo-to-ai-query","params":{"site":"sc-domain:example.com","days":90,"limit":20,"minImpressions":100,"maxRows":10000}}`.
-
-The CLI uses the same registry entry:
-
-```sh
-seo reports describe seo-to-ai-query --json
-seo reports run seo-to-ai-query --params '{"site":"sc-domain:example.com","days":90,"limit":20,"minImpressions":100,"maxRows":10000}' --json
-```
-
-`site` is required. Use either `days` or an explicit `startDate` and `endDate` pair. `maxRows` bounds source retrieval and `limit` bounds returned queries. Supply `brandTerms` or `includeBrand:true` only when brand handling is intentional.
-
-## Interpret and act
-
-Check `dataStatus` before reading `items`: `empty`, `filtered`, `partial`, and `available` mean different things. Preserve `dateRange`, `source.possiblyTruncated`, filters, `selection.invalidRows`, `selection.conflictingRows`, limited rows, warnings, and caveats. `methodology.observedAiPromptData` and `estimatedTrafficLift` are explicitly false. Each item has `evidenceScope: retained-gsc-query`; its prompts inherit that narrow scope.
-
-Safe actions are to select representative prompt variants, store the source query and date range beside later observations, and refresh the corpus on a controlled schedule. Do not report generated prompt count as AI demand, fill missing prompts with guessed traffic, or interpret no returned rows as an all-clear when the source is partial or filtering removed candidates.

package/skills/seo-to-ai-query/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Queries to AI prompts"
-  short_description: "Convert retained GSC wording into deterministic monitoring prompts"
-  default_prompt: "Use $seo-to-ai-query to run the seo-to-ai-query report and explain its evidence and limits."

package/skills/setup-check/SKILL.md

@@ -1,49 +0,0 @@
----
-name: setup-check
-description: Check whether local SEO Skills CLI authentication and defaults are usable; use it before reports when login, scopes, or saved configuration may be incomplete.
----
-
-# Check local setup
-
-Run `setup-check` before blaming a report for an authentication or configuration
-failure. It reads local setup state and separates missing credentials, missing
-Google scopes, and absent defaults from actual SEO evidence. A passing result
-means the local prerequisites look present. It does not prove that a token is
-still accepted by Google or that the account can access a particular property.
-
-## Run the report
-
-With MCP, call `seo_list_reports` with `{"category":"setup"}`. Then call
-`seo_describe_report` with `{"id":"setup-check"}` and use the returned schema.
-Finally call `seo_run_report` with `{"id":"setup-check","params":{}}`. The report
-accepts no parameters, so do not invent a site, project, or refresh field.
-
-The CLI exposes the same registry and schema:
-
-```sh
-seo reports describe setup-check --json
-seo reports run setup-check --params '{}' --json
-```
-
-Read MCP `structuredContent` or the CLI JSON as the machine contract. Use the
-text response only as a short presentation layer.
-
-## Interpret the checks
-
-Start with `ok`, then inspect every entry in `checks`. `status` distinguishes a
-blocking `fail` from a non-blocking `warn`; `detail` records what was observed;
-`fix` gives the matching local remedy when one exists. `generatedAt` tells you
-when the filesystem and token metadata were checked. Missing saved GSC or GA4
-defaults are normally warnings because explicit report parameters can replace
-them.
-
-Never copy account emails, token contents, OAuth client values, private keys,
-or local credential files into an answer. Summarise the check id, status, and a
-safe fix instead.
-
-## Act safely
-
-Apply the narrow fix attached to a failed check, such as logging in again or
-restoring the same OAuth client used by stored tokens. Re-run `setup-check`, then run
-a small read-only report for the intended property. Do not treat a setup pass
-as evidence about rankings, indexing, analytics accuracy, or site health.

package/skills/setup-check/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Doctor"
-  short_description: "Check local seo auth and configuration"
-  default_prompt: "Use $setup-check to run the setup-check report and explain its evidence and limits."

package/skills/site-crawl/SKILL.md

@@ -1,39 +0,0 @@
----
-name: site-crawl
-description: Build a bounded technical SEO inventory with explicit request, page, issue, and completeness evidence. Use for a site baseline or to save a stable crawl for focused follow-up reports.
----
-
-# Crawl a site
-
-A crawl observes what the configured fetcher could discover and retrieve during one run. It is the foundation for most technical reports, but it is not an index, traffic source, or guarantee of complete site coverage. Set a deliberate page and depth budget, then save the snapshot when later analysis must share the same evidence.
-
-## Run it
-
-For MCP, call `seo_list_reports` with category `crawl` when discovery is needed. Call `seo_describe_report` with `{ "id": "site-crawl" }`, then `seo_run_report` with:
-
-```json
-{
-  "id": "site-crawl",
-  "params": {
-    "url": "https://example.com/",
-    "maxPages": 100,
-    "maxDepth": 3,
-    "saveReport": true
-  }
-}
-```
-
-Check `isError` and consume MCP `structuredContent`. The same run is available from the CLI:
-
-```sh
-seo reports describe site-crawl --json
-seo reports run site-crawl --params '{"url":"https://example.com/","maxPages":100,"maxDepth":3,"saveReport":true}' --json
-```
-
-Describe the schema before adding `include`, `exclude`, sitemap, robots, JavaScript, or fetch-rate controls; their interaction changes the evidence collected.
-
-## Judge the crawl before the site
-
-Start with status, `requestEvidenceStatus`, attempted and fetched counts, failures, retained pages, `pageLimitReached`, data-source states, warnings, and caveats. A partial or capped crawl cannot support an all-clear or a definitive zero. Raw `pages`, `requests`, and full `issues` are opt-in because they can be large; request only what the next decision needs.
-
-Separate observations from defects. Response failures and contradictory indexability signals deserve investigation, while canonicals, robots rules, `noindex`, and snippet limits may be intentional. Use the compact top fixes for triage, then run `affected-urls` and `explain-crawl-issue` before creating work. Preserve the report id and crawl settings for verification. If JavaScript rendering was disabled or discovery depended on the sitemap or internal links, state that boundary when summarizing results.

package/skills/site-crawl/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Crawl site"
-  short_description: "Crawl a site for technical SEO evidence"
-  default_prompt: "Use $site-crawl to run the site-crawl report and explain its evidence and limits."