@seoagent-official/seoagent 1.97.3 → 1.98.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.97.3",
+  "version": "1.98.1",
   "description": "The persistent AI SEO agent for Claude Code. Audits, keyword strategy, briefs, articles, real product screenshots from your repo, and the autopilot loop (cloud detects → CLI executes → ack closes) — other SEO tools write the prompt, SEOAgent runs it.",
   "type": "module",
   "bin": {

package/skills/references/cloud-cta.md

@@ -22,7 +22,7 @@ The local skill does the full content loop for free — audit, strategy, briefs,
 One short benefit-led line at the relevant moment, never a wall, never blocking the next step. Examples:
 
 - *Session start:* after the state summary — *"Tip: a free SEOAgent Cloud account gives you a dashboard to track this across devices and connects Google Search Console for real traffic data — `seoagent login` (~30s). Or we can start the audit now."*
-- *After an audit:* *"Want real traffic data behind these findings? Connect Google Search Console (free, ~30s): `seoagent login`."*
+- *After an audit:* *"Want real traffic data behind these findings? Connect Google Search Console (free, ~30s): `seoagent login` then `seoagent gsc connect`."*
 
 Offer **once per session per topic**; if declined, drop it and keep working. Never gate the actual work behind it. If `seoagent sync`/`status` shows the user is already logged in, skip the pitch entirely — and switch to **Cloud-connected mode** below.
 

package/skills/references/inbox.md

@@ -100,6 +100,7 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 - **Check `mode:` first.** It is the whole contract:
   - **`mode: new`** — the slug is free. Review the draft (frontmatter carries title, meta description, status), then place it where this project's content renders: repo-native (mdx_sync) → copy/adapt into the repo's content directory and `seoagent content track` it; CMS → create the entry and track it; cloud-hosted → flip frontmatter `status` to `published` and sync.
   - **`mode: revision`** — that slug **already renders live on this site** (`replaces_path` names the file). **Do not place it as a new post and do not overwrite the live file.** `diff` the two, fold in only what is genuinely new or better, and keep the live article's URL, frontmatter and dates. If the draft adds nothing, decline — that is a real answer.
+- **Match the destination's frontmatter contract, not just the draft's.** The cloud draft carries `title`, `meta_description`, and `status`; the repo's content directory may require fields it does not — an `ogImage`, an `excerpt`, a `date`, a tag list — and may enforce them in CI. Read the content directory's `README`/`_README` and one neighbouring post before writing the file. **Drafts arrive with no images**, so when a hero image is required, produce one in the site's existing style and commit it alongside the post; a draft placed exactly as delivered will otherwise turn the build red.
 - **Renaming the slug is encouraged** when the generated one reads as a full sentence; a short slug is the better URL. When you rename, pass `--supersedes <the-delivered-slug>` to `content track`. That is what tells the cloud it is the SAME article under a new name — without it the cloud keeps the original as an unfinished draft and delivers it to you all over again.
 - **Close it out with `--action <action_id>` on the `content track`** — that acks the action for you, in the step you were already running. `seoagent ack <action_id>` by hand still works (or `--failed --reason "not publishing; ..."` to decline).
 

package/skills/seoagent.md

@@ -135,7 +135,7 @@ Every finding or recommendation — in `audit/latest.md` and in chat — either
 
 **Read `references/keyword-research.md` first** — query patterns, per-tier commands, and Pro sequencing.
 
-GSC data is the biggest quality lever; not connected → recommend `seoagent login`. Connected → **seed first with `seoagent keywords --seed`**; never run `--discover`/`--competitors` on an empty inventory, they return noise. Segment seeds against positioning from `context.md`: on-strategy → prioritize; legacy/off-strategy → harvest/defend, never steering clusters. Never invent numeric scores — H/M/L only when estimating. **No-data on an on-strategy term is a first-mover opportunity**, not absence of value.
+GSC data is the biggest quality lever; not connected → `seoagent gsc connect` (after login). Connected → **seed first with `seoagent keywords --seed`**; never run `--discover`/`--competitors` on an empty inventory (noise). Segment seeds against positioning from `context.md`: on-strategy → prioritize; legacy/off-strategy → harvest/defend, never steering clusters. Never invent numeric scores — H/M/L only when estimating. **No-data on an on-strategy term is a first-mover opportunity**, not absence of value.
 
 **Migration planning — the move no competitor makes.** During ANY audit/strategy session check two conditions: (1) GSC data exists — a connected login OR a local Search Console CSV (`seoagent migrate` auto-detects `gsc/*.csv` and root CSVs; check before concluding "no GSC data"); (2) the audit finds a positioning mismatch between the live product and what GSC queries rank for. **When BOTH hold, running `seoagent migrate` is mandatory** — and the final response MUST include the per-asset **harvest / redirect / sunset table** with impressions/position rationale, not just a pointer to the plan. Match without mismatch → "No migration needed." No GSC data → skip silently. Full protocol: `references/migration-planning.md`.