WeWrite: a WeChat Official Account content pipeline as an AI Agent Skill

The gap WeWrite fills: an agent that writes, but only when told to

Most writing assistants collapse everything into one action. You ask for an article and you get an article, an image, and a publish button in the same breath. WeWrite splits that apart deliberately. The README describes the default as a reviewed local draft: the pipeline runs topic capture, topic scoring, an article brief, a claims-and-sources list, safe content enhancement, a first draft anchored to real information, editorial judgment, and revision if the review fails. Images and publishing are not part of that run. You add them afterward, one request at a time.

The audience is narrow and specific. This is for people who publish to a WeChat Official Account and who already drive an AI agent. The README lists Claude Code, Codex, OpenClaw and Hermes as supported hosts. If you write for a blog, a landing page, or a newsletter, the project's own suitability list says to use a front-end skill instead. That honesty is worth noting: the authors would rather lose a user than have someone fight the WeChat theming engine for a use case it was never built for.

Three-layer decoupling: prompt for judgment, Python for determinism

The architecture statement in the README is one sentence long and does most of the explaining: prompts make the judgments, Python does the deterministic work. That maps onto three layers. The Prompt layer lives in skills/, ten self-contained skill directories that each carry their own references folder. The Runtime layer is the wewrite CLI, a pip package that scores text, converts markdown to WeChat HTML, calls the WeChat API, generates images, and routes writing cost. The State layer is ~/.wewrite/, overridable with WEWRITE_HOME, and it holds credentials, style, history, learning output and generated files.

The consequence is that state never lives inside the repository. Skill directories are described as copy-and-use, the CLI upgrades independently of the skills, and moving machines means carrying ~/.wewrite/ rather than re-cloning. Each article is stored under ~/.wewrite/runs/<task id>/, and the README states that progress is resumable and that concurrent articles do not overwrite each other. That is the mechanism behind the example of picking topics in the morning and saying "continue from last time" in the afternoon: the run directory is the checkpoint, not the conversation.

The scoring side is where determinism pays off. wewrite score runs eleven mechanical checks that flag filler phrasing, choppy sentences and repeated rhythm, and the README is explicit that it does not judge author identity. wewrite content-eval covers five editorial dimensions: accuracy, point of view, usefulness, voice match and readability. Splitting a mechanical pass from an editorial pass is a real design decision, not a slogan, and it tells you where to expect false positives.

Installing WeWrite and running one article end to end

The recommended path clones the repository shallowly and runs the bundled installer. According to the README, install.sh does three things: it installs the wewrite CLI through uv or pipx with a venv fallback, links the ten skills into ~/.claude/skills/ and ~/.agents/skills/ (and into the OpenClaw or Codex skill directories when those are detected), and migrates older user state into ~/.wewrite/.

git clone --depth 1 https://github.com/imraywang/wewrite.git ~/wewrite
cd ~/wewrite && bash install.sh

If you would rather take modules one at a time, the README offers a second route through skills.sh. The skill directories are self-contained, so copying them is enough, but the CLI is a separate install. Both commands below come from the README.

npx skills add imraywang/wewrite
uv tool install wewrite

For Hermes, which ships its own skill manager, the README gives a single command instead.

hermes skills install imraywang/wewrite

Configuration is optional at first. The README states plainly that writing needs no configuration at all. You copy the example file to your home directory and fill in the WeChat appid and secret for pushing, plus an image API key if you want generated images.

cp config.example.yaml ~/.wewrite/config.yaml

With the skills linked, the first real use is a sentence rather than a command. Saying "write a WeChat article" triggers the full text pipeline and, by default, produces a reviewed local draft with no images and no publishing. Saying "complete production of a WeChat article" adds images and a local preview. Saying "push to the draft box" is the only path that publishes, and the README says it requires explicit authorization and satisfied conditions. The CLI also exposes the individual steps, including wewrite hotspots, wewrite search-articles, wewrite seo, wewrite sources, wewrite preview and wewrite gallery.

WeChat is the only target, and that is a hard boundary

The suitability list is unusually blunt. Ordinary web pages and landing pages belong to a front-end skill. PPT, email and blog output are out. Non-WeChat SEO is out. Component-level design customization is out, and even though you can technically use wewrite-publish alone for layout, the README recommends a dedicated layout skill instead.

The layout engine itself carries the same constraint from the other direction. Styles are fully inlined, WeChat compatibility fixes are applied, and dark mode is handled, all of which exist because WeChat's editor strips or rewrites a lot of CSS. That is a maintenance surface, not a feature. Eighteen themes plus learn-theme means every theme is a compatibility target, and a change in how the WeChat editor sanitizes markup can invalidate the lot. The README does not document a rollback path for a theme that renders badly after a platform change, and it does not describe a test suite that pins rendering against a captured WeChat output. If your publishing schedule cannot tolerate a layout regression, that silence matters more than the theme count.

Cost is the second boundary. The README states that writing can be routed to a separate writing model when WEWRITE_WRITER_API_KEY is configured, and that actual cost depends on the service, model and article length you choose. There is no published figure, and none should be assumed.

How WeWrite differs from a general-purpose writing skill

A general writing skill, the kind bundled with most agent hosts, takes a prompt and returns prose. It has no notion of a topic backlog, no source ledger, and no publishing target. WeWrite's difference is that the pipeline has named artifacts at each stage: ten scored topics from wewrite-topic, an article brief plus a claims-and-sources list from wewrite-write, and a pass-or-revise editorial decision from wewrite-review. The claims list separates fact, inference, opinion and personal experience, and wewrite sources keeps a per-article source ledger. That is a different approach to the same request, and it is the reason the review step can fail a draft rather than just annotate it.

The second difference is the learning loop. wewrite-learn turns your edits into playbook rules and a style library, and wewrite-stats feeds reading data back into topic suggestions. A general writing skill starts from zero every session. Whether the learning loop converges on something you actually like is a question the README does not answer, and it is the part most worth testing on your own edits before you rely on it.

The third difference is portability across hosts. Because each skill is a folder, the same ten modules run under Claude Code, Codex, OpenClaw and Hermes without a build or conversion step. A host-specific writing feature does not travel that way.

Licence, upgrade cost and what the repository does not say

WeWrite is MIT licensed, and the pyproject metadata declares requires-python >=3.11 with dependencies on markdown, beautifulsoup4, cssutils, requests, pyyaml, Pygments and Pillow. There is an optional browser extra pulling in playwright and camoufox for a secondary fetch path; the README notes the requests path works without it. MIT is permissive, so embedding the CLI or vendoring the skills into an internal tool is straightforward, but the practical implication sits with the content rather than the code: generated articles, learned style libraries and playbooks live in ~/.wewrite/, and what you do with those is your call, not the licence's. Nothing here is legal advice.

Upgrade cost is asymmetric between the two layers. The CLI is a pip package, so it moves with uv tool install wewrite or your package manager. The skills are linked directories, which means reinstalling or re-cloning is how they move, and a stale link is a plausible failure mode after a repository rename or a move to a different home directory. The README documents an "update" phrase that upgrades to the latest version, and install.sh migrates old user state, but it does not describe how a partially migrated ~/.wewrite/ behaves if the migration stops midway. Back that directory up before upgrading across a major version.

The last push was on 2026-09-21, and the most recent release listed is v4.2.0 from 2026-07-16, which the release notes title "optional images and high-availability content generation". The v4.0.0 notes describe a resumable, safe and traceable workflow, and v3.3.0 describes the move from a monolithic skill to the three-layer architecture. Those three notes together are the shape of the project's recent direction: reliability and structure, not new output formats.

Editorial conclusion

Adopt WeWrite if you publish to a WeChat Official Account and already run Claude Code, Codex, OpenClaw or Hermes, because the topic, draft, review and layout steps are separated into skills you can call one at a time. Do not adopt it for landing pages, blogs, email or PPT work; the README sends those to a front-end skill instead. Before trusting it on a live account, verify three things yourself: that install.sh linked all ten skill directories into your agent's skills path, that config.example.yaml copied to ~/.wewrite/config.yaml holds the appid and secret for the account you actually intend to push to, and that a dry run of the layout step produces WeChat-compatible HTML you are willing to paste. The draft box is the boundary worth testing first, since the README states that publishing happens only after explicit authorization and satisfied conditions.

Frequently asked questions

Official sources

1. imraywang/wewrite on GitHub
2. Issues
3. License: MIT
4. README
5. Releases