Running a 17‑Week Automated WeChat Publishing Workflow with WorkBuddy

01. Define the System Before Choosing Tools

The workflow solves a concrete problem: every week select noteworthy GitHub projects, produce a verifiable Chinese report, and distribute the same content to a website candidate pool, a WeChat draft, and an email. It has four goals: scheduled start, single source of truth for research results, retain completed artifacts when downstream steps fail, and keep final publishing under human control.

It explicitly avoids fabricating data, misrepresenting star counts, and auto‑clicking the WeChat publish button, which keeps the architecture bounded and prevents error amplification.

Key quality attributes are consistency of content, traceable numbers, fault isolation, checkpoint recovery, idempotent retries, and manual final approval.

02. System Context: One Main Pipeline, Three Downstreams

The main pipeline is linear:

Scheduled Trigger
↓
Research & Verify Top 10
↓
Generate Markdown Report
↓
Create Stable Content Snapshot

After the markdown report is created, the content is dispatched to three downstream branches:

┌→ Website Candidate Pool
Markdown Report ├→ WeChat Draft
└→ Result Email

The markdown report serves as the single source of truth (SSOT). All downstream consumers read from it, so a failure in one branch does not require re‑research and prevents divergent outputs.

03. Logical Component View

Trigger & Orchestration: WorkBuddy Scheduled Task

A weekly scheduled task at 9 am on Sundays launches the pipeline and carries a prompt that defines the four ordered actions: research GitHub, generate markdown, sync website pool & create WeChat draft, and send the result email. Prompts describe goals and data scope, while reusable capabilities are encapsulated in Skills or scripts.

Content Capabilities: Three Custom Skills

content-to-wechat

handles the full WeChat publishing flow and is the core component. article-title-generator produces title candidates and filters them; it reuses methods the author previously built for title generation. humanizer-zh-adrop checks for formulaic phrasing, empty connectors, and obvious AI tone, restoring the author’s personal style. It is a customized version of the humanizer-zh project.

Skills encapsulate input, steps, hard constraints, output, and failure conditions, making them reusable across tasks as long as the input contract stays the same.

Professional Role: WeChat Operations Expert

The expert supplies writing standards such as mobile‑friendly paragraph length, detail density, and reader benefit. The workflow separates “process flow” (handled by content-to-wechat) from “writing style” (handled by the expert), allowing independent changes.

External Dependencies

Research relies on GitHub Trending, project repositories, and community discussions.

The website candidate pool uses Supabase for storage and a small site ( https://1stuser.adrop.top).

Cover images are generated with a local imagegen model; the built‑in imagegen quality is insufficient, so the author uses OpenAI’s image2 instead.

WeChat drafts are created on an Alibaba Cloud VPS because the WeChat API requires a fixed IP whitelist.

Result emails are sent via the external agent-mail skill, a service for QQ‑based agents.

All external services are treated as edge components that can fail without blocking the core report generation.

04. Data Architecture and Interface Contracts

Component hand‑offs are the most error‑prone area. The project defines simple contracts.

Input Contract

Each run must specify a clear start and end date; historical re‑runs reuse the original window to avoid overwriting past reports. For each candidate project, the system verifies repository URL, weekly star delta, README purpose, recent activity evidence (releases, commits), and community discussions (Issues, Discussions, Hacker News, Reddit). If reliable discussion is missing, the field is marked “not found” rather than fabricating consensus.

Intermediate Artifact Contract

Each markdown report includes project name, repository link, weekly and total stars, problem solved, core features & tech stack, why it’s noteworthy this week, discussion sources, and risk items. This file serves both as article material and as an audit trail.

Output Contract

A complete run can produce up to four results: a Chinese GitHub weekly report, a batch of website candidate drafts, a WeChat draft article, and an email with results and anomalies. The “up to” qualifier matters: downstream failures do not invalidate the already‑produced report.

05. Research Layer: AI Can Search, Evidence Must Remain

The research phase first gathers candidates from trending lists, then verifies project positioning, functionality, and recent changes directly in the repository. Community viewpoints are collected separately from official descriptions because they often diverge, providing the most interesting commentary.

The author requires the research to answer three questions: source of the numeric data, whether a statement reflects the project’s claim or user judgment, and whether the original link can be revisited for verification.

06. State View: Manual Gate for the Candidate Pool

After the report, the top‑10 list is written as JSON into Supabase’s projects table. A short state machine governs the pool:

new (new discovery)
↓ upsert (update if exists, insert if not)
draft (candidate draft)
↓ Manual Review
published (published)

Conflicts are resolved using a stable short project name; already published records are skipped to avoid overwriting manual adjustments.

On July 19, Supabase failed with an SSL handshake, causing the entire batch sync to fail, yet the markdown report, WeChat draft, and email succeeded, confirming the architecture’s resilience.

07. WeChat Subsystem: Writing Is Only Two Steps of Ten

The WeChat publishing skill ( content-to-wechat) is split into ten steps:

Material Analysis
↓
Title Generation
↓
Summary & Body
↓
AI‑Tone Removal & Fact Check
↓
Cover Generation
↓
Markdown Assembly
↓
HTML Pre‑check
↓
Create WeChat Draft
↓
Old Draft Handling
↓
Read‑back Verification

Only the summary and body involve actual writing; the other steps ensure consistency, compatibility, and delivery.

Title, Body, and Style Components

The title generator produces candidates from multiple angles and selects based on factual support, information density, and length. The WeChat operations expert writes the summary and body. The humanizer-zh-adrop skill removes generic phrases and checks that facts are not altered for flow.

Cover and File Assembly

Cover images are stored in the Obsidian folder WeChat Writing/attachments/. The final markdown file contains front‑matter metadata, the body, and the cover reference, ensuring a fixed format for downstream processing.

WeChat Rendering Constraints

WeChat HTML imposes limits on tables, external links, styles, and total characters (≈20 000). The author built a lightweight Node.js renderer (v5) that transforms tables into mobile‑friendly cards, deduplicates links, preserves code block indentation, removes empty list nodes, compresses styles, and strips unsupported syntax such as Obsidian callouts.

Pre‑check aborts the task if prohibited elements ( <table>, raw href, etc.) remain, preventing draft creation.

08. Email Subsystem: Result Notification with Confirmation

Email is sent via the agent-mail skill in two steps: generate a confirmation token, then send using the token. This adds a clear permission boundary and traceable action for outbound content.

The email includes the weekly report and the status of each downstream component, ensuring transparency.

09. Runtime View: How a Run Ends

At the end of each run, the system records explicit statuses for every stage: research success and report saved, candidate pool update count, WeChat draft state (pre‑check failure, draft success, or read‑back failure), email send result, and any items requiring manual handling.

Three design principles guide this view:

Persist data before distribution so short‑lived external outages do not lose research.

Each downstream records its own state, so a failure does not mask successes elsewhere.

Retries are made idempotent: website uses stable short names for conflict detection, WeChat avoids duplicate drafts, and email does not resend without a confirmed token.

10. Portability to Other Topics

The data source (GitHub) can be swapped for industry news, competitor updates, course material, or team progress. The core pipeline—fixed time window → verifiable research card → main content generation → distribution → human final judgment—remains unchanged.

To build a similar pipeline, the author suggests:

Manually complete two or three cycles and document the steps.

Fix input scope and intermediate artifacts before pursuing full automation.

Encapsulate stable, repeatable steps as Skills.

Define failure states and retry rules for every external action.

Finally, add the scheduled trigger.

Without a clear definition of “done,” a timed task would only produce vague results.

11. Benefits After 17 Weeks

Previously, creating a GitHub weekly report required 4–5 hours of manual work (ranking, repository inspection, discussion mining, Chinese write‑up, formatting, cover design, and WeChat upload). Now the author spends about ten minutes reviewing results, handling exceptions, and deciding on publication.

The 19 stored reports form a continuous data trail, revealing which projects surged briefly and which trends persisted, enabling later retrospectives.

WorkBuddy handles scheduling, Skills capture reusable methods, Codex supplies the renderer and cover generator, and the VPS with API keys connects to external platforms. The workflow is one component of a larger content system that integrates research material, weekly reports, website, WeChat, and email.

The same design can run on other agents; the custom Skills are freely available.