self-media-content-workflow: nine Agent Skills for a content pipeline with five forced human checkpoints

The problem is not writing, it is the missing checkpoints

Most agent content tooling optimises the generation step. This project treats generation as the cheap part and spends its structure on the steps around it: clarification, evidence, platform adaptation, review, and authorisation. The README describes the suite as covering the full loop from a vague request to a creative brief, account strategy, trend and competitor research, platform-native copy, short-video plans, digital-human production, WeChat formatting and publishing, analytics, and delivery archiving. That is a wide scope for nine skills, and it is the scope rather than any single skill that defines the project. The intended user is someone who already runs an agent and wants the content process encoded as instructions the agent must follow, not a person looking for a hosted writing tool. The README states the design position plainly: the suite defaults to producing drafts or publish packages and never auto-broadcasts. If your actual need is a button that fills a queue, this is the wrong shape of software.

One router, eight specialists, and a shared evidence set

The architecture diagram in the README shows a single orchestrator, self-media-content-workflow, owning request routing, state management, confirmation points and end-to-end orchestration, with eight modules hanging off it: content-brief, content-strategy, trend-radar, platform-copywriting, short-video, content-analytics, content-delivery and wechat-publisher. Each module has a single stated responsibility. The interesting part is the data flow claim: multiple platforms share facts and evidence, but titles, openings, structure and calls to action are rewritten per platform. That is a real design decision with a cost. It means the evidence layer has to be stable enough to survive being reused, and it means the copywriting step cannot simply reformat one draft. The README also states that collection and publishing are runtime adapter layers, not bound to a vendor implementation, and that the suite discovers available capabilities in the current environment at runtime. That is what makes it tool-agnostic in practice, and it is also where the suite is hardest to verify from the outside, because the adapters are described as runtime concerns rather than shipped integrations.

Five confirmation points, and a distinction between final draft and permission to publish

The workflow in the README reads as a chain: requirement clarification, direction confirmation, research and evidence, platform confirmation, pre-publish check, platform-native first draft, title confirmation, asset generation (live action or digital human), quality review, final draft confirmation, publish authorisation, draft or publish package, then analytics. Five of those are marked as mandatory human confirmation points. The detail worth noting is that final draft confirmation is explicitly not the same as publish authorisation. The suite treats them as two separate gates, which is a sensible split given that the WeChat module writes to a real account. The visual side is also gated: before asset generation, the workflow recommends two to three styles from a visual style library based on content type and platform, and if the account already has an established preference, that preference takes priority over the preset defaults. The README describes eight built-in style presets with platform routing, and states that styles are not mixed within a group. Whether the routing rules are good is not something the repository material lets me judge; what is clear is that the choice is made before generation, not after.

Installing it: two paths that do not install the same thing

Claude Code users get a plugin route with no Node.js requirement. The README gives two commands, run in sequence: /plugin marketplace add yanhua1010/self-media-content-workflow, then /plugin install self-media-suite@self-media. The README states this installs all nine skills at once. Other agents use the official skills CLI and do need Node.js. The base command is npx skills add yanhua1010/self-media-content-workflow, with -g to install into the user global directory instead of the current project. Selective installs use --skill to name one module and -a to name the target agent, for example npx skills add yanhua1010/self-media-content-workflow --skill self-media-content-workflow -a claude-code. Invocation is by skill name in the prompt, such as using $self-media-content-workflow to turn a product failure story into Xiaohongshu and WeChat content, or calling a module directly like $self-media-content-strategy to build a topic pool and a one-month calendar. The README adds a caveat that matters: the exact reference syntax depends on the agent you use. Repository validation is a separate step, python3 scripts/validate.py, which the README says checks skill frontmatter, directory consistency, core file line counts, UI metadata, relative links and unresolved TODOs, with no third-party dependencies. That is the one command in the repository you can run without an agent at all.

The WeChat publisher is the one module touching a live account

Most of the suite produces text and files. self-media-wechat-publisher is different: the README lists its responsibilities as WeChat formatting, image upload, writing into the draft box, and image messages for Xiaohongshu-style posts. The disclaimer is direct about the consequence, stating that the project involves real account operations such as writing to the WeChat draft box, and that the authors accept no liability for throttling, bans, content removal or data loss. Credential handling is stated as environment variables only, with WECHAT_APP_ID and WECHAT_APP_SECRET named as examples, and an explicit instruction not to write them into any file that could be committed or shared. The README also says the project does not collect, transmit or store credentials. This is the section to read before installing anything, because it defines the blast radius. The draft-box write is the boundary the suite is willing to cross; publishing is not. If your threat model does not accept an agent holding account credentials in the environment, this module is the one to skip, and the other eight skills do not require it.

Safety rules that constrain what the skills will do

SECURITY.md is referenced as holding the full policy, and the README summarises a set of prohibitions: no logging into competitor accounts with a primary account session for scraping, no automatic likes, comments, follows, direct messages or publishing, no cookies, tokens or secrets stored in task cards, logs or the repository, and an immediate stop when captchas, rate limits or platform risk controls appear. There is also a rule that recent product, price, version and platform details should be verified against official sources first, and a blanket prohibition on fabricating data, experiences, revenue, user reviews and test results. The evidence rule is more specific than a generic accuracy claim: key numbers must have a source, and the suite distinguishes between fact, judgement, inference and recommendation. That four-way distinction is the most useful thing in the policy, because it gives the agent a vocabulary for saying what it does not know. The digital-human section applies the same restraint to personal data: the README states that task files, the content registry and the repository do not store original avatars or recordings, their local paths, temporary links or platform-private identifiers, indexing only generated clips, final videos and subtitle files. The user uploads and selects avatar and voice material on the provider platform themselves, after reading that provider's current data-processing terms.

What it does not do, and what to use instead

The suite has no scheduler, no automatic publishing, and no hosted service. It is a set of instruction files plus a validation script. If you need content to leave the building on a timetable, this project will not do it, and its own rules forbid it from trying. A closer comparison is with a general-purpose agent framework plus a hand-written prompt library. The difference in approach is the checkpoint model: a prompt library gives the model instructions and trusts the output, while this suite encodes five mandatory confirmation points into the workflow and separates draft approval from publish authorisation. That structure costs you interruptions. If your content volume is high and low-risk, five gates per piece is friction you will feel. The other boundary is language and platform coverage. The platform references are written for X, Xiaohongshu, WeChat and short video, and the public-facing documentation is in Simplified Chinese with an English README. There is no evidence in the repository material of a Western platform playbook beyond X. The digital-human path is also the thinnest part of the material: the README explains the privacy stance but does not name providers or describe the production interface, so treat that module as unverified until you read its SKILL.md.

Version 0.1.0, MIT, and what maintenance actually costs

The repository is at v0.1.0, released 2026-07-26, with the last push on 2026-08-23. There is one release. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; that is the standard reading, not legal advice, and if you embed the skills in a product you should confirm the notice requirement with your own counsel. Maintenance cost is shaped by the repository layout rather than by dependencies. The README states SKILL.md files are capped at 500 lines and that platform detail lives in references directories, with copyable output templates in assets directories. That split means platform rule changes should land in references files, not in the core flow. It also means the suite's accuracy decays on the platforms' schedule, not the project's: the disclaimer states that platform rules, publishing flows and operating advice are summaries from the time of writing and that exact values should come from official announcements and the current publishing interface. Your upgrade cost is therefore mostly re-reading references when a platform changes, plus watching for changes to the skills CLI and plugin manifest formats the install paths depend on. The CI runs structural validation on every commit and performs one real install test with the official skills CLI, which is the right kind of test for a repository whose product is file structure. It does not test whether the content the skills produce is any good, and nothing in the material suggests it could.

Editorial conclusion

Adopt it if you already run an agent that supports the skills format and you want a documented draft-and-review pipeline rather than an autoposter, particularly if your output spans WeChat and Xiaohongshu and you need one evidence set rewritten per platform. Do not adopt it if you want scheduling, automatic publishing, or a non-Chinese content calendar: the suite deliberately never auto-posts and its platform references are written for Chinese platforms. Before committing, run python3 scripts/validate.py on a clone, read skills/self-media-wechat-publisher/SKILL.md to see exactly which WeChat API operations it performs against your account, and confirm which of the nine skills your agent can actually load, since the Claude Code plugin path and the npx skills path install different things.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yanhua1010/self-media-content-workflow on GitHub