@seoagent-official/seoagent 1.84.0 → 1.85.0

package/package.json

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

@@ -253,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.
 
@@ -724,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'"
 ```
@@ -843,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.