WeChat Tech Article

Overview

Structuredly complete a technical article for WeChat Official Accounts, from topic selection to finalization. Follow the specifications and existing article style of

blogs/wechat

Hard Gates (Mandatory Requirements)

Style Source (Mandatory): Must read the following before writing:
- ```
blogs/wechat/README.md
```
  (directory/naming/publishing rhythm)
- ```
skills/wechat-tech-article/references/style-guide.md
```
  (your fixed writing style and structure framework)

Directory Naming:

posts/YYYY/YYYY-MM-DD-<kebab-case-english-slug>/

File Naming: The directory name must be exactly the same as the .md file name
Slug Rules: Use only English (no Pinyin), separate with
```
-
```
, keep it as concise as possible
Reference Path: Use relative path
```
./
```
when referencing local files in the article
Structure Hard Gates (Mandatory):
- The first line must be
```
# Title
```
- Within 10-15 lines after the title, there must be: an entry link (one of GitHub/download/online experience) + a bolded
```
**tagline**
```
- Only use
```
#
```
  /
```
##
```
  for headings in the article body (prohibit using
```
###
```
  and deeper levels)
Reproducibility First (Mandatory): Include at least 2 copyable code blocks (choose from bash/yaml/toml/json), with accompanying explanations

Workflow (Four Phases)

Phase 1: Topic & Positioning

Input: Topic/idea provided by the user

Execution:

Clarify the following:
- What problem does this article solve for readers?
- Who is the target audience? (Developers, DevOps, technical managers?)
- What is your unique perspective? (Content no one else has written, your own experience)
Generate 3 candidate slugs based on the topic for the user to choose from
Select the article mode (only affects content organization, not your "typesetting signature"):
- Mode A: Open source project/tool release (official account style: strong hook, early entry link, many reproducible steps)
- Mode B: Technical popularization/architecture deep dive (technical blog style: clear hierarchy, problem definition, mechanism breakdown)
Create the article directory and .md file skeleton
Generate title candidates (see "Title Workshop" below), proceed to the outline phase only after the user confirms the title

Output:

posts/YYYY/YYYY-MM-DD-<slug>/
└── YYYY-MM-DD-<slug>.md  # Contains basic skeleton

Skeleton Template:

markdown

# [Title: One-sentence value statement]

> [Subtitle: Scenario description/problem introduction]

# Preface

[Why write this article, who should read it]

# [Core Chapter 1]

## [Section 1]

## [Section 2]

## [Section N]

# [Core Chapter 2]

# [Core Chapter N]

# Conclusion

[Summary + action suggestions]

---

Title Workshop (Viral but Authentic)

Goal: Generate titles "like you write": strong hook, scenario-focused, actionable; avoid overstatement.

Mandatory Title Requirements:

Cannot promise unprovable benefits (e.g., "10x efficiency boost" unless you have benchmarks/data)
The title must include at least two of the following: object/tool + scenario/pain point + benefit/result + suspense (choose any two or more)

Generation Rules (prioritize your commonly used hook styles):

Rhetorical question/contrast: e.g., "No way? You're still doing...?"
"I built/I open-sourced...": Suitable for Mode A
Migration/replacement: e.g., "This open-source plugin helped me migrate from A to B"
Workflow/convenience: e.g., "I turned X into a handy CLI"

Output Format:

Generate 8 title candidates, grouped by type (choose from pain point/number/result/suspense/list/counterintuitive)
Each title is accompanied by 1 line of note: suitable audience + core benefit
Provide Top 2 recommendations + reasons (specificity/credibility/audience matching)

Phase 2: Outline & Research

Execution:

Refine the outline (3-5 key points per chapter)
Mark content that requires research (data, references, cases), prioritize recent information (current month/quarter); outdated materials must be labeled "may be outdated"
Collect information sources in parallel (official documentation / authoritative blogs / community discussions) to avoid single-source bias
Mark materials that need preparation (code snippets, screenshots, diagrams)
If image generation is needed, choose based on environment capabilities:
- If image generation tools are supported: Generate and save to the article directory (same level or
```
assets/
```
  )
- Otherwise: List a "required image checklist" and explain what each image demonstrates/proves

Outline Format:

markdown

# [Chapter Title]
- Key Point A
- Key Point B [requires data support]
- Key Point C [requires code example]
- [may require diagram]

Material Checklist (create in the same directory):

posts/YYYY/YYYY-MM-DD-<slug>/
├── YYYY-MM-DD-<slug>.md
├── outline.md           # Detailed outline
├── research.md          # Research materials
└── assets/              # Images and other resources (optional; can also be placed at the same level)

Phase 3: Section-by-Section Writing

Principles:

Write only one section at a time
Pause after completing a section and wait for user feedback
Proceed to the next section only after user confirmation

Writing Checkpoints (ask yourself after completing each section):

Is there specific examples/code/data to support it?
Have empty clichés been avoided?
Does it match the user's writing style?
Are relative paths used for referencing local resources?

Hook Optimization (pay special attention to the opening paragraph):

Start with data/story/questions, not "Today we're going to talk about X"
The first three sentences determine whether readers will continue reading

Phase 4: Finalization & Publishing Preparation

Checklist:

Title: Is the value clear at a glance?
Subtitle: Does it arouse curiosity?
Length: 2000-4000 words is recommended for official accounts
Images: Is there a cover image?
Code blocks: Is syntax highlighting correct?
Links: Are all links clickable?
Typesetting signature: Short paragraphs (3-4 lines), bold keywords, white space before and after code blocks

Publishing Recommendations (based on README.md):

Time zone: Beijing Time (CST / Asia/Shanghai)
Official account: 21:30 on Tuesday; alternative: 21:30 on Wednesday/Thursday; extra (optional): 21:00 on Sunday (long-tail for long articles)
Moments diversion: 10–20 minutes after the article is published

Output:

✅ Finalized article: posts/YYYY/YYYY-MM-DD-<slug>/YYYY-MM-DD-<slug>.md
📊 Word count: [N] words
📅 Recommended publishing time: [Date Time]

Prohibited Items

Prohibited: Write the entire article at once before showing it to the user
Prohibited: Use Pinyin for slugs
Prohibited: Use absolute paths to reference local files
Prohibited: Skip the outline phase and directly write the body
Prohibited: Use clichéd openings like "Today we're going to talk about"
Prohibited: Use images as decoration (each image must be explained before and after to show what it demonstrates/proves)

Style Guide

Mandatory default compliance:

skills/wechat-tech-article/references/style-guide.md

The following is a "quick reference" style fingerprint (helps with quick self-check, does not replace the original document):

Get straight to the point: The preface directly states "What problem I encountered → How I solved it"
Clear structure: Use more subheadings, lists, tables
Code with explanations: Must include explanations after code blocks
Clear viewpoints: Don't be afraid to say "This is not good", "I think"
Actionable conclusion: Give readers 1-2-3 executable suggestions

Template & Long Article Specifications

For copyable templates (Mode A/Mode B), prioritize reference to:

skills/wechat-tech-article/references/style-guide.md

For a streamlined copyable template for "quick writing":

skills/wechat-tech-article/references/templates.md

For a "style cheat sheet" (condensed version of the mandatory default style):

skills/wechat-tech-article/references/style-cheatsheet.md

wechat-tech-article

NPX Install

Tags

SKILL.md Content (Chinese)