@seoagent-official/seoagent 1.83.1 → 1.85.0

package/package.json

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

@@ -129,6 +129,7 @@ Offer **once per session per topic**; if declined, drop it and keep working. Nev
 - **`cli_content_update`** — autopilot flagged an existing page to revise (declining GSC clicks, low CTR, or stale/thin). Reversible (edits existing content).
 - **`cli_sitemap_update`** — GSC is connected but can't fetch a sitemap at the site's `/sitemap.xml`. Write/refresh the project's sitemap (from the URL list in the file, which includes CMS-hosted articles) so Google can index it. Safe (adds/updates a sitemap).
 - **`cli_new_landing_page`** — the keyword engine flagged a high-value keyword (`easy_win` or `competitor_gap`) with no page covering it. Write a dedicated landing page targeting it. Safe (new content).
+- **`cli_draft_ready`** — the cloud already **wrote a complete article** (drafted from a brief, or generated during the user's onboarding) and synced it to `.seoagent/content/<slug>.md` in the same pull. Nothing to write — review the draft and place it where this site's content renders. Safe (new content).
 
 **Whenever the user says "process the inbox", "handle pending actions", "what's in my inbox", or anything similar**, OR whenever you see `.seoagent/inbox/README.md` reports pending actions after a sync, do this:
 
@@ -195,8 +196,13 @@ Offer **once per session per topic**; if declined, drop it and keep working. Nev
    - Publish where this project's content lives (repo `content/` or the connected CMS). Safe (new content) — but still confirm the user wants this specific page before committing.
    - Acknowledge it: `seoagent ack <action_id>` (or `--failed --reason "already covered by /existing-page"` to decline).
 
-8. After processing, run `seoagent sync` once more to clean stale inbox files and confirm everything is settled.
-9. Report a summary to the user: how many actions you applied, how many you declined (and why).
+8. For each `cli_draft_ready-<id>.md` file:
+   - `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 it: `seoagent ack <action_id>` (or `--failed --reason "not publishing; ..."` to decline).
+9. After processing, run `seoagent sync` once more to clean stale inbox files and confirm everything is settled.
+10. Report a summary to the user: how many actions you applied, how many you declined (and why).
 
 **Never delete a file without explicit user confirmation on the first action of the session.** Auto-prune is conservative (requires <5 clicks in 90 days, zero inbound internal links, etc.) but it can still surprise the user. Show them what's about to go. (Technical-fix actions edit an existing page rather than delete, so they only need a diff review, not a destructive-action confirmation.)
 
@@ -247,7 +253,7 @@ Offer **once per session per topic**; if declined, drop it and keep working. Nev
 
 2. **Check for a pull receipt.** If `.seoagent/.pull-receipt.json` exists, a previous `seoagent pull` (manual, autosync hook, or cron) brought down cloud changes that no agent has triaged yet. Handle it **before any SEO work** — see "### Pull Receipt Triage" below — then delete the receipt file.
 
-   > **Content tracking is automatic — you don't run a backstop.** Every `seoagent sync` (including the PostToolUse hook that fires after each file write) auto-tracks any *published* (`draft: false`) article in your content dir that doesn't have a pointer yet. So writing an article locally registers it on the dashboard with no extra step. The one thing that bootstraps this: the **first** article in a repo must be tracked explicitly with `seoagent content track --slug <s> --file <path>` (Phase 4 step 7) — that records the content dir, and from then on every later article auto-tracks on sync. To **clean up** drift that predates this (untracked legacy articles, or a stale pointer whose source file is gone), run `seoagent content reconcile --prune` once — it backfills all missing pointers and deletes dead ones. If `seoagent status`'s "articles" count ever disagrees with the live count, that's the command.
+   > **Content tracking is automatic — you don't run a backstop.** Every `seoagent sync` (including the PostToolUse hook that fires after each file write) auto-tracks any *published* (`draft: false`) article in your content dir that doesn't have a pointer yet. So writing an article locally registers it on the dashboard with no extra step. The content dir comes from `project.md` — `publishing.content_dir` (set it during the Publishing Target Decision) — or is inferred from an already-tracked article. Only when NEITHER exists does the **first** article need an explicit `seoagent content track --slug <s> --file <path>` (Phase 4 step 7); that call self-records `content_dir`, so it happens at most once per repo. To **clean up** drift that predates this (untracked legacy articles, or a stale pointer whose source file is gone), run `seoagent content reconcile --prune` once — it backfills all missing pointers and deletes dead ones. If `seoagent status`'s "articles" count ever disagrees with the live count, that's the command.
    >
    > **Cluster-status drift (same root cause).** Cluster files in `.seoagent/strategy/clusters/` carry a per-article `status`. When you wrote an article you set it `drafted`/`in review` — but nothing advances it once the article ships, so old `IN REVIEW (PR #…)` labels linger after the PR merges. When you read the clusters, reconcile them against reality: if a cluster lists an article as `drafted`/in-review but it's live in the repo (`draft: false`, no open PR — or it has a `content reconcile` pointer), `Edit` the cluster file to mark it `published` (or `live`). The strategy should always reflect what's actually shipped.
 
@@ -718,6 +724,7 @@ publishing:
   strategy: managed_proxy | subdomain | mdx_sync | custom | other
   cms: strapi | wordpress | sanity | contentful | webflow | shopify | ghost | payload | other  # only when strategy is custom or other
   blog_path: /blog                          # canonical URL prefix on the live site
+  content_dir: content/blog                 # repo-root-relative dir where article files live (mdx_sync — lets sync auto-track from article #1)
   setup_status: pending | done              # done = the one-time setup task is complete
   notes: "Free-text — e.g., 'rewrite added to next.config.js on 2026-04-28'"
 ```
@@ -837,7 +844,7 @@ This is the per-article procedure. When executing an approved **plan** (see "Pla
 
      `content track` writes a small **pointer** record to `.seoagent/content/{slug}.md` (slug, title, canonical, status, source) and syncs it — so the dashboard shows the article **without duplicating the body**. Do NOT also hand-write a full-body `.seoagent/content/{slug}.md`; that's the old dual-write that drifts. If `.seoagent/content/{slug}.md` **already exists** (e.g. a cloud-generated draft you just published), `content track` patches it in place: the existing `title:`, `brief:` link, `meta_description:`, and body all survive — only the fields you pass on the command line change. Pass `--brief {brief-slug}` to add/set the brief link on an article that doesn't have one.
 
-     > **After the first article, tracking is automatic.** The explicit `content track --file` above is required only for the **first** article in a repo — it records the content dir. Every later article you write is auto-tracked by the next `seoagent sync` (which the PostToolUse hook runs after each write), so you never have to remember a per-article call or run a backstop. (If you ever need to force a sweep — e.g. cleaning up legacy untracked articles — `seoagent content reconcile --prune` does it.)
+     > **Tracking is automatic when the content dir is known.** If `project.md` has `publishing.content_dir` (you set it during the Publishing Target Decision), skip the explicit `content track` entirely — the next `seoagent sync` (which the PostToolUse hook runs after each write) auto-tracks every published article, including the first one. Run the explicit `content track --file` above only when no `content_dir` is declared and no article is tracked yet; that call self-records `content_dir` so it never has to happen again. (If you ever need to force a sweep — e.g. cleaning up legacy untracked articles — `seoagent content reconcile --prune` does it.)
    - **Cloud-hosted (`managed_proxy` / `subdomain`)** — the SEOAgent cloud renders the article, so the body DOES live in `.seoagent/`: write the full article to `.seoagent/content/{slug}.md` with full SEO frontmatter (slug, page_type, title, meta_title, meta_description, canonical, og, twitter, json_ld, images, internal_links) and `seoagent sync`. (No `content track` needed — the full file is the record.)
 8. **Update the cluster's link graph** — for sub_pillar/long_tail writes, edit the parent (and the cluster file) to add the new link UP. For pillar writes, ensure all sub_pillars are referenced.