OpenClaw on TorchTree

From OpenClaw to Hermes: Automatic Role Migration with a Single Command

Wed, 08 Apr 2026 05:55:11 +0800

After running hermes claw migrate, your config files and skills have been migrated to Hermes, but the Agent’s cognition may still be stuck in the OpenClaw era. It may still call itself “Aris,” try to access the ~/.openclaw/ directory, and use tools that no longer exist.

Solution: Send a single command that lets the Agent automatically check and fix its own identity and working logic.

Roles Explained

Before continuing, we need to clarify two identities:

Identity	Framework	Description
Aris	OpenClaw	The AI assistant name in the original OpenClaw ecosystem, used in your historical configuration
Helix	Hermes	The new identity after migrating to Hermes, which the Agent needs to self-identify as

When the Agent says “I am Aris,” it is still running on its OpenClaw identity. You need it to update to “I am Helix.”

Background

Limitations of the Official Migration Command

hermes claw migrate handles the data level:

Copies configuration files to ~/.hermes/
Migrates skills to ~/.hermes/skills/openclaw-imports/
Transfers memory files

But it does not modify the contents of files. If SOUL.md says “I am Aris,” the Agent will still believe that after migration.

Typical Symptoms

After migration, if the Agent exhibits any of the following behaviors, it needs role adaptation:

Symptom	Description
Calls itself “Aris”	Identity not updated
Accesses `~/.openclaw/`	Wrong path cognition
Invokes memory_search	Using an OpenClaw-specific tool
Mentions “OpenClaw provides context”	Wrong framework cognition

The Single-Command Automation Approach

You don’t need to edit files manually. Send the following command to the Agent, and it will automatically perform all checks and fixes:

The Agent will automatically run the checks above, modify files directly, and report a summary of changes to you.

Technical Details (for reference)

If you want to know exactly what the Agent will check, here are the technical details:

Where Identity Is Declared

File	Path	Purpose
SOUL.md	~/.hermes/SOUL.md	Global identity and personality definition
MEMORY.md	~/.hermes/memories/MEMORY.md	The Agent’s personal notes (limited to 2,200 characters)
USER.md	~/.hermes/memories/USER.md	User profile (limited to 1,375 characters)

Key Differences

Dimension	OpenClaw (Aris)	Hermes (Helix)
Identity	“I am Aris”	“I am Helix”
Framework	OpenClaw	Hermes Agent (Nous Research)
Home directory	~/.openclaw/	~/.hermes/
Memory storage	.jsonl files	SQLite + FTS5
Skill lookup	memory_search	skills_list + skill_view
Memory limits	No explicit limits	2,200 / 1,375 characters

Example of Actual Changes

SOUL.md changes:

MEMORY.md changes:

Verification Results

After the Agent completes its self-check, it will output a report similar to the following:

Manual Verification (optional)

If you want to confirm the migration results manually:

References

Official migration guide: Migrate from OpenClaw
Memory system: Persistent Memory
Context files: Context Files

Compiled from actual migration experience with Hermes Agent v0.7.0.

Connecting Kimi Code to OpenClaw: Key Configuration Cheat Sheet

Sun, 05 Apr 2026 07:01:31 +0800

Kimi Code is the Coding Plan subscription from Moonshot AI that provides an API based on the Anthropic protocol. If you’ve already subscribed to Kimi Code, here’s how to connect it to OpenClaw.

Core information

Endpoint: https://api.kimi.com/coding/
Protocol: Anthropic Messages API (not OpenAI-compatible)
Model name: kimi-for-coding
Context window: 256K tokens
Max output: 64K tokens
Multimodal: Supported (based on K2.5, can handle visual inputs like images)
API Key: Generate it in the Coding Plan page of the Kimi Code console; usage is also tracked on the same page

Example OpenClaw configuration

Add the following provider to your OpenClaw configuration file:

Configuration notes:

Set the API Key as the environment variable KIMI_CODE_API_KEY, using the key generated on the Coding Plan page
api must be anthropic-messages; going through the OpenAI-compatible path returns 403 or 404 errors
cost is set to 0 because the Coding Plan is a subscription, not per-token billing
input includes text and image, indicating multimodal input support

Gotchas

Some OpenClaw versions may have compatibility issues with tool calls; if your call chain breaks, watch for version updates
Kimi Code officially permits use in Claude Code and Roo Code; connecting it to OpenClaw is a “non-officially-supported product” and carries a risk of being flagged as abuse—evaluate this yourself

Suitable use cases

This fits users who already have a Kimi Code subscription and want to reuse their quota within OpenClaw. If you don’t have a Kimi Code subscription yet, you’ll first need to sign up for a membership plan at kimi.com.

Update note: the provider name changed from kimi-code to kimi-plan to avoid colliding with a built-in OpenClaw name.

How We Turned Ghost Publishing into an OpenClaw Skill

Thu, 02 Apr 2026 11:56:02 +0800

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.