A complete AI content workflow for Ghost separates editorial judgment from CMS authority. The AI can research, organize evidence, draft, validate, and prepare a reviewed article package. A bounded Ghost integration can then create a draft, apply approved changes, publish or schedule an exact item, trigger deployment when required, and verify the public result.
The workflow is controlled because no single instruction owns every stage. Research does not imply approval. Draft approval does not imply publishing permission. A successful Ghost status change does not imply that a headless frontend is live.
Key points
- Use a repeatable editorial procedure for research, evidence, structure, metadata, and validation.
- Check the publishing site before creating a new article.
- Approve target questions, material claims, proprietary evidence, and the outline before expensive drafting.
- Keep Ghost draft creation draft-only and bind edits to current revisions.
- Require separate confirmation for scheduling, publishing, unpublishing, and deployment.
- Verify Ghost state, deployment state, and the rendered public page independently.
- Record receipts and remaining uncertainty instead of claiming that every successful call completed the whole workflow.
The seven layers of an AI content workflow for Ghost
A production workflow becomes easier to reason about when it is divided into layers with different responsibilities.
- Brief layer: audience, market, keyword, reader job, voice, CTA, product truth, and proprietary evidence.
- Research layer: existing-site coverage, search intent, current sources, target questions, and content gap.
- Editorial layer: outline, claims, article pattern, draft, metadata, images, and validation.
- Review layer: human approval of evidence, positioning, wording, risk, and the exact revision.
- Ghost action layer: reads, drafts, images, metadata changes, schedules, and publication transitions.
- Delivery layer: optional headless build, revalidation, cache update, or deploy hook.
- Observation layer: revision receipts, audits, public checks, and performance monitoring.
The workflow can use different products at each layer. The important requirement is that the handoff between layers is explicit and reviewable.
Stage 1: create a source-backed content brief
The workflow begins with a real assignment, not a request to “write an SEO article.” Define the publishing domain, primary keyword, target audience, market, language, reader job, voice, prohibited language, CTA, author context, and required delivery format.
Supply product facts from approved documentation and identify any proprietary evidence the article is expected to use. Proprietary evidence may include an implementation log, internal result, test, interview, customer workflow, or first-hand observation. The AI must not invent it.
A complete brief also defines what should happen when evidence is missing: block the assignment, narrow the claim, or leave a visible editorial placeholder and keep the package in draft status.
Use the source-backed SEO brief guide to structure the inputs before research begins.
Stage 2: research the site and current search intent
Research starts on the publishing site. Search for the primary keyword, close variants, and pages serving the same reader job. If an existing article already satisfies the intent, the correct action may be a refresh, consolidation, redirect, or a narrower angle.
Then review the most relevant organic results. Record their format, audience, target questions, sources, methodology, freshness, useful visuals, and important omissions. Competitors reveal expected coverage; they should not become the published article’s evidence.
Classify the intent as informational, commercial investigation, transactional, navigational, or mixed. The classification determines how quickly the article should answer the main question, how much proof is required, and where a product CTA belongs.
Build a list of target questions and a defensible information gap. “Longer than competitors” is not a gap. A current source, clearer implementation, fair comparison method, real test, overlooked risk, or reusable decision framework can be.
The broader AI SEO content workflow explains how first-party search data can inform this stage without being treated as a guaranteed ranking cause.
Stage 3: approve questions, claims, and the outline
Before drafting, list the material claims the article expects to make. Classify each as primary-source fact, secondary-source fact, proprietary evidence, user-provided information, calculated result, editorial analysis, or unverified.
Use a claim ledger with the claim, source, verification date, scope, limitation, and status. Unverified material claims should remain visible and block a publish-ready label.
Choose an article pattern that matches the reader’s job. A definition guide, setup tutorial, comparison, best-of roundup, alternatives page, pillar guide, and refresh require different structures and proof.
The approval package should include title options, search intent, target questions, content gap, proprietary evidence, material claims, unresolved unknowns, proposed H2 and H3 outline, internal-link targets, and CTA.
This is the first major human gate. It is much cheaper to reject a weak angle or unsupported claim before a complete article has been written.
Stage 4: draft and validate the article package
The draft should answer the main question early, use clear headings, preserve source scope, and distinguish features, benefits, evidence, and analysis. Every section should add new information instead of repeating the same claim in different language.
A complete article package includes:
- title, slug, meta title, meta description, and CMS excerpt;
- article body with logical H2 and H3 hierarchy;
- verified internal links and descriptive anchors;
- FAQs based on real long-tail questions;
- cover and in-article image recommendations with alt text;
- numbered references mapped to material claims;
- a blocked, draft, or publish-ready status.
Run deterministic checks for structure, metadata lengths, headings, citation numbering, duplicate FAQs, image fields, and unresolved placeholders. Code can detect mechanical defects; it cannot prove that evidence supports the prose.
The Source-Backed Blog Writer packages this editorial procedure as a portable Agent Skill. It prepares content but does not authorize a CMS.
Stage 5: complete the human editorial review
Human review should examine the exact revision that may move downstream. Reviewers should not approve a summary while the CMS receives a different or later draft.
Prioritize high-risk content: numbers, dates, quotations, product behavior, competitive comparisons, security statements, legal or regulatory claims, customer results, first-hand experience, and conclusions that could influence an important decision.
Check brand fit, reader usefulness, unsupported certainty, internal links, author attribution, image accuracy, and the proposed CTA. Confirm that any proprietary evidence may be published in the stated form.
The approval record should identify the revision, reviewer, time, remaining limitations, destination Ghost site, and permitted next action. Approval to create a draft is not approval to publish.
For a detailed evidence review, use the AI content fact-checking guide.
Stage 6: create a Ghost draft
A trusted local or server-side integration should hold the Ghost Admin API key. The key should not appear in the article, prompt, conversation, repository, screenshot, or shell argument.
Create the Ghost post as a draft regardless of instructions embedded in the content. Send the reviewed title, slug, excerpt, body, tags, author selection, SEO metadata, and image intent as an explicit package.
After creation, read the draft back and record its exact Ghost ID, slug, status, and updated timestamp. These values become the basis for revision-aware changes.
If the creation response is uncertain, list or retrieve the expected draft before trying again. Automatic write retries can create duplicates or conflicting state.
The guide to publishing to Ghost with AI explains the least-privilege architecture around this handoff.
Stage 7: review Ghost metadata and images
The Ghost draft is a new system state and deserves a final delivery review. Confirm that Markdown or structured content converted correctly, headings and links survived, authors and tags are correct, images resolve, and SEO fields match the approved package.
Image uploads should be limited to approved local roots. Validate file type, size, and integrity before upload, then attach the Ghost-returned URL. Review visual accuracy, licensing, sensitive information, and alt text.
When a correction is needed, read the current draft and prepare a preview showing the exact target, current revision, fields or sections to change, and before-and-after values.
Apply the change only if the Ghost revision still matches the preview. If another editor changed the draft, stop and regenerate the plan from the current state.
Stage 8: approve scheduling or publishing
Scheduling and publishing are public or time-sensitive transitions. They require a second explicit approval naming the exact Ghost site, post or Page IDs, current revisions, intended status, local schedule when applicable, and whether a deployment will follow.
For scheduling, plan with an IANA time-zone name, convert the approved times to UTC, and bind the plan to the current draft revisions. The planning step should not write.
Before publishing a batch, preflight every target. If one item has changed, is missing, or fails required metadata checks, stop before the first mutation unless partial publication is an explicitly approved mode.
After each transition, read the Ghost record back and retain a receipt. A successful request should be confirmed against the resulting state.
Stage 9: deploy a headless frontend when required
When Ghost renders the public theme directly, no separate frontend deployment may be required. In a headless architecture, the public site may need a static build, route revalidation, cache update, or another delivery action.
Treat the deploy hook as a separate restricted capability. The destination belongs in trusted server configuration, not in generated content. Require HTTPS, reject redirects, redact sensitive URL components, and avoid automatic retries.
Trigger one deployment after the complete approved Ghost batch succeeds. If Ghost succeeds and deployment fails, report partial success instead of claiming that the public page is available.
The headless Ghost publishing guide covers route templates, deploy hooks, caches, and recovery in more detail.
Stage 10: verify the public result
Public verification closes the loop. Construct the URL from a trusted post or Page template and the verified Ghost slug. Do not allow generated content to choose an arbitrary host for server-side checks.
Check the expected HTTP status, rendered title, canonical URL, meta title and description, feature image, selected social fields, and accidental noindex directives.
Keep the evidence categories separate:
- Ghost confirmed: the CMS record has the expected status and revision.
- Deployment confirmed: the delivery system reports completion when such evidence is available.
- Public output confirmed: the expected page is reachable and contains the required elements.
None of these states prove that a search engine indexed or ranked the page. Indexing and performance require separate monitoring.
Roles and permission profiles
Assign responsibilities according to risk rather than giving every operator the same connection.
Researcher or writer
Can research, draft, validate, and propose changes. Does not require Ghost credentials.
Editor
Approves claims, structure, positioning, metadata, images, and the exact downstream revision.
Draft operator
Can create Ghost drafts, upload approved images, and apply approved draft-safe changes.
Scheduler
Can apply approved schedules to exact revisions but does not need publish, unpublish, or deployment authority.
Publisher
Can perform approved public transitions, trigger the configured deployment, and initiate live checks.
Ghost Publisher MCP implements read-only, draft-editor, scheduler, and publisher profiles as separate registered capability sets.[1]
How the two open-source tools fit together
Source-Backed Blog Writer and Ghost Publisher MCP are independent projects that solve different parts of the workflow.
- Source-Backed Blog Writer defines how the agent researches, plans, drafts, refreshes, audits, cites, and validates an SEO article.
- Ghost Publisher MCP defines which Ghost reads and actions a connected AI client can perform and how sensitive transitions are controlled.
Installing the skill does not install or authorize the MCP server. Connecting the MCP server does not force the AI to use the writing skill. The operator combines them intentionally.
This is the practical difference between procedure and capability described in MCP vs Agent Skills.
A production example and its limits
The Ghost Publisher repository includes a maintainer-operated Ortak Alan case study. It describes a workflow covering draft creation, metadata changes, image upload, approved publishing, deployment, and public checks across a public archive that showed 336 pieces on August 20, 2026.[2]
The operator reports a current cadence of five to six posts per day and says a manual path that previously took roughly 30 minutes per post became a reviewed batch completed in minutes.[2]
This is operational evidence from the maintainer, not an independent customer study. It does not prove that the MCP caused search growth, that every team will achieve the same speed, or that the workflow is safer than every alternative.
The useful lesson is architectural: repeatability came from putting draft-first creation, approval, deployment, and verification into the same bounded process rather than removing human control.
Failure handling in the complete workflow
Research is incomplete
Mark the package blocked or draft. Do not compensate with invented data or unsupported certainty.
The Ghost draft changed after approval
Stop the write, read the current revision, show the conflict, and require a new preview or review.
A publish request times out
Do not retry automatically. Read the exact Ghost item and determine whether the original transition succeeded.
Ghost succeeds but deployment fails
Report partial success. Retain the Ghost receipt and require a new approved decision to retry deployment or roll back the public status.
Deployment succeeds but the page is wrong
Compare the approved package, Ghost Admin record, Content API result, and rendered HTML to identify where the mismatch begins.
Frequently asked questions
Can the complete Ghost content workflow run automatically?
Mechanical stages can be automated, but evidence, brand, risk, and public-transition ownership still need explicit human responsibility. Automation does not require unattended publishing.
Does the writing skill need the Ghost Admin API key?
No. The writing skill prepares the editorial package. A separately trusted Ghost integration holds the key and enforces CMS permissions.
Should every approved draft be published immediately?
No. Draft approval, scheduling, and publication are different decisions. The team may need legal review, campaign timing, author approval, or a coordinated release.
How do I know which version was approved?
Record the editorial revision or content hash, then bind Ghost change previews and publication plans to the current Ghost updated timestamp.
Does live verification guarantee indexing?
No. It confirms that the page is publicly reachable and contains expected output. Search-engine crawling, indexing, and ranking are separate systems.
The practical takeaway
A complete AI content workflow for Ghost is not one giant prompt. It is a chain of evidence-backed editorial work and separately authorized system actions.
Begin with a real brief, research the site and current intent, approve claims and the outline, draft and validate a complete package, review the exact revision, create a Ghost draft, preview changes, authorize public transitions separately, deploy once when required, and verify the rendered page. That structure lets AI remove repetitive work without hiding the decisions that determine what becomes public.
References
[1] Ghost Publisher MCP repository and permission profiles
[2] Ortak Alan publishing case study
[3] Source-Backed Blog Writer repository
[4] Ghost Admin API documentation
[5] Google: creating helpful, reliable, people-first content