mufeng-materials-to-wechat-publish

Files (5)

• README.md
• SKILL.md
• openai.yaml · agents/
• platforms.md · references/
• upload_github_images.py · scripts/

SKILL.md (first lines)

# Mufeng Materials To WeChat Publish

## Resource Paths

Set the shell variable `SKILL_DIR` to the directory containing the **loaded** `SKILL.md` before running the commands below. Resolve supporting paths from that directory, not the working directory or a fixed user/platform installation path. `$SKILL_DIR` is a shell variable you set, not a host-provided macro.


## Platform Dependencies

Read [references/platforms.md](references/platforms.md) before generating images or publishing. Set `MUFENG_WECHAT_SCRIPT` to the actual `wechat-api.ts` path from an installed `baoyu-post-to-wechat` skill, or use a documented publisher already configured in the host. The variable does not install the publisher. If the dependency or credentials are missing, finish the local article and report that publishing was not executed.

## Core Rules

- Use this skill for the materials-to-article workflow. If the user already has a finished Markdown article and only needs image upload, formatting, API publishing, or publish recovery, use `mufeng-wechat-publish-full` instead.
- Start from the materials in the requested directory, not from a blank topic. Generate the article first with the `mufeng-blog-writing` skill's article-writing conventions, with this skill's frontmatter requirements taking precedence.
- Apply all seven rules in `mufeng-blog-writing/SKILL.md`, section `Reader Understanding and First Principles`: define reader and outcome, select article type, explain terminology, use a continuous case, admit only relevant body details, pass the comprehension gate, and analyze technical first principles in depth. These rules govern content depth and readability throughout this workflow.
- Apply `mufeng-blog-writing/SKILL.md`, section `Article Length and Code Budget`: normally 1000–3000 字 and never over 4000 字; default to no code and retain only indispensable snippets. Technical depth and first-principles analysis must fit within this budget. Use its visible-character counting method for the final rendered article.
- Every generated Markdown article must include SEO/GEO-friendly YAML frontmatter with `title`, `slug`, `author`, `date`, `category`, `summary`, `tags`, and later `coverImage`.
- Keep `summary` and `tags` only in YAML frontmatter. Do not add visible `摘要` headings/blocks or `标签` lines/blocks to the article body. This rule overrides `mufeng-blog-writing`'s default visible `摘要` and `标签` blocks.
- Research current WeChat search intent before drafting. Choose one primary query and 3-6 supporting terms from verifiable current evidence; if live WeChat search evidence is unavailable, label the proxy source and uncertainty instead of inventing demand.
- Map keywords naturally into the title, opening, useful H2 headings, summary, and relevant body sections. Treat YAML `tags` as internal metadata, not as a WeChat ranking signal or a substitute for body relevance.
- Use the uploaded cover in both places: as `coverImage`/`--cover` publishing metadata and as the first rendered element of the WeChat article body. Put its Markdown image immediately after the H1 so the renderer can strip the H1 while leaving the cover first; place no text, visible metadata, caption, or divider before it.
- For articles whose subject is a technical thing, satisfy the `Technical Explainer Contract` and the `No-Filler Rules` before running the quality gates. The contract is a coverage requirement, not a section template.
- Every generated or substantially revised article must pass the evidence and authenticity gate: real screenshots when available, an evidence-backed case with clear attribution, at least one failure/lesson/limitation, and 2-3 authoritative sources. Use first-person experience only when supported by the author's actual experience.
- Before publishing, pass the originality, account-fit, title-integrity, and low-quality-content gates. Revise failures; stop before publishing when a material failure cannot be fixed from available evidence.
- Every generated Markdown article must be Emoji-free. Do not add any AI-assist, AI-generated, or model-use declaration to the article body or footer.
- Resolve image providers from the current user instruction and applicable AGENTS.md first. Otherwise prefer the host tools described in `references/platforms.md`: Codex built-in generation when available, or an explicitly configured image tool on Claude Code. Do not silently switch providers or impose a Google-first fallback. If no image tool is available, keep the local article and prompts and report the missing dependency. Immediately copy adopted images into the project and verify them before continuing.
- Do not use generated images as replacements for real screenshots. Real screenshots are evidence assets; never fabricate Codex, Claude, revenue, analytics, or project UI screenshots.
- Default generated visuals to a restrained, article-specific technical-editorial direction. Do not default to neon gradients, glowing networks, floating interfaces, glossy 3D objects, robots, brains, circuit heads, or other recognizable generative-AI clichés.
- Save generated images as PNG. If a generated asset is not PNG, convert it to PNG before upload.
- Keep generated images free of readable UI text, Chinese text, labels, captions, watermarks, and signatures unless the user explicitly requests text in the image. Put titles/captions in Markdown instead.
- Do not add a `真实开发过程` section or any equivalent meta-production section about how materials, logs, commands, research, or screenshots were assembled into the article. Keep reader-relevant evidence inside the topical sections and keep workflow notes in the completion report.
- Upload the cover and all inline visual assets to GitHub image hosting, then insert `https://raw.githubusercontent.com/...` URLs into the Markdown article.
- Publish from the final Markdown file. Do not pre-convert Markdown to HTML before calling the WeChat publishing script.

## Execution Contract

Inputs:
- A source-material directory, or the current working directory if no directory is given.
- Source files may include Markdown, text notes, transcripts, outlines, screenshots/OCR notes, code snippets, and drafts.
- Optional user constraints such as target angle, title preference, image count, output filename, or whether to stop before publishing.

Outputs:
- A publish-ready Markdown article saved in the source directory, usually as `<article-slug>.md`.
- SEO/GEO-friendly frontmatter with `title`, `slug`, `author`, `date`, `category`, `summary`, `tags`, and uploaded `coverImage`.
- A documented WeChat search brief with the primary intent, primary query, 3-6 supporting terms, evidence source, and research date.
- A body that starts with the uploaded cover image after the Markdown H1 and contains no visible summary or tag metadata blocks.
- Article body with evidence-backed content: real screenshots when available, a clearly attributed case, failure/lesson/limitation, and authoritative sources.
- Local PNG images under `imgs/<article-slug>/`.
- Uploaded raw GitHub image URLs under `https://raw.githubusercontent.com/mf-blog/blogPictures/main/images/<article-slug>/...`.
- A final WeChat draft or publish result when publishing is not explicitly skipped.

Non-goals:
- Do not rewrite a finished article from scratch unless the user asks for a rewrite.
- Do not use generated images as generic decoration; each inline image should explain or reinforce nearby content.
- Do not publish before the article has metadata, image URLs, and the required ending hook.
- Do not invent personal experience, screenshots, income numbers, project results, or source citations. If evidence is unavailable, record the gap in the completion report and omit the unsupported element or use a clearly labeled non-evidence illustration.

## Markdown Emoji Rules

- The final generated `.md` article must contain no Emoji symbols anywhere.
- This ban applies to YAML frontmatter, title, H1/H2/H3 headings, summary, tags, body paragraphs, lists, blockquotes, code comments, image alt text, captions, `参考资料`, the engagement hook, footer, and any copied source-material excerpts.
- Do not add `📌 声明：本文由 AI 辅助完成` or any equivalent disclosure about AI assistance, AI generation, model use, or automated writing.
- If source materials or an existing draft contain Emoji, remove or rewrite them during article generation. Do not preserve Emoji in quotes or examples unless the user explicitly overrides this rule.
- If the `mufeng-blog-writing` footer rule is used, keep only the timestamp and location. Omit all AI-assist declarations.
- Before publishing, scan the final Markdown for Emoji and AI-assist declarations. Remove every match and re-check.

## Shared Visual Direction and Layout

Before planning images or formatting the article, read [沐风统一视觉规范](../mufeng-blog-writing/references/visual-style.md). It is the shared visual reference for this workflow and `mufeng-wechat-publish-full`.

Apply its modern humanistic editorial direction, topic variants, composition rules, prompt records, layout defaults and thumbnail/mobile checks. Use a complete text-free cover by default; a separately typeset title is optional. Keep exact diagrams deterministic and evidence screenshots authentic. Preserve explicit user choices and record unsupported layout differences rather than editing the publisher or changing the publication path.

## Technical Explainer Contract

Apply this contract when the article's subject is a technical thing: a tool, framework, API, protocol, model, library, command, or engineering method. Skip it for 成长, 读书笔记, and 投资 articles, and record the skip in the completion report.

This is a coverage requirement, not a section template. Answer each item at the depth appropriate to the reader and primary article type defined by `mufeng-blog-writing`. Do not create eight mechanical headings to satisfy it, and never add an empty heading to pass the check. Introductions may explain the starting action and link advanced commands; tutorials require a runnable path; deep analyses expand causal mechanisms and evidence. All technical documents require the first-principles analysis below.

1. **技术点是什么** — Name the exact thing and its boundary in one or two sentences before any elaboration. State what it is not whenever readers confuse it with a neighboring concept, for example MCP 与普通插件 or Agent 与 Workflow.
2. **存在的意义** — The condition that made it necessary: what people did before it existed and what that cost them. Ground this in a real constraint; `随着 AI 的发展` and similar scene-setting does not count as an answer.
3. **有什么作用** — The concrete capability, stated as outcomes a reader can verify: 能做什么, 省掉哪一步, 换来什么结果. When this would repeat 存在的意义, merge the two. Never state the same fact twice under two headings.
4. **第一性原理** — Apply rule 7 in `mufeng-blog-writing`: derive how and why the mechanism produces its outcome from verifiable facts, inputs/outputs, constraints and assumptions; explain tradeoffs and failure conditions. Support the causal chain with documentation, source, spec, experiment or mathematical reasoning. A field inventory or module list is not this analysis. Give an intuitive explanation and the concrete case before deeper implementation detail. When internals cannot be verified, analyze the known mechanism and state the unknown boundary rather than inventing it.
5. **怎么使用** — For tutorials, give a minimal runnable path: prerequisites, the smallest working command or code, expected output, verification and the one or two common errors. For introductions, give the smallest starting action and link detailed setup; keep full projects and rare errors out of the body unless needed for the reader's task.
6. **给出实战案例** — At least one evidence-backed case: context, observable result and the decision or conclusion it supports. Distinguish the author's actual work, an attributed external case and an experiment completed during this task. This satisfies the case requirement in `Article Evidence and Authenticity Rules`; never turn an execution-stage experiment into an invented author memory.
7. **痛点与解决方法** — State the reader's concrete pain in their own words, then the specific fix, then what the fix does not solve. Pair every 痛点 with a 解决方法 in the same section; an unpaired complaint is filler. The unsolved part also satisfies the failure/limitation requirement.
8. **顺序与答案前置** — Let one concrete reader problem connect the sections. Introduce the case before abstractions that depend on it; explain concepts before using them in commands or analysis. Lead with the useful answer, including necessary concrete context, and develop mechanism, action and boundaries at the chosen depth. Do not force an abstract conclusion into the first sentence when it relies on unexplained terms.

### No-Filler Rules

These extend the low-quality-content gate in `Originality and Recommendation-Readiness Gates`. Run both together.

- Deletion test: for each paragraph ask 删掉这段，读者损失了哪条信息、哪个判断、哪个步骤，或是否失去理解下一段所需的前提. Keep useful terminology explanations, grounded analogies and causal connections; delete paragraphs that serve none of these purposes.
- Remove banned openers and transitions: `随着 XX 的发展`, `众所周知`, `在当今时代`, standalone transition paragraphs, `首先/其次/最后` used as the only structure, and background scene-setting placed before the first concrete fact.
- Do not restate a conclusion already stated verbatim. A closing section may compress the argument and add the applicability boundary, but must not repeat body sentences.
- Do not paraphrase official documentation without adding a judgment, a measurement, a comparison, or a limitation.
- Cut information-free adjectives such as `非常强大` or `极其丝滑` unless the number or observation that earns them follows immediately.
- Every H2 must deliver a fact, mechanism, step, comparison, measurement, decision, or necessary explanation that helps the target reader understand them.

## Article Evidence and Authenticity Rules

Apply these rules to every generated or substantially revised article unless the user explicitly asks to skip them. If a rule cannot be satisfied from available materials or verifiable sources, do not fake it; document the gap in the completion report and, when the gap weakens the article, stop before publishing.

### Real Screenshots

- Include at least one real screenshot when source materials, local project UIs, terminal output, Codex/Claude sessions, dashboards, or user-provided screenshots are available.
- Prefer screenshots that prove the article's claims: terminal/test/build output, project interface, product result, revenue/analytics dashboard, or configuration screen.
- For income, revenue, analytics, or account screenshots, only use user-provided or locally available screenshots. Redact private data, tokens, emails, customer names, order IDs, and unrelated balances before upload.
- Do not generate fake UI screenshots. If no real screenshot is available, use a deterministic diagram or generated illustration only as supporting visual material, and do not describe it as a screenshot.

### Personal Experience and Failure Cases

- Include a concrete evidence-backed case with context, action or observation, outcome and the judgment it supports. Use first-person narration only for experience attributable to the author in the materials or confirmed by the user. Label current task experiments as verification experiments and attribute external cases to their source; neither establishes the author's personal experience. Clearly marked teaching examples may explain concepts but do not substitute for empirical evidence.
- Include at least one failure case, wrong turn, limitation, or lesson learned. Good examples: a failed prompt, broken build, rejected publish attempt, misleading metric, unusable generated image, or implementation shortcut that later caused rework.
- Keep claims bounded. Use exact numbers only when they appear in source material or verified local artifacts; otherwise use qualitative wording.

### Authoritative Sources

- Cite at least 2 authoritative sources, target 3 when the topic supports it.

From ichangyou/mf-ai-skills, MIT.

More from ichangyou/mf-ai-skills