@seoagent-official/seoagent 1.88.0 → 1.88.1

package/package.json

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

@@ -88,10 +88,12 @@ 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>` — pulled in the same sync that delivered this task.
+- **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`
 

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.