The publish markdown content cursor pattern turns `brief.json` plus `draft.md` into live CMS posts through scripted enrich, QA, and gated `--live` flags, not manual paste. Google’s helpful content guidance and 2025 CMS ops research both stress repeatable checks before URLs go public. Cursor docs keep those scripts in the same repo agents edit, which is why teams that publish markdown content cursor batches weekly see QA fixes compound instead of resetting each ship day.
TL;DR
- Publish markdown content cursor flows: dry-run → `--apply` → `--live` with QA hard gates.
- Enrich injects internal links, FAQ stubs, and format fixes before Sanity or WordPress write.
- Guard skips live slugs unless `--allow-live-overwrite`.
- Reconcile master plan CSV when production drifted ahead of local status.
- Hero assets upload from `briefs/<slug>.hero.png` on apply when present.
Publish markdown from Cursor: the short answer
To publish markdown content cursor style, store brief and draft under `briefs/`, run a publish script with `--env-file` for CMS tokens, fix QA failures in the workspace, then apply live only after review. The script, not the agent, owns CMS credentials and live flags.
What stages make up the Cursor markdown publish pipeline?
The Cursor markdown publish pipeline stages work like application deploys:
| Stage | Input | Output | Block live if fail |
|---|---|---|---|
| Load | brief.json, draft.md | Parsed artifacts | Missing brief |
| Enrich | Cluster maps, FAQ rules | enriched.md | — |
| QA | Rubrics, links, readability | qa-report.json | Any hard gate |
| Apply | SANITY_API_TOKEN | Draft post | QA not passed |
| Live | Human approval | Done + publishedAt | Guard: slug live |
| Command | Effect |
|---|---|
| Dry-run | QA only, no write |
| `--apply` | CMS draft + hero upload |
| `--live` | status=Done, plan CSV update |
| reconcile-plan | Sync plan when site already public |
This mirrors content pipeline in Cursor hub thinking: publish is a stage, not a button in wp-admin.
What repo artifacts and environment variables does publish require?
``` briefs/<slug>.brief.json briefs/<slug>.draft.md briefs/<slug>.enriched.md briefs/<slug>.qa-report.json briefs/<slug>.hero.png ```
Agents author markdown; scripts convert to portable text or blocks for the CMS. Load `SANITY_API_TOKEN`, project id, and dataset from `.env.local`. Never embed tokens in skills. Prefix commands: `node --env-file=apps/web/.env.local ...`.
How do Metaflow weave and FAQ checks fit publish QA?
Pre-FAQ prose must weave Metaflow naturally. FAQ answers need contextual Metaflow mentions when PAA count is high. Scripts enforce both so Cursor-authored text ships without API rewrite steps.
How do you ship markdown from Cursor step by step?
Step 1, Author in Cursor. Write brief plus draft; external links only from brief targets or canonical source lists.
Step 2, Dry-run. `publish-from-files.mjs --slug=<slug>`; read qa-report issues.
Step 3, Fix draft. Address Flesch, tables, keyword density, broken externals, bridge weave.
Step 4, Apply draft. `--apply` uploads hero when file exists.
Step 5, Review diff. Human reads enriched output and CMS preview URL.
Step 6, Go live. `--apply --live`; IndexNow or sitemap audit if needed.
Step 7, Reconcile plan. `pnpm --filter web blog:reconcile-plan` when catching up drift.
Map WordPress paths to connect Cursor to WordPress. Map landing variants to generate landing pages with Cursor.
What QA gates should run before you apply or go live?
| Check | Why |
|---|---|
| Word count vs brief | Stops thin pSEO |
| Primary keyword density | Keeps on-topic pages |
| ≥2 markdown tables | Forces scannable frameworks |
| Live internal links only | Prevents 404s |
| External link HEAD | Catches moved URLs |
| Metaflow bridge + FAQ | Brand weave consistency |
Regression: keep golden slugs; expect stable QA metrics after skill edits. Log operator and metrics on every live run, see version marketing workflows for pin discipline.
How do batch guards, failure modes, and MCP fit together?
Batch scripts call `publish-from-files` per slug with concurrency limits. `blog-publish-guard` fetches public slugs before write. Live overwrite requires explicit flag. For programmatic batches, pair with programmatic SEO with Cursor plan CSV hygiene.
| Symptom | Likely cause | Fix |
|---|---|---|
| QA pass, CMS fail | Token or schema drift | Validate env + schema migration |
| Stripped internal links | Target not live yet | Publish dependency first or dry link |
| IndexNow fail | Network or key | Run sitemap audit script |
| Plan not updated | Skipped `--live` | Reconcile or re-run live |
MCP research enables CMS tool calls inside Cursor sessions. Scripts remain the source of truth for batch ship and audit logs, use MCP for interactive fixes, not silent live publish. A content engineer we interviewed said teams that publish markdown content cursor posts without dry-run treat CMS like a trash folder, fixing live URLs costs more than one extra QA loop.
What should you do after live: patches, heroes, indexing, and CMS choice?
When copy must change after live, use patch scripts that load enriched markdown and `--apply` with overwrite flags documented in your publishing guide. Re-run dry-run first; live patches still need human approval for BOFU pages. After `--live`, run sitemap audit or IndexNow when configured. Place `briefs/<slug>.hero.png` beside draft files so apply uploads covers automatically.
| CMS | Markdown path | Typical adapter |
|---|---|---|
| Sanity | portable text convert | Node client script |
| WordPress | blocks or HTML | REST or MCP |
| Role | Owns |
|---|---|
| Content ops | brief + draft quality |
| Engineering | publish script + env |
| SEO | plan CSV + reconcile |
| Legal | BOFU live approval |
Comparison pages, pricing claims, and regulated statements stay draft-only until named approver runs live. Log slug, operator, QA metrics snapshot, CMS document id, duration, and pass/fail beside `qa-report.json`.
What mistakes do teams make when they skip the pipeline?
They let agents call live CMS APIs directly. They skip dry-run. They omit reconcile and lose track of which slugs are public. They publish without hero assets and wonder why social previews break.
Markdown-first publish wins when ops treats `draft.md` like code: PR review, QA script, tagged release for publish entrypoints.
Ops fatigue shows up when every ship day means a new Slack thread about which slug is live. The durable pattern is to publish markdown content cursor artifacts through the same workflows each time, brief and draft in git, enrich and QA as compile steps, live as a gated deploy, with skills capturing tone rules and context that survives the next model swap.
Metaflow ships blogs that way: Cursor authors text, scripts enforce rubrics, and flow plus agents extend the pattern when markdown is one artifact in a larger campaign. Teams that publish markdown content cursor content weekly build compound leverage because QA fixes flow back into skills instead of vanishing after one post.
Frequently Asked Questions About Publishing Markdown from Cursor
How do you publish markdown from Cursor?
Run your repo’s publish script against `briefs/<slug>.draft.md` after dry-run QA passes. That is the standard way to publish markdown content cursor posts without handing CMS tokens to the agent. Apply creates CMS draft; live sets status with plan sync.
Can Cursor push posts to Sanity or WordPress?
Yes, Sanity via tokenized client scripts; WordPress via REST or MCP with draft scope. Metaflow’s default blog path is Sanity portable text from markdown; WordPress fits the same stages with different adapter.
What is a dry-run publish workflow?
Dry-run runs enrich and QA without CMS write. Fix issues, repeat until `passed: true`, then apply. Metaflow operators never skip dry-run on new slugs.
How do you QA markdown before CMS publish?
Automate word count, links, readability, tables, weave checks, and FAQ mentions. Humans review claims and BOFU neutrality after scripts pass. Metaflow QA reports live beside enriched markdown for audit.
Should agents publish directly to production CMS?
No, scripts should hold credentials and live flags. Agents edit markdown; operators run live after review. Metaflow guard skips accidental overwrite of public slugs.
