Content & publishing

Release scheduling

Split one piece of content into platform × format units, and catch the missing asset before publishing.

Paid $9 list, $7 until 2026-12-31 · one skill, yours for good. The outline, the steps and the file open after purchase.

Background

The most expensive mistake in publishing is not a failed upload, but discovering only after it went out that the asset was wrong or the timing was wrong. A failed upload can be retried; a wrong time can only be deleted and reposted. So every check moves forward and is completed before the "publish" button is pressed.

Why it is built this way

Publishing breaks in two different ways, and only one of them is recoverable. A rejected upload can be retried in the same minute; a piece that went out at the wrong time has to be deleted and posted again, losing the queue position it had. So the skill splits one creation into release units of content times platform times account times time, then moves every check in front of the publish button. The seven steps run plan, check, backfill, single-unit verification, batch publish, log, postcheck, and nothing after the publish step can repair an asset that was wrong.

The single-unit step carries most of the weight. The first time a platform uses a given publish parameter, scheduling above all, one item goes out and gets verified in the backend, and first_run_verified: true is written back; until that flag exists, batch publishing stays blocked. Gaps come graded block, warn, info, with block covering a missing file, an empty account, a spec mismatch and an unverified first run. A block is never regraded to warn to get something out the door, and release_check.py returns exit code 0 only when the unit is clean.

Where it bites

• Block quietly regraded A missing file, an empty account, a spec mismatch and an unverified first run are all block. Calling one of them warn so the batch can proceed is how several wrong assets go out in one round; the document records a Xiaohongshu release with 3 wrong items from exactly that. Block gets filled and re-checked.
• A schedule that never fires The platform API accepts a scheduled job and the backend shows nothing at the appointed minute. Step 4 exists for this: publish one item, confirm it in the backend, write back first_run_verified, only then batch. Step 7 postcheck compares the live status against the ledger after the scheduled time.
• One check for three units Content times platform times account times time turns one finished piece into three units that need different assets. Checking the finished video once and shipping all three leaves the image-and-text unit without its carousel of a cover plus 5 to 8 images, an asset the matrix assigns to xiaohongshu-material.
• No ledger row Without the ledger row of platform, link, actual time and status, a scheduled item that went live late or not at all leaves nothing to compare against. Postcheck then has no object to read, and deciding whether to repost becomes a guess about which unit already exists.

When to use it

Release scheduling and pre-publish verification: split one content item into publish units of platform × spec, check whether the assets are complete (final cut / image carousel / cover / title / body copy / hashtags / account / schedule), and for anything missing state exactly which asset to add and which skill owns it (video-editing, xiaohongshu-material, wechat-material, agent-caption etc.), while maintaining the release ledger and the post-publish re-check. Use when preparing to publish, for multi-platform distribution, scheduling, checking before publishing, asking whether the assets are complete, scheduled publishing, or the release ledger. Does not replace the upload action of the per-platform upload skills.