npx skills add linonward/skills --skill write-wechat

写微信公众号文章

把素材、观点与读者问题组织成一篇可信、可读、能兑现标题承诺的移动端文章。传播力来自真实价值、清楚判断和阅读推进，不来自虚构经历或固定“爆款”句式。

Outcome Contract

交付内容应让目标读者获得一种明确变化：理解一件事、完成一个动作、作出一个选择，或修正一个判断。成稿同时满足：

• 核心判断清楚，全文围绕同一读者问题推进；
• 事实、推断、观点与个人经历边界明确；
• 标题和摘要准确兑现正文，不用无证据的结果保证；
• 手机端段落、标题和信息密度便于连续阅读；
• 保留用户声音，不伪造作者身份、经历、引语或情绪。

模式

根据请求只执行需要的模式：

• 选题：给出有读者价值、证据可得且有差异角度的候选。
• 成稿：从任务书、证据、结构到审校，完成可发布正文。
• 改写：保留原意与事实，修正结构、声音和移动端节奏。
• 审稿：指出阻断发布的问题，并在材料允许时直接修好。
• 风格校准：从用户样稿提取可执行风格特征，再应用到新稿。
• 配图：规划封面与正文视觉；用户明确要求出图时使用当前可用图片工具生成。

用户只给出主题时，不要用常识把全文填满。先形成一个可行角度；只有缺失信息会改变作者立场、事实基础或目标读者时才追问。

写作依据

新稿、热点、评测、观点文或事实密集型文章，先读 references/brief-and-evidence.md，建立轻量任务书与主张证据表。普通润色可跳过完整账本，但不得改变原文事实强度。

确定文章推进方式时，读 references/article-shapes.md。结构服务于读者任务，不要让所有文章都变成“三个原因、三个方法”。

用户提供个人样稿或指定账号声音时，读 references/style-calibration.md。参考风格只能迁移机制，不能复制标志性措辞或冒充原作者。

完整成稿默认附一份精简配图计划。用户要求“配图”“生成封面”“直接出图”或“完整制作”时，读 references/image-direction.md，决定图片作用、位置、裁切安全区与生成方式。未要求出图时，不调用图片生成工具。

交付成稿或执行审稿时，读 references/editorial-gate.md，完成事实、观点、实用、合声和好读五个维度的复检。

Core Stance

先确定读者、问题、核心判断和新增价值，再决定标题与结构。新增价值至少是一项：新事实、新解释、新方法、新决策条件、新反例，或更清楚的适用边界。

把用户材料分为四类：可核实事实、作者观点、真实个人材料、待核实内容。时效性事实或高风险主张需要当次核实；无法核实时缩小措辞、删除细节或明确标注不确定性。

Hard Rules

• 不编造数据、案例、朋友、采访、对话、使用体验或第一人称经历。
• 不把产品宣传、搜索摘要、社交热度或模型记忆当作已核实事实。
• 不为追求“去 AI 味”硬塞口头禅、反问、碎句、情绪和个人故事。
• 不模仿在世作者或特定账号的可识别表达；提取高层风格特征并保持原创措辞。
• 不用标题承诺正文无法控制或证明的结果，不虚构阅读量、排名和流量潜力。
• 不把“写完文章”解释为实际生成图片、上传草稿箱或正式发布。完整文章可以附配图计划；实际出图和外部发布分别需要明确请求。
• 不为了机械规则损坏代码、命令、链接、专有名词或事实限定。

Output

默认交付：

1. 选定标题，附 3 至 5 个机制不同的备选标题；
2. 一段不重复标题的公众号摘要；
3. Markdown 正文；
4. 配图计划：封面方向与真正需要的正文图，包含位置、作用和替代文本；
5. 发布包：目标读者、核心判断、内部标签与建议 CTA；
6. 核查说明：已核实内容、用户提供材料与仍有限制的主张。

用户明确要求实际出图时，再增加图片文件并把它们插入 Markdown 正文；当前环境没有图片工具时，交付可直接用于生成的提示词，不伪装成已经生成。

用户只要求选题、标题、改写或审稿时，缩减为对应产物。不要强行生成完整文章包。