content-remix

Files (5)

• SKILL.md
• openai.yaml · agents/
• evals.json · evals/
• trigger-cases.json · evals/
• remix-contract.md · references/

SKILL.md (first lines)

# 内容二创

把“这个爆款为什么成立”迁移成“泊舟凭什么能讲这件事”。二创不是同义改写，也不是把原稿换几个名词，而是保留功能机制、替换事实来源、重新确定内容承诺并按平台原生组织。

## 必读与调用

每次运行先读：

- `references/remix-contract.md`：输入合同、原创边界、平台适配器、输出格式和保存约定。
- `<NOTES_VAULT>/我的设定/个人创作方向.md`：判断是否符合长期定位。
- `<NOTES_VAULT>/我的设定/受众画像.md`：确定目标读者和真实需求。

生成成稿时，再读取并遵循：

- 已安装的 `bozhou-writing-style` Skill 及其要求的动态偏好。
- `content-angle`：用户没有给出明确新角度时，先确定区别于原内容的角度。
- `hook-writing`：生成目标平台标题、封面文案或前三秒钩子时使用。

## 边界与路由

- 只消费已经选定、已经拆解的样本。只有原链接、原文或逐字稿时，先交给 `viral-video-benchmark` 完成判级、证据化八部分拆解和入库；本 Skill 不跳过上游门禁。
- 正式爆款笔记的 `analysis_status` 必须是 `current`；`limited` 只允许迁移未受缺失证据影响的机制，并明确降低置信度；`stale` 必须先重新拆解。
- 八部分拆解至少要有 `可复用点`、`不能照搬` 和 `本账号适配`。缺少任一部分时不生成可发布草稿。
- 找新选题用 `topic-extract`，判断值不值得做用 `topic-priority`，普通改稿用对应写作或润色 Skill，发布后复盘用 `creator-data-review`。
- 本 Skill 只生成二创方案或内部草稿，不发布、不登记 publication、不上传图片、不写飞书、不采集后台数据。

## 工作流

### 1. 锁定样本与目标

确认唯一的爆款拆解笔记、`platform + post_id`、`evidence_version`、`analysis_version`、关联母题、目标平台和目标形式。标题不能充当样本身份。

多个样本或多个母题都可能匹配时，列出候选与证据，让用户选择；确认前零写入。一次二创只设一个主对标，其他样本只能作为补充证据。

目标平台未明确时：

- 上下文能唯一推出平台时直接使用；
- 无法唯一推出时先交付二创迁移卡，不同时生成多个平台成稿；
- 小红书默认以图文为主路径，小红书视频只在用户明确指定时生成。

### 2. 提炼一个主机制

从八部分拆解中选择一个最值得迁移、且本账号具备事实条件的主机制。把它写成与原句无关的功能链，例如：

`圈定人群 → 结果前置制造信息差 → 过程证据建立信任 → 方法清单形成收藏理由 → 行动指令承接需求`

同时记录：

- `benchmark_id = {platform}:{post_id}`；
- `mechanism_id = {benchmark_id}#{简短机制名}`；
- `mechanism_version = {analysis_version}`；
- 该机制需要哪些一手事实才能成立；
- 发布后什么表现会支持或推翻迁移判断。

不要因为样本数据好，就假定其中每一个表达都有效。观察、传播假设和只能确认相关的指标必须继续分开。

### 3. 建立原创边界

逐项完成四栏迁移：

1. **保留功能**：用户需求、钩子功能、信任功能、信息推进和行动功能。
2. **删除来源表达**：原句、特色比喻、镜头组合、页面设计、叙事顺序和高度可识别的表达。
3. **禁止借用事实**：原作者身份、经历、客户、收入、结果、评价、数据和素材。
4. **注入本账号内容**：泊舟自己的经历、项目、截图、流程、判断、失败和产品连接。

出现下面任一情况时，判定原创距离不够，重新构思：

- 标题或钩子只是替换名词；
- 段落、卡片或镜头与原内容逐段一一对应；
- 沿用同一案例、数字、结果承诺或独特比喻；
- 结论与原内容相同，只有语气变化；
- 去掉来源后，剩下的仍能明显反推出原稿表达。

### 4. 映射一手素材

沿关联选题的 `materials`、用户指定文件和相关笔记寻找素材。每个“我做过 / 我发现 / 我的客户 / 我的数据 / 我的结果”都必须能回到用户提供的信息或本地来源。

至少具备以下两项，才生成无占位符的完整草稿：

- 一个只有泊舟能提供的一手事实、过程、演示或失败；
- 一个明确属于泊舟的判断，并能说明它与原内容的区别。

素材不足时不得编造。只输出“可迁移机制 + 素材缺口 + 建议补证方式”，或在用户明确接受时生成带 `[待补：真实事实]` 的内部骨架，并标记“不可发布”。

### 5. 重新确定内容承诺

先用一句话写清：

- 原内容给谁什么承诺；
- 泊舟的新内容给谁什么不同承诺；
- 新承诺由哪条一手事实支撑。

用户没有指定角度时调用 `content-angle`。新角度不能只靠反义、夸张或改标题制造差异；它必须改变观察位置、核心判断、事实来源或读者所得中的至少一项。

### 6. 按平台独立生产

严格使用 `references/remix-contract.md` 对应的平台适配器：

- **小红书图文（主路径）**：重新设计搜索/点击承诺、标题、封面、完整图文正文、收藏理由、评论问题和可选卡片页规划。
- **抖音视频**：重新设计前三秒口播与画面、信息推进、证据出现位置、完整口播、屏幕字、画面提示和结尾动作。
- **小红书视频（辅助路径）**：保留小红书的搜索、封面、收藏、信任与产品承接逻辑，再增加前五秒和时间推进。

同一机制做多个平台时，从迁移卡分别重写；禁止先写一篇长文再机械压缩成视频，也禁止把抖音逐字稿直接切成小红书卡片。

### 7. 过发布前质量门

逐项检查：

- 一手事实和数字都有来源，没有把原作者事实改成第一人称；
- 新承诺、开头、案例、结构和结论至少有三处实质差异；
- 标题和钩子兑现正文，不借爆款结果做虚假承诺；
- 平台结构成立，不混用小红书与抖音模板；
- `falsifiable_statement` 只描述本次机制迁移假设，不承诺必爆；
- 草稿符合泊舟最新写作偏好，且人工最终确认事实、隐私、品牌语气和公开边界。

未通过时先修复；缺真实材料时保持“不可发布”，不要用流畅文案掩盖证据缺口。

### 8. 保存与交接

From bozhouDev/video-skills-toolkit, MIT.

More from bozhouDev/video-skills-toolkit