This post documents a concrete implementation: getting OpenClaw to reliably create, update, and publish Ghost posts. The goal was simple: the process must be reusable, the configuration must stay contained, and when something goes wrong we need to know exactly which step failed.

Goal

We wanted OpenClaw to do three things:

• Understand Ghost’s publishing pipeline
• Turn the publishing flow into a reusable skill
• Handle authentication and publishing through local environment variables, without writing secrets into code

Which Docs We Consulted First

We didn’t start with sample articles but with the parts of the Ghost official docs covering APIs and authentication, focusing on two questions:

• Which APIs are read-only
• Which APIs can create and update content

After reading, the conclusion was clear: the Content API is fine for reading, but actual writes go through the Admin API.

What This Skill Does

We organized the flow into ghost-publisher.

Its responsibility is narrow and well-defined:

• Accept publishing fields such as title, body, slug, and tags
• Handle Markdown or HTML input
• Normalize the content structure before publishing
• Call the Ghost Admin API to create or update posts
• Return verifiable results, such as post id, slug, URL, and status

The benefit is that OpenClaw no longer needs to reinterpret Ghost’s rules every time — it can just route through this skill directly.

Which Environment Variables You Need

Conceptually only two pieces of configuration are required:

• The Ghost site address
• The Ghost Admin API key

Both values should live in a .env file, read by OpenClaw at startup. Don’t write them into posts, logs, or prompts.

Why It Failed the First Time

Initially we grabbed the common Content API key from a Ghost Integration. It can read content but cannot write it.

That was the root cause of the first failure:

• The Content API key is read-only
• To write posts, you must use an Admin API key
• An Admin API key is only available after creating a Custom Integration in the Ghost admin panel

Until the permission model was straightened out, the flow seemed correct but could never actually publish.

Why You Need to Restart OpenClaw After Editing .env

Because OpenClaw reads environment variables at startup.

So after editing .env, you must restart OpenClaw for the new host and key to take effect. Editing the file alone won’t do — the process still holds the old configuration.

The Formatting Issues We Actually Ran Into

We also confirmed a few publishing constraints this time, which we can carry forward into future articles:

• Don’t repeat the top-level title in the body, since Ghost already has a title field
• Normalize the Markdown before publishing to avoid messy blank lines, indentation, and repeated list markers
• Keep slugs clear and consistent with the topic; English is usually more intuitive than forcing Chinese characters

If these issues are not addressed, pages look messy and the content feels thrown together.

How to Safely Let AI Handle an Environment Containing Secrets

If AI is involved in this kind of work, the boundaries need to be spelled out first:

• Use only the designated environment variables
• Don’t output the full .env contents
• Don’t echo the value of any key
• Only return non-sensitive verification results

In other words, the AI can tell you “whether the config is active,” “whether a post is published,” and “what slug was returned,” but it must not leak any secret values.

Result

Once this flow was working, OpenClaw can now reliably:

• Read the local configuration
• Process posts through ghost-publisher
• Write to Ghost via the Admin API
• Return verifiable publishing results

If we later need to extend this to updating posts, batch publishing, or more complex content formats, the foundation is already in place — we can simply reuse this pipeline.