md2wechat-skill 2.0: From a Set of Commands to a Release-Ready WeChat Workflow

I would not describe this release as a normal feature update. It is closer to a consolidation point.

Many tools are technically usable, but still feel unfinished because the main workflow is not fully stable, the install path is uneven, and the docs do not describe the same reality as the runtime.
Version 2.0 is where those layers finally line up much better for md2wechat-skill.

Public entry:

• ClawHub: geekjourneyx/md2wechat

One date detail matters here:

• this article is about the v2.0.0 major release line
• as of March 21, 2026, the public ClawHub page already shows v2.0.1 as the current version

So 2.0.0 is the point where the major release became real, while 2.0.1 reads more like the follow-up calibration of public metadata, installation guidance, and packaging.

Why this is not just another minor version

If the change were only "more commands" or "one more theme," this would not justify a 2.0 label.

What changed here is broader:

• the CLI mainline
• the image-generation and prompt asset layer
• the Coding Agent and OpenClaw skill split
• installers and release artifacts
• docs, config, discovery commands, and publishing metadata

From the outside, that may look like feature growth.
From an engineering perspective, the more important change is that these layers now behave more like one product surface.

The first change users will feel: the workflow is more complete

If you are new to md2wechat-skill, the biggest difference is not one command. It is that the end-to-end path now feels much more intentional.

The main chain has been tightened into a clearer flow:

1. Markdown conversion
2. image processing or generation
3. upload
4. draft creation
5. image-post creation

That sounds obvious, but many "usable" tools only make two or three of those steps feel solid. The rest still depends on repo archaeology, shell snippets, or guessing from scattered docs.

Version 2.0 feels closer to a WeChat publishing workflow than to a loose collection of commands.

The CLI contract is much clearer now

One of the most important parts of this release is not a new feature. It is the tighter contract.

1. The main command chain is now coherent

The path from Markdown conversion to images, upload, draft creation, and image-post creation is no longer shaped like an experiment.

That matters because it lets users and agents design automation against a clearer spine instead of improvising between commands.

2. The JSON output envelope has been unified

This may not be the most visible improvement for a human user, but it matters a lot for scripts, agents, and workflow tooling.

When output shapes drift, the failure mode is familiar:

• one version parses, the next one breaks
• success and error payloads behave differently
• commands in the same flow become harder to chain

Tightening that contract is one of the real 2.0-level changes.

3. convert still defaults to api mode unless you override it

This looks like a small default, but it is operationally important.

When users do not pass --mode, convert still defaults to api. That keeps older habits and existing automation from drifting just because a default changed underneath them.

4. The boundary of AI mode is stated more honestly

Another important clarification is that AI mode currently returns the AI request / prompt, not final HTML output.

That kind of wording matters. If you do not define that boundary clearly, users form the wrong expectation about what the mode actually produces.

Prompt Catalog and image workflows are now more like a system

The hardest part of image generation is usually not "having prompts." It is having prompt assets scattered across docs, examples, and repo paths with no reliable discovery model.

Version 2.0 addresses that problem directly.

Discovery commands now form a real surface

The stabilized discovery commands include:

• capabilities
• providers
• themes
• prompts

That means a user no longer has to start by searching the README just to find out what the current build supports.

A better pattern is now possible:

1. inspect capabilities
2. inspect providers
3. inspect themes
4. inspect prompts

That is much closer to a discovery-first product surface.

Prompt assets are now tied to the binary

This release embeds built-in themes, the default writer style, and prompt assets into the binary.

That changes several practical things:

• fewer repo-relative path assumptions
• fewer missing-asset problems in runtime environments
• stronger version consistency between code and prompt resources

In other words, prompts are no longer just supporting files around the repo. They are part of the runtime asset layer.

Image archetypes are now a product layer, not an afterthought

The image prompt archetype set now covers areas such as:

• article covers
• infographics
• banner summaries
• dark ticket-style visuals
• hand-drawn sketchnotes
• Apple keynote-style visuals
• Victorian engraving style

The real value is not "more styles." The real value is that these archetypes are now discoverable, callable, and overridable inside one model.

That also gives the image commands a more stable surface:

• generate_image --preset
• generate_cover
• generate_infographic
• command-level --model override

The two skill paths are finally separated

One of the easiest places for drift used to be the gap between platform-specific behavior and shared facts.

That split is now explicit:

• Coding Agent: skills/md2wechat/
• OpenClaw: platforms/openclaw/md2wechat/

This is not just a directory cleanup. It fixes a real product problem: platform-specific installation, runtime rules, metadata, and disclosure should not be mixed into the same shared layer.

That separation makes the responsibilities clearer for:

• installation
• runtime boundaries
• metadata
• security disclosure

Installation and release engineering now feel much more deliberate

Another major difference in 2.0 is that the release path itself is more disciplined.

One version source

Using a single VERSION file as the source of truth is not flashy, but it matters.

Once the version number lives in too many places, drift becomes inevitable:

• the tag says one thing
• the installer says another
• the docs mention a third version
• the publishing metadata points somewhere else

Version truth needs one anchor if release quality is meant to hold.

Build, smoke, and release are tied to the same artifact path

This release tightens the line around:

• build once
• smoke the same artifact
• release the same artifact

That matters because it reduces the classic gap between "what passed locally" and "what actually shipped."

Installer paths and release metadata were calibrated together

You can also see this on the public ClawHub page itself. As of March 21, 2026, the listing clearly exposes fixed-version install resources and installer entry points, while also clarifying runtime-version matching and the OpenClaw install boundary.

That is what a more mature release looks like: not just uploading a binary, but publishing the binary, skill bundle, installer paths, and metadata as one coherent release surface.

The docs now serve onboarding instead of just reference

If the commands change but the docs remain fragmented, the release is still not really finished.

One thing 2.0 gets right is that the documentation has been reorganized around the first questions users actually ask:

• what is the default mode
• how does the API service connect
• which themes, prompts, and providers are supported
• which install path fits which environment

It also pulls several high-friction topics back into the formal doc layer:

• config guidance
• capability discovery docs
• FAQ
• WeChat AppID / AppSecret / IP whitelist guidance
• image service guidance
• OpenClaw docs

That matters because missing information usually hurts adoption more than missing features.

Why 2.0.0 is justified

From both a product and engineering angle, this release crosses the line beyond minor-version accumulation.

It is much closer to this kind of shift:

• from a single-command tool to a fuller publishing workflow
• from manual doc reading to a discovery-first agent-facing system
• from repo-relative assets to embedded assets with override paths
• from mixed skill packaging to platform layering
• from "usable" to "publishable, verifiable, and maintainable"

If version numbers are meant to reflect product state, 2.0.0 is justified.

What existing users should do now

If you already use an older version, the next move is not to try every new capability at once. I would start with four things.

1. Run discovery first

Confirm what the current build supports:

md2wechat capabilities --json
md2wechat providers list --json
md2wechat themes list --json
md2wechat prompts list --json

2. Use image presets instead of starting from raw prompts

If your goal is a cover or infographic, start from:

• generate_cover
• generate_infographic
• generate_image --preset

That is a steadier path than opening with raw prompt text.

3. Choose the right skill path for the platform

If you are running a Coding Agent workflow, use the Coding Agent path.
If you are running OpenClaw, use the OpenClaw path.
Do not mix platform-specific installation assumptions together.

4. Treat installation as a fixed-version release path

Especially for OpenClaw, it is better to treat the fixed-version installer, runtime, and skill bundle as the real install path instead of mixing discovery entrypoints with complete provisioning.

Closing thought

The real meaning of md2wechat-skill 2.0.0 is not "there are more commands now."

The more important part is that the facts spread across the CLI, prompt assets, image workflow, platform packaging, installers, release artifacts, and docs have been pulled into a much more stable release surface.

For users, that means a clearer starting path, more stable defaults, and easier discovery of prompt and image capabilities.
For maintainers, it means versions, installation, metadata, and documentation are finally much closer to the same source of truth.

If you want the surrounding context, continue with:

• md2wechat Is Now on ClawHub: What to Check Before Installing It in OpenClaw
• md2wechat-skill: WeChat Formatting for Claude Code and OpenClaw
• md2wechat-lite vs. md2wechat-skill