mp-article-writor

Name: mp-article-writor
Author: balabalabalading

118stars12forks

How to install mp-article-writor?

balabalabalading/huuuuuuho-skills/mp-article-writor

$npx -y skills add balabalabalading/huuuuuuho-skills --skill mp-article-writor

Installs into the current project.

Summary

微信公众号文章创作。当用户想把工作流探索、AI 工具测评、产品体验、个人实践、生活感悟等素材整理成公众号文章时使用。即使用户只是说「帮我写篇文章」「整理成推文」「发公众号」，也应当触发此技能。

Files · 1

View on GitHub

SKILL.md

1	# 公众号文章生成
2
3	帮助作者将素材整理为一篇可直接进入微信公众号编辑和配图流程的静态图文长文。
4
5	本 Skill 只处理微信公众号。所有交给归藏 Skill 的任务都必须显式传递「微信公众号、静态图文」；禁止生成 Live Photo、MOV、PVT、GIF、MP4、视频替代品、小红书图片或其他平台封面。
6
7	## 工作流
8
9	严格按以下 11 个步骤顺序执行，不可跳步、不可合并。每一步完成后再进入下一步。
10
11	### Step 1：理解作者意图
12
13	先检查当前环境是否能够读取 `guizang-social-card-skill` 和 `guizang-material-illustration`。两个 Skill 都是完整静态视觉工作流的推荐前置条件，但不得自动安装、不得声明为强制依赖。
14
15	读取环境变量 `MP_ARTICLE_IMAGE_MODE`，只接受 `local` 或 `picgo`：
16
17	- 未设置时，使用 ask_user 工具询问一次图片发布方式，推荐并默认选择 `local`。
18	- 设置为 `local` 时，只生成本地图片，不探测 PicGo，不产生云端写入。
19	- 设置为 `picgo` 时，视为作者已经持久授权本工作流通过 PicGo 上传最终图片，再检查本机 PicGo Server 是否可访问。
20	- 值不合法时停止图片发布分支，提示改为 `local` 或 `picgo`，文章写作和本地视觉生产仍可继续。
21
22	如果任一 Skill 缺失，只提示一次并给出 `references/视觉路由.md` 中的安装命令，同时说明：文章写作仍可继续；Step 10 只能生产当前已安装 Skill 覆盖的视觉素材，缺失部分在 Step 11 标记为「待安装依赖后完成」。不要生成旧版题图或插图 prompt 作为替代，也不要在后续步骤重复提示安装。
23
24	使用 ask_user 工具向作者确认以下信息：
25
26	- 切入角度：这篇文章想从什么视角写？（技术拆解 / 个人体验 / 横向对比 / 叙事故事 / 其他）
27	- 深度偏好：读者应该获得什么程度的理解？（入门科普 / 中度解析 / 深度技术）
28	- 核心主旨：用一句话描述文章写完后读者应该记住什么
29	- 素材补充：素材中有哪些是作者的真实经历？有哪些细节需要特别保留或避免？
30	- 正文解释性插图风格：询问作者选择 `guizang-social-card-skill` 或 `guizang-material-illustration`。前者生成杂志或瑞士风格的完整排版卡片，后者生成 3D 瑞士编辑风格的材质插图。推荐选项应结合文章内容说明理由，但最终由作者确认。所选 Skill 缺失时，明确说明安装后才能生产对应插图。
31	- 现有视觉素材：确认可用的截图、照片、图表、数据和本地路径；真实素材优先承担证据作用。
32	- 输出目录：根据「视觉生产与交付」确定本次文章和图片的明确目录，并向作者展示。不得将归藏 Skill 的 `local-tests` 目录作为最终交付目录。
33	- 图片发布方式：`local` 只生成本地图片并使用相对 Markdown 路径；`picgo` 上传到作者已经配置的图床并替换为 HTTPS 地址。环境变量未设置时只询问一次。
34	- 授权方式：本次对选定归藏 Skill 的首次渲染授权，同时授权后续自动执行静态图片检查和必要修复。只有作者选择 `picgo`，或环境变量明确设置为 `picgo` 时，才包含云端上传授权。
35
36	正文解释性插图风格只询问一次。同一篇文章默认只使用一种归藏插图风格，作者明确要求混用时除外。真实截图和照片不计入风格混用。
37
38	推荐篇幅 4000-8000 字，但优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足以支撑该篇幅，短一些也无妨，在此步骤主动告知作者需要补充哪些内容，而不是自行编造。作者的可信度建立在真实性之上，编造细节或数据是不可接受的。
39
40	### Step 2：阅读参考资料，校准语感
41
42	阅读以下两份参考文件：
43
44	1. references/范文风格分析.md —— 从作者历史文章中提炼的风格特征和写作模式。必读，用于校准语感和调性。
45	2. references/行文风格指南.md —— 少数派创作手册风格指南，作为行文排版和标点符号的权威参考。必读，确保排版规则无遗漏。
46
47	### Step 3：设计大纲和风格
48
49	基于 Step 1 确认的意图和 Step 2 校准的语感，设计文章大纲。大纲应包含：
50
51	- 开头切入场景（必须是具体的、真实的事件或场景，不可编造信源）
52	- 各章节的核心论点和承载的叙事功能
53	- 计划使用的写作技巧（从「写作技巧工具箱」中选择，或不用）
54	- 结尾收束方式
55	- 视觉素材清单和页面视觉脚本，字段与路由规则见 `references/视觉路由.md`
56
57	使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。
58
59	### Step 4：编写初稿
60
61	根据确认后的大纲编写完整初稿。写作过程中遵守本文档中「作者声音」「内容要求」「行文规范」的全部规则。
62
63	初稿保存到 `projects/自媒体运营/mp-高效人生指北` 文件夹中。
64
65	### Step 5：独立审读（subagent）
66
67	调用 subagent 对初稿进行独立审读。审读重点：
68
69	- AI 味检测：哪些段落读起来像 AI 在输出信息而非人在聊天？具体到句子级别指出。
70	- 逻辑连贯性：段落之间的转折是否自然？是否有硬拼接的痕迹？
71	- 结构对称性：是否有过于整齐、对仗的结构让文章显得「被设计过」？
72	- 信息密度 vs 叙事节奏：是否有段落在堆砌信息而缺乏个人视角或情绪？
73
74	### Step 6：事实核查（subagent）
75
76	调用 subagent 对初稿中涉及的事实性内容进行核查。核查范围：
77
78	- 文中引用的数据、数字是否能在素材中找到来源？
79	- 文中描述的事件、场景是否来自真实素材，还是 AI 自行编造或合成的？
80	- 文中提及的产品名称、公司名称、技术术语拼写是否与官方一致？
81	- 文中引用的用户评价、社区讨论是否有原始出处？
82	- 视觉脚本中的截图、数据、图表、产品界面和标签是否与素材一致？
83	- 每项外部素材是否记录来源、授权状态和引用要求？
84
85	核查标准：文中每一个事实性陈述都必须能追溯到作者提供的素材、公开可验证的信息、或作者明确声明的个人经历。无法追溯的内容必须标记为「待作者确认」或删除。
86
87	### Step 7：修改初稿
88
89	根据 Step 5 和 Step 6 返回的反馈修改初稿：
90
91	- 逐条处理审读意见，对每条反馈做出「采纳」或「不采纳（附理由）」的判断
92	- 删除或改写被标记为编造的内容
93	- 修复 AI 味段落，增加个人视角、情绪或具体细节
94
95	### Step 8：终审自检（subagent）
96
97	调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。subagent 独立评分，不受前序步骤影响。
98
99	### Step 9：完成终稿
100
101	根据 Step 8 的自检结果完成最终修改。将终稿更新到文件中，附上自检报告，提供三个标题推荐，并确定用于组合封面左侧主封面区的标题和右侧方形分享区的短标题。
102
103	### Step 10：生产静态视觉素材
104
105	按 `references/视觉路由.md` 执行视觉生产：
106
107	- 使用 `guizang-social-card-skill` 直接生成一张 `3.35:1` 公众号组合封面，固定输出 `2412×720`。左侧 `1692×720` 为主封面区，右侧 `720×720` 为方形分享区；两区分别设计，在同一 HTML 画布中直接渲染为一张 PNG，不先生成两张图片再拼接。
108	- 正文解释性插图严格使用 Step 1 已确认的归藏 Skill。选择 social-card 时输出静态排版卡片 PNG 和可编辑 HTML；选择 material-illustration 时输出静态栅格插图和 `PROMPTS.md`。
109	- 真实截图、照片和图表保留为证据素材；只有在需要重点标注、对比或重新排版时才交给选定的归藏 Skill。
110	- 所有调用显式传递「目标平台：微信公众号」「交付形式：静态图文」「禁止 Live Photo、视频及其他平台输出」「最终输出目录：<明确路径>」。
111
112	视觉生产前无需再次确认授权。完成首轮渲染后自动检查尺寸、裁切、文字、数据、文件路径和移动端可读性；发现问题后修复并重新渲染。
113
114	静态检查通过后，根据 Step 1 确定的图片发布方式处理文章引用：
115
116	- `local`：保留全部本地成品，正文使用相对于文章文件的标准 Markdown 路径，例如 `![中文说明](article-assets/<文章标识>/illustrations/V01-说明.png)`。在 `SOURCES.md` 记录本地路径，并把交付状态写为「需要在公众号编辑器中手动上传图片」。本地模式属于完整交付，不标记为工作流失败。
117	- `picgo`：运行 `scripts/upload-images-to-picgo.mjs`，将一张组合封面和全部最终正文图片批量上传到本机 PicGo Server。脚本保留本地可编辑源文件，只创建临时上传副本，并以「文章标题、素材角色、时间戳」生成唯一图床文件名。用 PicGo 返回的 HTTPS 地址更新文章，front matter 的 `cover` 指向组合封面，正文使用 `![中文说明](https://...)`。同时在 `SOURCES.md` 记录本地文件与远程地址的映射。
118
119	PicGo 上传前执行 `POST /heartbeat`，旧版本返回 `404` 或 `405` 时继续尝试 `/upload`。上传后逐个验证远程地址返回 `2xx` 且内容类型为图片。不得读取、输出或写入腾讯云、GitHub、阿里云等图床凭据；上传配置完全交给作者已经配置的 PicGo。PicGo Server 默认地址为 `http://127.0.0.1:36677`，可用 `--endpoint` 或 `PICGO_SERVER_URL` 覆盖，基础地址和完整 `/upload` 地址都可使用。服务启用鉴权时只从 `PICGO_SERVER_SECRET` 环境变量取得 shared secret，不读取 PicGo 图床配置文件。
120
121	PicGo 连接失败、超时、鉴权失败或返回异常时，不修改文章中的本地图片引用，不删除本地成品。将交付状态写为「图片发布待完成」，记录失败信息和可重新执行的命令。
122
123	如果所需归藏 Skill 未安装，跳过该 Skill 对应的视觉生产，保留已经完成的文章和其他视觉素材，并把缺失项、安装命令和恢复入口写入交付检查。不得静默切换到另一种插图风格。
124
125	### Step 11：交付检查
126
127	逐项确认：
128
129	- 终稿、一张组合封面、正文插图、真实素材、可编辑文件和来源记录均存在于明确输出目录；因归藏 Skill 缺失而未生成的项目已明确列入待完成清单。
130	- 公众号组合封面为 `2412×720`。左侧主封面区为 `1692×720`，右侧方形分享区为 `720×720`，两区分别设计并位于同一张 PNG 中。
131	- 正文解释性插图与 Step 1 选择一致，没有混入另一种归藏风格。
132	- 图片中的中文标签、图表数据、产品名称和文章事实一致。
133	- 所有本地素材路径可读

People who liked this also viewed

6 picks

Type

mp-article-writor

118stars12forks

View on GitHub

How to install mp-article-writor?

balabalabalading/huuuuuuho-skills/mp-article-writor

$npx -y skills add balabalabalading/huuuuuuho-skills --skill mp-article-writor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 公众号文章生成
2
3	帮助作者将素材整理为一篇可直接进入微信公众号编辑和配图流程的静态图文长文。
4
5	本 Skill 只处理微信公众号。所有交给归藏 Skill 的任务都必须显式传递「微信公众号、静态图文」；禁止生成 Live Photo、MOV、PVT、GIF、MP4、视频替代品、小红书图片或其他平台封面。
6
7	## 工作流
8
9	严格按以下 11 个步骤顺序执行，不可跳步、不可合并。每一步完成后再进入下一步。
10
11	### Step 1：理解作者意图
12
13	先检查当前环境是否能够读取 `guizang-social-card-skill` 和 `guizang-material-illustration`。两个 Skill 都是完整静态视觉工作流的推荐前置条件，但不得自动安装、不得声明为强制依赖。
14
15	读取环境变量 `MP_ARTICLE_IMAGE_MODE`，只接受 `local` 或 `picgo`：
16
17	- 未设置时，使用 ask_user 工具询问一次图片发布方式，推荐并默认选择 `local`。
18	- 设置为 `local` 时，只生成本地图片，不探测 PicGo，不产生云端写入。
19	- 设置为 `picgo` 时，视为作者已经持久授权本工作流通过 PicGo 上传最终图片，再检查本机 PicGo Server 是否可访问。
20	- 值不合法时停止图片发布分支，提示改为 `local` 或 `picgo`，文章写作和本地视觉生产仍可继续。
21
22	如果任一 Skill 缺失，只提示一次并给出 `references/视觉路由.md` 中的安装命令，同时说明：文章写作仍可继续；Step 10 只能生产当前已安装 Skill 覆盖的视觉素材，缺失部分在 Step 11 标记为「待安装依赖后完成」。不要生成旧版题图或插图 prompt 作为替代，也不要在后续步骤重复提示安装。
23
24	使用 ask_user 工具向作者确认以下信息：
25
26	- 切入角度：这篇文章想从什么视角写？（技术拆解 / 个人体验 / 横向对比 / 叙事故事 / 其他）
27	- 深度偏好：读者应该获得什么程度的理解？（入门科普 / 中度解析 / 深度技术）
28	- 核心主旨：用一句话描述文章写完后读者应该记住什么
29	- 素材补充：素材中有哪些是作者的真实经历？有哪些细节需要特别保留或避免？
30	- 正文解释性插图风格：询问作者选择 `guizang-social-card-skill` 或 `guizang-material-illustration`。前者生成杂志或瑞士风格的完整排版卡片，后者生成 3D 瑞士编辑风格的材质插图。推荐选项应结合文章内容说明理由，但最终由作者确认。所选 Skill 缺失时，明确说明安装后才能生产对应插图。
31	- 现有视觉素材：确认可用的截图、照片、图表、数据和本地路径；真实素材优先承担证据作用。
32	- 输出目录：根据「视觉生产与交付」确定本次文章和图片的明确目录，并向作者展示。不得将归藏 Skill 的 `local-tests` 目录作为最终交付目录。
33	- 图片发布方式：`local` 只生成本地图片并使用相对 Markdown 路径；`picgo` 上传到作者已经配置的图床并替换为 HTTPS 地址。环境变量未设置时只询问一次。
34	- 授权方式：本次对选定归藏 Skill 的首次渲染授权，同时授权后续自动执行静态图片检查和必要修复。只有作者选择 `picgo`，或环境变量明确设置为 `picgo` 时，才包含云端上传授权。
35
36	正文解释性插图风格只询问一次。同一篇文章默认只使用一种归藏插图风格，作者明确要求混用时除外。真实截图和照片不计入风格混用。
37
38	推荐篇幅 4000-8000 字，但优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足以支撑该篇幅，短一些也无妨，在此步骤主动告知作者需要补充哪些内容，而不是自行编造。作者的可信度建立在真实性之上，编造细节或数据是不可接受的。
39
40	### Step 2：阅读参考资料，校准语感
41
42	阅读以下两份参考文件：
43
44	1. references/范文风格分析.md —— 从作者历史文章中提炼的风格特征和写作模式。必读，用于校准语感和调性。
45	2. references/行文风格指南.md —— 少数派创作手册风格指南，作为行文排版和标点符号的权威参考。必读，确保排版规则无遗漏。
46
47	### Step 3：设计大纲和风格
48
49	基于 Step 1 确认的意图和 Step 2 校准的语感，设计文章大纲。大纲应包含：
50
51	- 开头切入场景（必须是具体的、真实的事件或场景，不可编造信源）
52	- 各章节的核心论点和承载的叙事功能
53	- 计划使用的写作技巧（从「写作技巧工具箱」中选择，或不用）
54	- 结尾收束方式
55	- 视觉素材清单和页面视觉脚本，字段与路由规则见 `references/视觉路由.md`
56
57	使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。
58
59	### Step 4：编写初稿
60
61	根据确认后的大纲编写完整初稿。写作过程中遵守本文档中「作者声音」「内容要求」「行文规范」的全部规则。
62
63	初稿保存到 `projects/自媒体运营/mp-高效人生指北` 文件夹中。
64
65	### Step 5：独立审读（subagent）
66
67	调用 subagent 对初稿进行独立审读。审读重点：
68
69	- AI 味检测：哪些段落读起来像 AI 在输出信息而非人在聊天？具体到句子级别指出。
70	- 逻辑连贯性：段落之间的转折是否自然？是否有硬拼接的痕迹？
71	- 结构对称性：是否有过于整齐、对仗的结构让文章显得「被设计过」？
72	- 信息密度 vs 叙事节奏：是否有段落在堆砌信息而缺乏个人视角或情绪？
73
74	### Step 6：事实核查（subagent）
75
76	调用 subagent 对初稿中涉及的事实性内容进行核查。核查范围：
77
78	- 文中引用的数据、数字是否能在素材中找到来源？
79	- 文中描述的事件、场景是否来自真实素材，还是 AI 自行编造或合成的？
80	- 文中提及的产品名称、公司名称、技术术语拼写是否与官方一致？
81	- 文中引用的用户评价、社区讨论是否有原始出处？
82	- 视觉脚本中的截图、数据、图表、产品界面和标签是否与素材一致？
83	- 每项外部素材是否记录来源、授权状态和引用要求？
84
85	核查标准：文中每一个事实性陈述都必须能追溯到作者提供的素材、公开可验证的信息、或作者明确声明的个人经历。无法追溯的内容必须标记为「待作者确认」或删除。
86
87	### Step 7：修改初稿
88
89	根据 Step 5 和 Step 6 返回的反馈修改初稿：
90
91	- 逐条处理审读意见，对每条反馈做出「采纳」或「不采纳（附理由）」的判断
92	- 删除或改写被标记为编造的内容
93	- 修复 AI 味段落，增加个人视角、情绪或具体细节
94
95	### Step 8：终审自检（subagent）
96
97	调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。subagent 独立评分，不受前序步骤影响。
98
99	### Step 9：完成终稿
100
101	根据 Step 8 的自检结果完成最终修改。将终稿更新到文件中，附上自检报告，提供三个标题推荐，并确定用于组合封面左侧主封面区的标题和右侧方形分享区的短标题。
102
103	### Step 10：生产静态视觉素材
104
105	按 `references/视觉路由.md` 执行视觉生产：
106
107	- 使用 `guizang-social-card-skill` 直接生成一张 `3.35:1` 公众号组合封面，固定输出 `2412×720`。左侧 `1692×720` 为主封面区，右侧 `720×720` 为方形分享区；两区分别设计，在同一 HTML 画布中直接渲染为一张 PNG，不先生成两张图片再拼接。
108	- 正文解释性插图严格使用 Step 1 已确认的归藏 Skill。选择 social-card 时输出静态排版卡片 PNG 和可编辑 HTML；选择 material-illustration 时输出静态栅格插图和 `PROMPTS.md`。
109	- 真实截图、照片和图表保留为证据素材；只有在需要重点标注、对比或重新排版时才交给选定的归藏 Skill。
110	- 所有调用显式传递「目标平台：微信公众号」「交付形式：静态图文」「禁止 Live Photo、视频及其他平台输出」「最终输出目录：<明确路径>」。
111
112	视觉生产前无需再次确认授权。完成首轮渲染后自动检查尺寸、裁切、文字、数据、文件路径和移动端可读性；发现问题后修复并重新渲染。
113
114	静态检查通过后，根据 Step 1 确定的图片发布方式处理文章引用：
115
116	- `local`：保留全部本地成品，正文使用相对于文章文件的标准 Markdown 路径，例如 `![中文说明](article-assets/<文章标识>/illustrations/V01-说明.png)`。在 `SOURCES.md` 记录本地路径，并把交付状态写为「需要在公众号编辑器中手动上传图片」。本地模式属于完整交付，不标记为工作流失败。
117	- `picgo`：运行 `scripts/upload-images-to-picgo.mjs`，将一张组合封面和全部最终正文图片批量上传到本机 PicGo Server。脚本保留本地可编辑源文件，只创建临时上传副本，并以「文章标题、素材角色、时间戳」生成唯一图床文件名。用 PicGo 返回的 HTTPS 地址更新文章，front matter 的 `cover` 指向组合封面，正文使用 `![中文说明](https://...)`。同时在 `SOURCES.md` 记录本地文件与远程地址的映射。
118
119	PicGo 上传前执行 `POST /heartbeat`，旧版本返回 `404` 或 `405` 时继续尝试 `/upload`。上传后逐个验证远程地址返回 `2xx` 且内容类型为图片。不得读取、输出或写入腾讯云、GitHub、阿里云等图床凭据；上传配置完全交给作者已经配置的 PicGo。PicGo Server 默认地址为 `http://127.0.0.1:36677`，可用 `--endpoint` 或 `PICGO_SERVER_URL` 覆盖，基础地址和完整 `/upload` 地址都可使用。服务启用鉴权时只从 `PICGO_SERVER_SECRET` 环境变量取得 shared secret，不读取 PicGo 图床配置文件。
120
121	PicGo 连接失败、超时、鉴权失败或返回异常时，不修改文章中的本地图片引用，不删除本地成品。将交付状态写为「图片发布待完成」，记录失败信息和可重新执行的命令。
122
123	如果所需归藏 Skill 未安装，跳过该 Skill 对应的视觉生产，保留已经完成的文章和其他视觉素材，并把缺失项、安装命令和恢复入口写入交付检查。不得静默切换到另一种插图风格。
124
125	### Step 11：交付检查
126
127	逐项确认：
128
129	- 终稿、一张组合封面、正文插图、真实素材、可编辑文件和来源记录均存在于明确输出目录；因归藏 Skill 缺失而未生成的项目已明确列入待完成清单。
130	- 公众号组合封面为 `2412×720`。左侧主封面区为 `1692×720`，右侧方形分享区为 `720×720`，两区分别设计并位于同一张 PNG 中。
131	- 正文解释性插图与 Step 1 选择一致，没有混入另一种归藏风格。
132	- 图片中的中文标签、图表数据、产品名称和文章事实一致。
133	- 所有本地素材路径可读

People who liked this also viewed

6 picks

Type