## 1. 先提取事实，保留原文的限定语

只读 source-article.md。输出事实清单：编号、原文依据、类型（样例事实/建议/未验证）、可用于文案的表达、必须保留的限定语。不得补查外部数据，不改写成真实邮箱实测，不生成节省时间或准确率数字。先交付 facts.md。

验收：数字 8、6、2 的含义没有变化；F06 里的未测量信息仍然存在。

## 2. 把渠道、读者和语气写成编辑要求

根据 editorial-brief.json 和 facts.md，写出两种内容大纲：X 5 条串文、LinkedIn 1 篇。每段标事实编号。语气具体克制；第一段交代是合成练习。先展示大纲，不连接账号，不排期。

验收：原文里的“建议”没有升级为“已经实现”，每个段落都有来源编号。

## 3. 生成草稿，再逐条做事实与语气审阅

按已确认大纲生成 X 串文和 LinkedIn 草稿。正文之外附“草稿 id → 事实编号”表。再独立检查：新增数字、遗漏的限定语、把计划写成完成、重复论点、未经确认的承诺。发现问题直接修订，并列出改动。只写 drafts.md。

验收：每条具体判断均能回到原文；两个版本都保留合成练习和未验证范围。

## 4. 先核对账号与工具，再准备草稿请求

先只读检查我的 Typefully 连接与目标 social set：<填写>，列出对应的 X、LinkedIn 账号以及可用工具。检查 draft-payload.json 只用于创建普通草稿：没有 publish_at、plan_at 或即时发布参数，share 为 false。仅展示核对结果和拟执行请求，不调用写入工具。密钥不得回显。

验收：没有把社交账号显示名当作唯一身份；不包含排期、即时发布或公开分享参数。

## 5. 只保存明确批准的草稿，并回读验证

只在我确认具体账号与请求后，创建这一个普通草稿；不排期、不发布、不生成公开分享链接。记录返回的 draft_id 并回读核对正文、平台和草稿状态。工具不可用则保留文件，写明未写入。结果不明时先查重，不重复创建，不覆盖已有草稿。

验收：平台和账号正确，内容没有丢段；状态仍为草稿，没有发布记录。

## 6. 保存改写方法，发布作为独立决策

把验收后的改写方法写成 content-repurpose Skill：输入原文与编辑要求，提取事实，生成渠道大纲，改写，自查，交付草稿与来源表。写入 Typefully、公开分享、排期和发布都是独立阶段，默认停在本地文件。不创建定时发布任务，不跨 Bot 委派。

验收：下一篇换输入后仍先核对事实；没有自动继承旧账号、时间或发布授权。