1. 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)
2. Directory Naming:

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

3. File Naming: The directory name must be exactly the same as the .md file name
4. Slug Rules: Use only English (no Pinyin), separate with

   -

   , keep it as concise as possible
5. Reference Path: Use relative path

   ./

   when referencing local files in the article
6. 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)
7. Reproducibility First (Mandatory): Include at least 2 copyable code blocks (choose from bash/yaml/toml/json), with accompanying explanations

1. 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)
2. Generate 3 candidate slugs based on the topic for the user to choose from
3. 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)
4. Create the article directory and .md file skeleton
5. Generate title candidates (see "Title Workshop" below), proceed to the outline phase only after the user confirms the title

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

undefined

[Subtitle: Scenario description/problem introduction]

• 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)

• 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"

• 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)

1. Refine the outline (3-5 key points per chapter)
2. Mark content that requires research (data, references, cases), prioritize recent information (current month/quarter); outdated materials must be labeled "may be outdated"
3. Collect information sources in parallel (official documentation / authoritative blogs / community discussions) to avoid single-source bias
4. Mark materials that need preparation (code snippets, screenshots, diagrams)
5. 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

undefined

• 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):

undefined

• 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

• 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?

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

• 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

• 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

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

• 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)

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

• 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