Tengence GEO Agent

Assemble a ready-to-use writing brief for a new article: the matched T1–T7 body skeleton, the pre-writing research-brief template, and the full writing standard (base + supplement). The body you author MUST follow this brief; the check_article gate enforces the same G1–G14 editorial gates before publishing. Call this first, then write the Markdown body, then check_article.

Export an article md + brief from the DB to the site data/inbox (for rewriting)

Content ingest (single entry): body md + research brief → articles table (CLI canonical orchestration)

List articles (articles table), with status/limit filters

Validate a title/body against a platform's style rules — the 校验 (validation) half. Deterministic, no content generation. Returns errors (HARD: title length / forbidden words / body length / removeBlocks) and warnings (SOFT: CTA presence / internal links / keepBlocks) plus the platform checklist and rewrite.strategy. Run AFTER rewriting to confirm it passes before channel_publish. Platform-scoped (wechat / juejin / blog / any registry platform).

List all external content platforms in the syndicate registry: API type (official|cookie|none), status (ready|pending|manual), capabilities (multi-article merge, per-platform limits, draft/cover/tags) and the full platform rewrite rules (styles). The rewrite rules are the HARNESS rewriting guide — the server never rewrites content: read the original via article_export, apply these rules yourself, then channel_publish to land the draft/export. READY PLATFORMS: wechat (微信公众号, official API), juejin (掘金, cookie — can publish article drafts) and csdn (CSDN, cookie — the creator-console gateway; needs CSDN_COOKIE before status becomes ready). To publish to Juejin/CSDN pass platform="juejin"/"csdn" to channel_publish / channel_plan_*; this server is multi-channel.

Update a channel_plan row status (todo | draft | published | paused) and optionally record its draft ids (media ids). Call after channel_publish to persist the created draft (e.g. wechat media_id) and keep the calendar in sync.

Per-platform publishing calendar: return the next article to publish for a platform plus all calendar rows (status/period/topic/weekday/slugs). Each platform has its OWN rows in the same channel_plan table. wechat keeps a real per-issue calendar (returns the earliest row still todo). juejin / csdn (and other api platforms) treat the table as a PUBLISH LOG — nextDue is DERIVED from the blog article_plan: it returns the next blog-published article (by publish_order) that is NOT yet recorded as published on THAT platform, so each platform's queue follows the blog order and resumes right after the last article published to it (failed rows retry). Nothing is ever bulk-copied from the blog plan: only real outcomes are recorded, so juejin and csdn each keep their own independent calendar in the shared table. Seed already-published articles with channel_plan_reconcile (platform=csdn) before the first nextDue, otherwise the csdn queue starts from the very first blog article.

Reconcile a platform channel_plan with what is ACTUALLY published on that platform (platform=juejin | csdn). This SEEDS the publish log with already-published articles — we do NOT bulk-import the blog plan (the table only logs real outcomes, so each platform keeps its own calendar). Pass map[] of {slug, title?, blogOrder?} for the explicitly-known published articles (recommended — avoids API rate limits), or omit map to live-read the platform published list and match titles back to blog slugs. Idempotent (upsert by slug). Run this once per platform before the first channel_plan_next so the already-published articles are skipped instead of re-published.

Publish/export to one external platform. Mode A: pass slugs[] and the server reads the DB and runs the platform pipeline (wechat drafts box — preview in mp.weixin.qq.com before mass-sending; juejin draft → publish; csdn draft → publish; devto publish). Mode B: pass pre-written articles[] ({slug,title,contentMd,summary,tags,sourceUrl,cover}) — the harness-rewritten draft — and the server exports a publish package to <site>/data/channel-export/<platform>/<slug>.md with full front matter (manual publishing on every platform; required for api:none platforms). asDraft defaults true (never mass-sends). PLATFORMS: wechat, juejin (cookie — 原文直发 via juejin draft), csdn (cookie — 通过创作中心网关一步发文), devto. Juejin pipeline: reads DB article → resolves category/tags against the cached platform dictionary (channel_taxonomy; our article_plan.category/tags → the platform's category_id/tag_ids — see channel_taxonomy_resolve) → creates draft → writes body → publishes; dryRun=true previews the plan AND the resolved taxonomy with no external calls; idempotent — skips a slug already on Juejin (draft or published). Category and tag are both required by Juejin, so a fallback chain (alias → dictionary → env → dictionary default) guarantees both are always sent. CSDN pipeline: reads DB article → Markdown is converted to CSDN HTML locally (CSDN does NOT convert server-side) → one saveArticle call (status 2=draft / 0=publish); tags come from article_plan.tags else target_keywords (1~5 required to publish). Idempotent through the SAME slug-based dedup as juejin. Every publish outcome is logged to channel_plan under its own platform, so each platform keeps an INDEPENDENT publishing calendar (only real outcomes are recorded — the blog plan is never bulk-imported). This server is multi-channel; choose by platform=.

Return the FULL platform style / rewrite rules for ONE platform (wechat / juejin / blog / …). This is the RULES half of the rewrite surface: the server only serves the rules, the harness/Skill does the actual rewriting. Covers rewrite.strategy (source|title|body|both — what to change), title hooks + forbidden words, body structure + style, internalLinks requirement, cta and the acceptance checklist. ALWAYS call this BEFORE rewriting an article for a platform so the latest rules are used (never hardcode rules in the client). Multi-channel: pick by platform=.

Read the cached external-platform taxonomy dictionary (channel_taxonomy) — the platform's OWN categories and tags with their ids. Filter by kind (category|tag); look one up exactly with name=, or by prefix with prefix= (prefix lookups use the NOCASE index; infix/contains search is NOT index-accelerated, so do it client-side over this list). Use it to see which platform tags exist before choosing an alias.

Preview how OUR taxonomy maps onto a platform's (article_plan.category/tags → platform category_id/tag_ids) WITHOUT publishing. Returns the chosen ids/names plus a per-item origin showing which fallback layer fired (alias / exact / token:<kw> / fuzzy / default / env / first / hardcoded). Use it to sanity-check a mapping before a real publish; it never makes external calls and never writes.

Refresh the cached dictionary of an EXTERNAL platform's own taxonomy (category + tag id/name) into the workspace table channel_taxonomy. Currently juejin: 8 categories + ~725 tags fetched from the platform APIs. The dictionary is PLATFORM-scoped, shared by every site — a site publishing to Juejin needs NO mapping file of its own. It is used to map our article_plan category/tags onto the platform's category_id/tag_ids at publish time. Idempotent (upsert by platform id); publish auto-runs this once when the dictionary is empty, so calling it manually is only needed to refresh after a platform word-list change. Names are indexed for exact/prefix lookup (infix search runs in memory). Requires JUEJIN_COOKIE in the site .env. Read-only on the platform — it fetches lists, it does not publish.

Publish gate: enforces the editorial rules codified in the "article-writing-standards" standard (citation dual-channel, word count by T1–T7 type, banned words, the three GEO blocks — Summary / Key Takeaways / FAQ / Data Sources — and the research-brief hard check). Read that standard via standards_read before authoring, and run article_draft first to scaffold per-spec.

Delete a CSDN article (blog/phoenix/console/v1/article/del). IRREVERSIBLE — pass confirm=true only after verifying the article id via csdn_status. Requires CSDN_COOKIE in the site .env. NOTE: this removes it from CSDN only; the local channel_plan publish log (the CSDN publishing calendar) is not touched — re-run channel_plan_reconcile(platform=csdn) afterwards if you want the log back in sync.

Read the CSDN blog backend for this site: the draft box and the published list (blog/phoenix/console/v1/article/list with status=draft / all_v2). Read-only. Requires CSDN_COOKIE in the site .env. Use it to verify before publishing (idempotency) and to see what is already on CSDN. page is 1-based (default 1). An expired login is surfaced as cookieExpired=true + code 401 instead of an empty list — renew CSDN_COOKIE then. This is the CSDN counterpart of juejin_status.

Explicitly initialize the database (sqlite idempotent table creation / mysql DDL; --drop rebuilds)

Database status: driver, path, schema version, table list, missing tables

Full GEO/SEO site diagnosis: domain (DNS/TLS cert/WHOIS), transport & server fingerprint (CMS/framework/platform/CDN), robots.txt, sitemap, homepage + representative pages (meta, H1..H6 structure, JSON-LD, OG, images/alt, links, mixed content), performance and security checks. Bootstraps the site on first use (url → site key, dots → underscores).

Auto image pipeline (search → red-line filter → download → WebP crop → upload to WP media library)

Delete a published Juejin article (article/delete). IRREVERSIBLE — pass confirm=true only after verifying the article id via juejin_status. Requires JUEJIN_COOKIE + JUEJIN_UID in the site .env.

Delete a Juejin draft (article_draft/delete). IRREVERSIBLE — pass confirm=true only after verifying the draft id via juejin_status. Requires JUEJIN_COOKIE + JUEJIN_UID in the site .env.

Read the Juejin (掘金) backend for this site: the draft box (article_draft/list_by_user) and the published list (article/list_by_user). Read-only. Requires JUEJIN_COOKIE + JUEJIN_UID in the site .env. Use it to verify before publishing (idempotency) and to see what is already on Juejin. page defaults to 0 (50 per page).

Read monitoring results (latest round or a given run_id)

Run GEO monitoring (one round of site prompts × models; results persisted)

Import/update the plan table from the site plan directory (idempotent)

Article plan table list (status/batch/category/node filters)

Update a plan row status (todo/written/queued/published/archived)

Run the daily promotion task (promotes due drafts to publish by plan publish_order; default 1/day). Optional date sets the promoted article publish/modified time (YYYY-MM-DDTHH:MM:SS, site timezone).

Publish a draft (default draft → WP; can --status=publish directly, must pass the gate first)

Publish an article from the DB to WordPress (--force updates an existing article)

Bypass update of an existing article (title/content/status + sync SEO/GEO meta). When meta_title / meta_description / post_title is provided, runs meta-only mode: updates ONLY those fields (meta_title → DB seo.title + WP seo_meta_title; meta_description → DB seo.meta_description + WP seo_meta_description, 165–175 chars hard gate; post_title → DB title + WP post_title itself); body/content/status/excerpt untouched.

Write a Markdown report into the site data/reports/ directory (path-safe: filename is basenamed and confined to the reports dir). Auto-bootstraps the site on first use.

Query one URL's Google indexing status (URL Inspection API, read-only): verdict, coverageState, indexingState, lastCrawlTime, googleCanonical. Use it to check whether a specific article page is indexed. Quota: 2000 calls/day.

Read Google Search Console Search Analytics data: clicks / impressions / CTR / average position, grouped by query (default), page, date, country or device. This is the ONLY Google source for search performance — and the only source at all for page-level data (Bing dropped its page/traffic endpoints on 2026-08-31). GSC data is finalised 2–3 days late: the default window is the 28 days ending 3 days ago. Requires the GSC service account (secrets/gsc-service-account.json or GOOGLE_SA_JSON).

Submit URLs to Baidu normal inclusion (requires BAIDU_TOKEN / BAIDU_SITE). Two modes: pass url for an explicit list, or all=true to push the sitemap incrementally — it recursively flattens sitemap_index.xml, skips every URL already logged as submitted in data/baidu-log.jsonl, and pushes at most limit URLs (default 10) so a scheduled run stays inside the daily quota.

Submit the sitemap to Google Search Console (soft-fail)

Submit URLs to IndexNow (requires INDEXNOW_KEY)

Scaffold a site inside the bound workspace: <workspace>/<key>/{config,data/inbox,data/reports,.env} (idempotent, never overwrites existing files)

List the sites inside the bound user workspace (site key, domain, app_id, storage driver). Returns a hint instead when no workspace is bound yet.

Site status: config paths, .env readiness, DB driver and SQLite init state

List the generic writing & GEO standards shipped with the engine (titles, whether a site-specific supplement exists). Read one with standards_read before authoring an article; see article_draft for a ready-to-use brief.

Read a generic standard document (base + any site-specific supplement merged). Names are repository-relative without `.md`, e.g. "article-writing-standards", "content-strategy", "block-conventions", "templates/skeletons/howto", "templates/research-brief". This is the canonical way to pull the requirements an article must satisfy.

Connectivity self-check: SDK version, driver, internal data directory, bound workspace and site count

Read Bing Webmaster console data (verified sites / URL submission quota / query stats / crawl issues). Requires BING_WEBMASTER_API_KEY in the site .env. Note: Bing trimmed its JSON API on 2026-08-31 (GetPages/GetSitemaps/GetTrafficStats/GetUrlSubmissionStatus now 404).

Write to Bing Webmaster: submit URL(s) (comma-separated = batch, ≤10000 per call). Requires BING_WEBMASTER_API_KEY in the site .env.

Delete a published article (freepublish/delete, article_id from wechat_status published). IRREVERSIBLE — verify the article_id first; index (1-based) deletes one article of a multi-article message, omit to delete the whole message.

Publish a draft box media_id to the account homepage via freepublish/submit (NO push to followers — the draft is consumed and moves to the published list, where it is visible in the account homepage). Use for the "发布" step; mass push (推送粉丝) is a separate tool wechat_mass_send.

Send a draft (media_id from the draft box) to one user as a preview (message/mass/preview). Requires a verified account; pass openid (touser) or wxname (towxname). Use this to check layout before mass-sending.