Communitygithub.com

AidenXu-1/wechat-layout-publisher

公众号排版发布 Skill:四路语义配图、2.35:1 封面、可复制 HTML 与草稿箱发布

¿Qué es wechat-layout-publisher?

wechat-layout-publisher is a Claude Code agent skill that 公众号排版发布 Skill:四路语义配图、2.35:1 封面、可复制 HTML 与草稿箱发布.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add AidenXu-1/wechat-layout-publisher

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

公众号排版发布

把可读取的资料或文章制作成一份公众号正文母版,再由同一母版进入修改、草稿箱和正式归档。收口后只保留本 Skill 的最终可复制 HTML,以及本 Skill 在直接改写入口亲自写出的 Markdown 终稿。

进入边界

支持会话直接入口和任意上游 Skill 续接。进入前必须同时满足:

  1. destination 已确认是 wechat_official_account
  2. 当前任务已进入公众号定稿、配图、排版、正式可复制版或草稿箱制作阶段。
  3. 源资料或文章可以读取。

用户只要正文、只要初稿、平台待定或目标为其他平台时,继续原工作流。Skill 续接时读取 references/upstream-handoff.md;不要向用户展示内部交接模板,也不要让上游替用户猜选择。

开局确认

开始制作前只确认内容处理模式:

开始前请确认内容处理模式:

A. 杂乱资料:梳理并产出公众号定稿文案,再配图排版
B. 初稿文案:检查优化内容细节并产出定稿,再配图排版
C. 发布定稿:保持文案内容不变,只做配图、排版和格式规范

用户请求或可追溯交接已经明确内容模式时不重复询问。内容模式确定前不得改写、规划配图、生成图片、制作预览或调用微信接口。首次正式可复制版完成前不要求用户决定草稿箱或归档。

把选择原样写入 image-plan.json

  • 内容 A:input_stage: messy_materialscontent_mode: rewrite
  • 内容 B:input_stage: draft_copycontent_mode: rewrite
  • 内容 C:input_stage: final_copycontent_mode: preserve
  • 首次交付前固定记录 interaction_contract_version: 3review_choice: pendingdelivery_mode: copy_readydraft_authorization: nonearchive_authorization: noneapproved_body_sha256: ""body_image_upload_authorization: copy_ready_request
  • 同时记录 content_choicechoice_source: direct_user | upstream_user_confirmationdestination: wechat_official_accountentry_mode: direct | skill_handoff;续接入口另记 handoff_version: 1source_skill
  • 从创建第一个文件或目录起维护 artifact_ownership.skill_created_filesskill_created_directoriesprotected_external_files。前两者只列本 Skill 本次真实创建的文件和目录;后者列用户文件、上游文档和外部素材,清单不得重叠。

默认交付循环

首次正式可复制版完成并通过质量闸门后,提供 HTML 并主动询问:

当前可复制版已经完成。是否通过,可以加入公众号草稿箱?需要修改请直接告诉我。
  • 用户提出修改:按 references/publishing.md 完整退回修改状态并清空旧批准;修改、重验后重新交付完整 HTML。
  • 用户确认加入草稿箱:把最新视觉 QA 回执中的正文哈希写入 approved_body_sha256,更新为 review_choice: draftdelivery_mode: draftpost_preview_confirmation 授权。草稿入口必须核对当前正文与该哈希完全一致;正文有任何变化都停止并重新确认。
  • 草稿成功:返回 media_id,提醒“进入草稿箱不等于公开发布”,记录 archive_authorization: post_draft_success,然后按 references/archive.md 自动把同一最终 HTML 写入调用项目提供的正式目标位置;不再询问是否收口。

只有用户明确说“只要手动复制版”时才跳过草稿 API;用户明确要求“直接加入草稿箱”时可以跳过用户预览,但仍完成全部内部质量检查。不要主动向用户展示这些内部路线或状态名。

五条硬合同

  1. 内容边界
    • messy_materials 保存可追溯源资料,分开事实、观点、经历、数据、重复、冲突和待核项,再按读者理解顺序成文。
    • draft_copy 以初稿为母版,保护事实、立场、证据边界和真实声音;按结构与动力、证据连接、段落呼吸、词句准确的顺序修订。
    • final_copy 只改变 HTML 结构和视觉节奏。正文字符、标点与顺序不得变化;缺少标题时先请用户补充或取得单独新增授权。副标题按文章需要选用,用户明确不需要时记录 subtitle_policy: omitted_by_user,不为通过校验强行新增。
  2. 编辑与图片计划
    • 搜索、生成或绘图前创建 image-plan.json。新建或重做的 rewrite 任务必须使用 editorial_contract_version: 1 和可验证的 editorial_plandraft_copy 另含 voice_fingerprintrevision_priorities
    • 旧文章包只有显式使用验证器的 --allow-legacy-editorial 才能走兼容路径;新任务禁止使用该开关。
  3. 真实视觉来源
    • 每个视觉只走 user_assetevidence_screenshotgenerated_imagecoded_visual 中的一条路线。证据必须来自真实来源,代码图只解释结构。
    • 标题与副标题之后的首图必须由真实生图工具生成,准确 H1 自然融入 2.35:1 构图,最终文件至少 900×383。纯图、用户图、截图、代码图或脚本贴字不能代替。
    • 当前 Agent 无生图能力时,告知用户并停在本地工作预览;保留完整提示词,首图返回前不得正式交付。
  4. 单一正文母版
    • 正文使用 ARTICLE HTML STARTARTICLE HTML END 标记,只含微信安全的内联 HTML。预览按钮、状态条和脚本只能在标记外。
    • 正文视觉按计划顺序使用唯一 data-wlp-visual-id;所有强视觉统一计入密度。相邻强视觉之间必须有承担新信息的正文。
  5. 授权与安全
    • copy_ready 可以准备正文图片,但绝不创建草稿。普通路线只有用户确认当前 HTML 后才记录正文哈希并更新草稿授权;直接草稿路线只接受用户当前明确指令。
    • 只有 delivery_mode: draft、草稿授权与正文哈希合同同时有效时才能调用 draft/add。普通路线发送的 ARTICLE HTML 正文必须与用户最新确认版本逐字节一致。凭据只从环境变量、本地 .env 或本 Skill 的标准系统凭据位置读取,不搜索旧聊天、随机文件、shell 历史或无关钥匙串。
    • IP 白名单以微信接口 40164 返回的 invalid ip 为准。普通公网 IP 探测只作参考;代理、TUN 或分流存在时,不得用与微信实测不同的探测结果指导用户。
    • 收口只删除 artifact_ownership.skill_created_files 中逐条登记的文件,只移除 skill_created_directories 中已经变空的目录;禁止通配符、目录扫描和整目录递归删除。用户文件、用户目录、上游文档、外部素材及来源不明路径永不移动、覆盖或删除。
    • 不创建名为 WeChatwechat 的文件夹。临时素材使用当前文章工作目录内的普通子目录,收口后只删除已登记且属于本 Skill 的文件。

按需读取

只在进入对应阶段时加载,避免把低频发布细节提前塞进上下文:

阶段读取
Skill 续接references/upstream-handoff.md
内容规划references/content-planning.mdrewrite 再读 references/editorial-writing.md
图片计划references/image-placement.md,从 assets/image-plan.template.json 起步
视觉制作references/visual-quality.mdreferences/cover-system.md
HTML 排版references/style-guide.mdreferences/components.md
最终检查references/qa-checklist.md
上传正文图或草稿箱references/publishing.md
草稿成功或用户明确只收口手动复制版references/archive.md

final_copy 不加载改写规则。只需要本地预览时不加载发布凭据和草稿 API 细节。

执行顺序

  1. 收集与核查:确认源文章、标题、可选副标题、作者或栏目名,以及全部用户图片和视频。先盘点用户素材;相关视频提取带时间戳的代表帧。依赖时效事实时联网核查一手来源。
  2. 完成内容规划:记录内容类型、置信度、依据、核心主张、读者承诺和章节地图。rewrite 完成编辑规划与定稿;entry_mode: directrewrite 同时写出本 Skill 自有的 公众号文案终稿.md,登记后在收口时保留。preserveskill_handoff 默认不另建 Markdown,原文只登记为受保护外部文件。
  3. 完成图片计划:填写交互合同、编辑合同、素材决策、首节视觉锚点和每个视觉的来源、位置、语义、状态与可追溯信息。先运行计划阶段验证。
  4. 制作视觉:优先使用相关用户素材和真实证据;生成图负责隐喻或氛围;代码图负责流程、关系、时间线、比较、数据或机制。首图生成并人工检查后再继续。
  5. 制作 HTML 与本地预览:使用一致的组件、移动端节奏和内联样式。本地路径只用于内部预览,不能宣称可直接复制到微信。
  6. 完成交付前闸门:依次验证最终图片计划、正文安全、文案和统一布局;内部本地预览只服务制作,不交给用户审阅,也不因截图工具限制阻止正式可复制版生成。
  7. 交付与确认:通过 publish.ts 正式准备模式上传或复用正文图,首次交给用户的就是完整可复制 HTML。用户审阅后按意见循环修改;明确确认时生成绑定当前正文与图片计划哈希的视觉回执,锁定正文哈希并按 references/publishing.md 创建草稿;成功后按 references/archive.md 写入项目提供的正式目标并安全清理。

验证命令从 scripts/ 目录运行:

npm run verify-image-plan -- --stage plan --article <source-article> <image-plan.json>
npm run verify-image-plan -- --stage final --article <source-article> --check-files <image-plan.json>
npm run verify-article -- --complete-package --content-mode <rewrite|preserve> --source-article <source-article> <article.html>
npm run verify-copy -- <article.html>
npm run verify-layout -- --article <article.html> --image-plan <image-plan.json>

rewrite 的文案警告必须修复;preserve 只报告。正式交付还要按 qa-checklist.md 完成图片来源、移动端截图、verify-copy-ready 和视觉回执检查。

完成回报

只报告与本次分支有关的信息:

  • 内容模式、交付方式、正文母版与预览路径;明确是本地预览还是正式可复制版。
  • rewrite 的主要改动,或 preserve 的原文校验与获准新增节点。
  • 首图/封面路径、图片计划路径、视觉来源数量及证据 URL 或失败原因。
  • 用户素材的使用位置与跳过理由;当前生图能力和真实工具。
  • 正式可复制版的用户审阅状态、尚未解决的视觉或来源风险。
  • 创建草稿时返回 media_id,并提醒“进入草稿箱不等于公开发布”。
  • 首次完成和每轮修改后提供完整可复制 HTML,并主动询问是否通过、可以加入草稿箱。
  • 收口时只报告最终 HTML、保留的本 Skill Markdown 终稿(如有)和未触碰的外部文件数量。

Skills relacionados