@seoagent-official/seoagent 1.54.0 → 1.56.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Baxter Inc
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -74,10 +74,26 @@ The scaffolded sync hook uses `npx -y @seoagent-official/seoagent sync --silent`
 
 Then open Claude Code in this repo and say *"audit my site."* The skill takes it from there.
 
-<!-- Claude Code marketplace install is wired (the mirror serves the plugin
-     tree) but intentionally NOT documented here yet — holding promotion
-     until the plugin-install → init flow is validated end-to-end. Restore
-     the marketplace install section once that's confirmed. -->
+### Option C — Plugin marketplace (Claude Code or Codex)
+
+Prefer to discover and install from inside your agent? SEOAgent ships a plugin marketplace. The plugin is a thin **bootstrap**: installing it adds a `seoagent-cli-setup` skill that walks the agent through the one-time npm `init` above — which lands the full skill bundle + `.seoagent/` workspace. So you still end up in the same place as Options A/B; this is just a discovery path.
+
+**Claude Code:**
+
+```text
+/plugin marketplace add Baxter-Inc/seoagent-npm
+/plugin install seoagent-cli-bootstrap@seoagent-official
+```
+
+**Codex** (requires a Codex version with plugin support):
+
+```bash
+codex plugin marketplace add Baxter-Inc/seoagent-npm
+# then open the plugins list and install SEOAgent:
+codex /plugins
+```
+
+Then tell the agent *"set up SEOAgent"* — it runs `init`, installing the skill to `.claude/skills/seoagent/` (Claude Code) or `.agents/skills/seoagent/` (Codex / Cursor), symlinking the other location so both agents discover it.
 
 <!-- `npx skills add Baxter-Inc/seoagent-npm` is also wired (build.ts step 6b
      emits skills/seoagent/SKILL.md at the mirror root for the Vercel `npx skills`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.54.0",
+  "version": "1.56.0",
   "description": "The persistent AI SEO agent for Claude Code. Audits, keyword strategy, briefs, articles, and the autopilot loop (cloud detects → CLI executes → ack closes) — other SEO tools write the prompt, SEOAgent runs it.",
   "type": "module",
   "bin": {
@@ -9,7 +9,8 @@
   "files": [
     "index.js",
     "skills",
-    "assets"
+    "assets",
+    "LICENSE"
   ],
   "engines": {
     "node": ">=18"
@@ -29,6 +30,12 @@
     "claude-code",
     "claude-skill",
     "claude-agent",
+    "agent-skill",
+    "agent-skills",
+    "anthropic",
+    "codex",
+    "cursor",
+    "windsurf",
     "ai-agent",
     "ai-seo",
     "aeo",

package/skills/seoagent.md

@@ -494,6 +494,12 @@ Articles need a working place to live before they're worth generating. The good
 
 SEOAgent Cloud *hosting* (option C below) exists only as a convenience for users who have **no** content home and no engineering resources — it is NOT the default. Never lead with it.
 
+> **Guardrail — the "DB-backed / headless blog with no repo files" trap.** Some sites have a blog *route* (`app/blog/[slug]/page.tsx`, `/posts/[slug]`, …) that renders rows from a **database or headless store** — the app's own Postgres/Supabase, an internal admin API, a headless setup — while the **repo contains no content files** for it. When you find this, an existing route + a live `/blog` does NOT mean you've found the publishing path. Do **NOT**:
+> - **write directly into that production database** (e.g. an `INSERT` via an MCP/SQL tool) — that's not how the app publishes, it bypasses every safeguard, and it's usually read-only anyway; and
+> - **assume SEOAgent Cloud (or a "dashboard") will publish it** — the cloud does not publish to the user's own site. Never invent a publishing mechanism you haven't verified.
+>
+> Instead, **the default recommendation is to make the blog repo-native: add a git-based Markdown/MDX content collection** (option A) — a `content/blog/` dir the route reads from — so publishing becomes a reviewed commit, no extra services. If the user would rather keep the DB/headless setup, **ask them how a post actually gets created** (which API endpoint or command produces a live page) and record it as option B / `other` — never guess. When a site has no working content home at all, **recommend creating a Markdown collection as the default**, ahead of adopting a CMS or the cloud.
+
 **Trigger this section when:**
 - Phase 1 raised a `critical` `upstream_dependency_unreachable` or `page_renders_empty` finding on a content path (e.g., `/blog`, `/docs`, `/resources`)
 - `project.md` has no `cms` and no `blog_path`, and the user wants to start publishing
@@ -507,6 +513,7 @@ Figure out the destination from the codebase first (you usually already know it
 The site renders content from files in this repo (Next.js `content/`, Astro `src/content/`, a `_posts/` dir, MDX routes, a static-site generator, etc.).
 
 - **How you publish:** **Read an existing published article first** to learn the exact location, filename convention, and frontmatter shape this site expects. Then write `.seoagent/content/{slug}.md`'s content into a new file in that same location, matching that frontmatter exactly (their field names, their date format, their tags). Inject internal links + image refs. If a route/sitemap entry is needed and missing, add it.
+- **First post / just-converted blog (no existing file to copy):** if the content dir is empty — a brand-new blog, or one you're converting from a DB/headless source per the guardrail above — define a simple frontmatter convention yourself (`title`, `description`, `date`, `tags`, `slug`) and, if the route doesn't yet read from files, scaffold the loader + route to read the content dir (this is the one-time setup task in "After the user picks", tracked with `setup_status: pending` until it deploys).
 - **Ship it the way the repo ships:** open a PR (or commit to a branch) so the user's existing CI/CD deploys it. Never push straight to the default branch without asking.
 - **Best for:** any site whose content is in version control. This is the most common case and the highest-control path.