Installation and setup paths are distribution evidence, not proof of end-to-end compatibility with any named host. Treat each runtime as a validation candidate until its install, discovery, conversion, preview, and—when applicable—draft flow passes an end-to-end smoke test.

The good news about md2wechat-skill in Coding Agents is that most of the workflow is shared.

The bad news is that people still overcomplicate it.

For Claude Code, Codex, and OpenCode, start with the same validation sequence:

install the CLI
install the skill
run discovery
ask the agent to do the actual work

The shared install path

If you want the cleanest route, use:

brew install geekjourneyx/tap/md2wechat
npx skills add https://github.com/geekjourneyx/md2wechat-skill --skill md2wechat
md2wechat version --json
md2wechat capabilities --json

If you installed via install.sh, remember:

export PATH="$HOME/.local/bin:$PATH"

Without that line, the skill can exist while the runtime still looks missing to the current shell.

The discovery commands every agent should run

Before you ask an agent to pick a theme or generate a cover, make it prove what exists:

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

This is one of the most important patterns in the upstream docs.

It keeps the agent from inventing support that the current runtime does not have.

Claude Code

Claude Code has two setup paths to validate:

the shared npx skills add route
the plugin marketplace route

The plugin marketplace path is convenient, but it does not change the main constraint:

the CLI still needs to exist.

That means a healthy-looking plugin install can still fail at runtime if md2wechat is not in PATH.

Codex

Codex does not need a special mental model here.

Start Codex validation with the generic Coding Agent checklist:

install CLI
install skill
run discovery
send a precise prompt

The mistake to avoid is choosing a transport before validation. Keep the raw API available, and prefer the skill path only after that runtime's install, discovery, conversion, and preview checks pass.

OpenCode

OpenCode follows the same operational logic.

The key difference is usually not the toolchain. It is prompt discipline.

Good prompts tell the agent to:

verify the runtime first
name the mode it is using
explain whether the output is preview HTML, API HTML, or an AI request

That last point matters because AI mode is not the same as direct conversion.

Three prompts worth reusing

1. Install and verify

Please install md2wechat CLI first, then install the md2wechat skill, verify version and capabilities, and stop only after every command succeeds.

2. Safe first conversion

Run md2wechat capabilities --json first, then convert article.md into WeChat HTML and show me the preview.

3. AI-mode clarification

Use md2wechat in AI mode with theme autumn-warm and explain whether the current result is final HTML or an AI request for a second model step.

What people usually get wrong

They assume the skill installs the runtime

It does not.

They skip discovery

Then they are surprised when a provider, theme, or prompt preset is not actually available.

They forget API mode is the default

If --mode is missing, convert defaults to API mode.

They use environment-specific advice in the wrong place

OpenClaw is its own path. Claudian has GUI PATH issues. Do not copy those caveats into every other runtime.

Where to continue