@seoagent-official/seoagent 1.88.0 → 1.88.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.88.0",
+  "version": "1.88.2",
   "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/inbox.md

@@ -88,10 +88,13 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 
 ### `cli_draft_ready-<id>.md`
 
-- `Read` it. The frontmatter has `action_id`, `article_slug`, `path`, and (when drafted from a brief) `brief_slug`. The draft itself is at `.seoagent/<path>` — pulled in the same sync that delivered this task.
-- **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. The inbox file body walks through each strategy.
-- Edit freely before publishing — the `.seoagent` copy is the user's now. Show the user the draft before publishing.
-- Acknowledge: `seoagent ack <action_id>` (or `--failed --reason "not publishing; ..."`).
+- `Read` it. The frontmatter has `action_id`, `article_slug`, `path`, `mode`, and (when drafted from a brief) `brief_slug`. The draft itself is at `.seoagent/<path>`.
+- **Believe the task's own delivery line, not the word count.** It says either "pulled in the same sync that delivered this task" or "**NOT delivered by this sync**". The second means the pull kept your local copy and the cloud draft never reached disk: read the local file, then run the `seoagent sync --force <path>` the task prints to take the cloud version for that one file. Never publish a file whose body is a `Tracked record` pointer stub — that is the tracking placeholder, not the article.
+- **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.
+- **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).
 
 ### `cli_send_outreach_email-<id>.md`
 
@@ -100,7 +103,7 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 - **Confirm once per session** before the first outbound email (show recipient + subject); then send subsequent approved emails without re-prompting. Send **verbatim** — no added signature, links, or attachments; the one allowed edit is fixing an obviously wrong greeting name.
 - No `to_email`? Check the prospect page for the author's address or a contact form — a form submission with the body text counts as sent.
 - Acknowledge after sending: `seoagent ack <action_id>` — the dashboard marks the draft **sent** and the prospect **contacted**. Declining (`--failed --reason "not sending; ..."`) dismisses the draft. A transient tooling failure should NOT be acked — leave it pending and it returns next sync.
-- **No email tooling available at all?** Leave the action pending and tell the user what tooling would enable sending (or that they can send manually from the dashboard's drafts queue).
+- **No email tooling available at all?** Leave the action pending and tell the user exactly how to fix it: connect an email connector to this coding agent — e.g. the Gmail connector/MCP in Claude Code (Settings → Connectors, or `claude mcp add`) — or they can send manually from the dashboard's Outreach view.
 
 ### `cli_draft_context-<id>.md`
 

package/skills/references/publishing.md

@@ -96,6 +96,7 @@ The publishing strategy decides where an article's **body** is written. Never wr
 - **`mdx_sync` / `custom`** — the body lives in the **repo file or CMS entry**, NOT in `.seoagent/`. Match the site's existing frontmatter and content model exactly (read an existing article first). Tracking is automatic once `publishing.content_dir` is set: the next sync registers the file. Only when no content dir is declared *and* nothing is tracked yet, run once:
   `seoagent content track --slug {slug} --url https://{domain}{blog_path}/{slug} --file {path}`
   (it self-records `content_dir`). **Never hand-write a duplicate full-body `.seoagent/content/{slug}.md`** — two copies of one article drift, and the sync then reports both.
+  **Publishing a cloud-delivered draft under a different slug?** Add `--supersedes {the-delivered-slug}` (and `--action {action_id}`). Renaming a generated slug is good editorial practice, but `content track` keys on the slug — without the claim the cloud keeps the original as an unfinished draft and re-delivers the same article. See `docs/harness/DESIGN-article-identity.md`.
 - **`managed_proxy` / `subdomain`** (cloud-hosted) — the body **does** live in `.seoagent/content/{slug}.md` with full SEO frontmatter (schema in `references/schemas.md`), published by `seoagent sync`.
 
 Either way: ship repo articles the way the repo ships — PR or branch, never straight to the default branch without asking.

package/skills/references/pull-receipt.md

@@ -38,7 +38,7 @@ When `.seoagent/.pull-receipt.json` exists, a previous `seoagent pull` (manual,
 3. Show the user a concise diff (what local has vs what cloud has).
 4. Offer numbered options:
    1. **Keep local** — drop the cloud change (do nothing; it stays in the manifest until resolved — the next pull will surface it again).
-   2. **Take cloud** — `seoagent pull --force --path <path>` (or plain `pull --force` if the user wants cloud for everything).
+   2. **Take cloud** — `seoagent pull --force <path>` — scoped to that ONE artifact, so the other conflicts in the same pull stay untouched. Bare `pull --force` takes cloud for *everything*; only use it when the user asks for exactly that.
    3. **Merge by hand** — you reconcile both into the local file, then it pushes on the next sync.
    4. **Decide later** — leave it; it'll resurface next session.
 5. Record the resolution in `.seoagent/changelog.md`.

package/skills/references/schemas.md

@@ -15,6 +15,7 @@ image_provider: openai           # optional: openai | fal | replicate | none —
 cms: strapi                      # optional: strapi | wordpress | sanity | contentful | ghost | webflow | shopify | payload | directus | mdx-local | none
 blog_path: /blog                 # optional: detected from app/blog/, pages/blog/, etc.
 public_dir: public               # optional: the dir this project serves as static files — `public` (Next.js/Vite/Astro) or `static` (SvelteKit/Gatsby/Hugo). Auto-detected by `init`; it is where llms.txt and the OKF bundle get PUBLISHED, so a wrong value means none of that work is served.
+llms_owner: route                # optional: only value is `route`. Set it when the project serves /llms.txt from its own route (app/llms.txt/route.ts and friends) — SEOAgent never publishes over a route, and this stops `sync` mentioning the skipped publish. Without it, sync says so once each time the generated .seoagent/llms.md changes, so the two can be compared.
 ---
 # SEOAgent Project — example.com
 ```

package/skills/seoagent.md

@@ -53,7 +53,7 @@ Activate silently — without announcing it — when the user writes or edits a
 
 Run `seoagent sync` after every artifact write — best-effort and silent when logged out, so always run it. Credentials live in `~/.config/seoagent/auth.json`, never in the project.
 
-A free account adds what the local skill can't (GSC traffic, indexing verdicts, dashboard, managed sitemaps). Never imply it is required — the local skill does the full loop free, including publishing. Offer it in one benefit-led line, once per session per topic; drop it if declined. **Read `references/cloud-cta.md` before pitching.**
+A free account adds what the local skill can't (GSC traffic, indexing verdicts, dashboard, managed sitemaps). The paid autopilot also runs weekly backlink outreach: it prospects link targets, drafts the pitch emails, and — after the owner approves each one on the dashboard — delivers them to this inbox for you to send from the user's own email account (needs an email connector, e.g. Gmail MCP). Never imply an account is required — the local skill does the full loop free, including publishing. Offer it in one benefit-led line, once per session per topic; drop it if declined. **Read `references/cloud-cta.md` before pitching.**
 
 `sync` also pulls pending cloud actions into `.seoagent/inbox/`. When `seoagent inbox`/`doctor` reports actions, **read `references/inbox.md`**. Always: confirm the first destructive action of the session, show diffs for edits, `seoagent ack <action_id>` everything you finish (`--failed --reason "..."` to decline), then sync.