@seoagent-official/seoagent 1.108.6 → 1.110.0

package/package.json

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

@@ -5,7 +5,7 @@
 **Golden rules (these also live in the skill body):**
 
 - **Never delete a file without explicit user confirmation on the first destructive 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.
-- **Standing approval.** While the site is in auto-approve mode (the SEOAgent default), the cloud stamps each item it queues, and its file's steps then say **Standing approval applies**. Do that work without waiting for a go-ahead: with no one in the session (a scheduled run, a Grok Bot, a headless run) apply it, commit it, and ack it; with a person present, show the diff or draft as you go and carry on. It is a go-ahead, not a quality waiver: decline anything that looks wrong. Prunes (destructive) and new landing pages (a new URL) never carry it, and a file without it keeps its own confirm step.
+- **Standing approval.** While the site is in auto-approve mode (the SEOAgent default), the cloud stamps each item it queues, and its file's steps then say **Standing approval applies**. Do that work without waiting for a go-ahead: with no one in the session (a scheduled run, a Grok Bot, a headless run) apply it, commit it, and ack it; with a person present, show the diff or draft as you go and carry on. It is a go-ahead, not a quality waiver: decline anything that looks wrong. Prunes (destructive) never carry it, and a file without it keeps its own confirm step.
 - **Read the decline memory first.** `.seoagent/inbox/README.md` ends with **Previously declined on this site** (also `declined` in `seoagent inbox --json`, and a **Related past declines** block inside any action file an earlier decline bears on): what you or a previous session already refused here, and why. A pending action that one of those reasons still covers (same page, same class of problem — e.g. the page is `noindex`, so canonical, meta and schema on it are all inert) is **declined citing that reason, not re-investigated**: `seoagent ack <id> <id> … --failed --reason "covered by #<earlier id>: <its reason>"`. Several ids take one verdict. Only apply a fix when the earlier reason no longer holds.
 - Acknowledge every action you finish: `seoagent ack <action_id>` (or `seoagent ack <action_id> --failed --reason "..."` to decline). That marks it `completed` on the dashboard and removes the inbox file on the next sync. **Write decline reasons for your future self**: state the fact that rules the action out (the page is noindex; the canonical points off-site; the finding is stale since <date>) — every decline is fed back into the next inbox as memory, and the issue is not proposed again.
 - After processing, run `seoagent sync` once more to clean stale inbox files, then report a summary: how many applied, how many declined (and why).
@@ -27,6 +27,7 @@
 | `cli_draft_context` | Business context is missing while suggested keywords wait on the relevance judge — draft `.seoagent/context.md` | Safe (repo-local file) |
 | `cli_run_audit` | The full technical audit is stale (≥7 days) or has never run — re-run Skill Phase 1 and sync | Safe (read-only crawl + report) |
 | `cli_outreach_drafts_ready` | Outreach email drafts await the owner's review on the dashboard — tell the user, then ack | Safe (informational) |
+| `cli_submit_listing` | The owner approved a directory listing submission (or correction) on the dashboard — fill the directory's form **in a browser** with the facts given | **Outward-facing — owner-approved; stop at any account, CAPTCHA or payment** |
 
 ## Per-type procedure
 
@@ -93,9 +94,9 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 - `Read` it. The frontmatter has `action_id`, `keyword`, `opportunity` (`easy_win` | `competitor_gap`), `volume`, `difficulty`, and `intent`. The body explains why this keyword is worth a page.
 - Cross-reference the site's keyword inventory for related keywords — they tell you which cluster this page belongs to and which secondary keywords to weave in. It is `.seoagent/strategy/keywords/*.md` once the cloud shards it, and `.seoagent/keywords.md` otherwise; a synced workspace usually has only one of the two. **The action file names the files this workspace actually has — use those.** Do not assume a file named after the cluster in the rationale exists: a keyword whose cluster has no article role assigned yet is written to `strategy/keywords/unclustered.md`, so search the directory for the keyword rather than opening `<cluster>.md`.
 - Pick an article type from `intent` (commercial/transactional → product or comparison page; informational → guide or pillar). Pick a clean URL slug from `keyword`.
-- Write the article following the content-production protocol (Phase 4 — match the article type's quality rules, add internal links from related cluster pages, etc.). Show the user the draft before publishing (interactive sessions can use the visual review loop — `references/draft-review.md`).
+- Write the article following the content-production protocol (Phase 4 — match the article type's quality rules, add internal links from related cluster pages, etc.). Follow the file's go-ahead step: **Standing approval** → publish, commit, ack; otherwise show the user the draft before publishing (interactive sessions can use the visual review loop — `references/draft-review.md`).
 - **If the action body has a "Screenshots to capture" section** (SaaS product), follow `references/screenshots.md` — a landing page for a SaaS product should lead with a real product screenshot in the hero + feature sections, captured from this repo's UI.
-- 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.
+- Publish where this project's content lives (repo `content/` or the connected CMS). Safe (new content). Without **Standing approval**, confirm the user wants this specific page before committing.
 - Acknowledge: `seoagent ack <action_id>` (or `--failed --reason "already covered by /existing-page"`).
 
 ### `cli_draft_ready-<id>.md`
@@ -139,3 +140,12 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 - **Informational — nothing to change in this repo.** The backlinks autopilot drafted link-building emails, but only the owner can approve outreach, and the approval queue lives in the SEOAgent dashboard (the site's **Outreach** tab, drafts filter). Tell the user how many drafts await and where; each shows the prospect page, pitch angle, and the exact email text (edit / approve / dismiss).
 - Approved drafts return to this inbox as `cli_send_outreach_email` actions for delivery.
 - Acknowledge after surfacing it: `seoagent ack <action_id>`. Decline (`--failed --reason "not now; ..."`) if the user isn't interested — the reminder returns only when the awaiting count changes on a later weekly run.
+
+### `cli_submit_listing-<id>.md`
+
+- `Read` it. The frontmatter has `action_id`, `directory`, `mode` (`add` or `correct`) and `listing_id`; the body has the form URL, the business facts, and the verification the directory is expected to ask for.
+- **Needs a browser.** Nothing in this repo changes. If you have no browser tool, tell the user and leave the action pending — do not ack.
+- The owner already approved it (the **Submit for me** click on the Local tab). Enter **only** the facts given; leave optional fields empty when there is no fact; never invent amenities, rates or photos.
+- **Stop and decline** if the form asks for an account, a sign-in, a CAPTCHA, a payment, or any agreement beyond submitting the listing, or if a required field has no fact: `seoagent ack <action_id> --failed --reason "<what blocked you>"`. The reason becomes the owner's to-do on the dashboard.
+- Submitted: `seoagent ack <action_id> --url "<listing URL, if shown>"` → the listing goes to `submitted`; the next NAP audit marks it live once it appears.
+- The directory says the owner must verify (code, postcard, call, email): `seoagent ack <action_id> --verify "<what the owner must do>" --verify-type code|postcard|call|email` → the listing goes to `pending_owner_verification` and the dashboard shows the to-do. SEOAgent never receives the code.