ワンクリックで
design-content-script
剧本设计——叙事骨架、段落消息线、讲述节奏。当需要设计文章或演示的叙事结构,或提到"剧本""叙事""storyline""大纲"
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
剧本设计——叙事骨架、段落消息线、讲述节奏。当需要设计文章或演示的叙事结构,或提到"剧本""叙事""storyline""大纲"
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
| name | design-content-script |
| description | 剧本设计——叙事骨架、段落消息线、讲述节奏。当需要设计文章或演示的叙事结构,或提到"剧本""叙事""storyline""大纲" |
document / article / deck 需要先定叙事再进入产出design-content-direction;需要版式 → design-content-layoutbuild-content-writing(下游 build 技能)design-workflow-design先定讲什么、为什么这样讲、按什么顺序讲;再去写正文或做页面。
先读取 references/design-best-practices.md 和 references/design-inspiration-catalog.md,并把剧本相关证据写入 02-design.md 的 Design References / Pattern Synthesis / Adopt / Reject。
扫描重点:
DESIGN.md(如果存在,作为叙事约束参考)剧本方向必须由 Pattern Synthesis 收敛,不能只凭“感觉这样讲顺”。
写入 02-design.md:
| 失败场景 | 处理方式 |
|---|---|
| 没有核心主张 | 先降维成一句话主张 |
| 标题串不成线 | 重写消息线,不进入 build |
| 节奏失衡 | 删除或重排冗余段落 |
| 叙事模式无证据 | 补充 best-practice scan,写清 Adopt / Reject |
| 消息线与故事脊柱冲突 | 回到脊柱对齐,每段消息线必须服务脊柱主线,删除游离段落 |
| 说辞 | 现实 | 后果 |
|---|---|---|
| “先把内容都写出来再整理” | 没有剧本,后面只会变成清理垃圾。 | 无剧本写作 → 60-80% 内容需要删改重组,相当于重新写一遍;且有 40%+ 概率遗漏核心主张 |
| “PPT 就是文章拆页” | 没有页级消息线的 deck 不是演示。 | 文章拆页 → 每页信息密度不均匀,听众注意力在 3-5 页后断线,演示转化率下降 |
| “之后再调节奏” | 节奏是结构问题,不是润色问题。 | 节奏后补 → 结构性节奏缺陷无法通过润色修复,只能重排段落,等于重做剧本 |
核心主张: "远程团队的异步协作效率取决于信息可见性,而非响应速度"
故事脊柱:
- 起点: 远程团队的典型痛点(消息淹没、重复同步)
- 张力: "更快响应"是直觉解,但实际让问题恶化
- 转折: 证据——异步可见性工具(来源: Enterprise Product Patterns #4)降低 40% 同步会议
- 结论/行动: 3 个可执行的可见性改进
消息线:
- H1: "为什么更快回复反而更慢"(一个问题一个消息)
- H2: "可见性 > 响应速度"(一个证据一个消息)
- H3: "3 个改进方案"(一个行动列表一个消息)
Adopt: 问题-张力-解决路径(来源: Methods / Theory / Style Schools #2)
Reject: 纯数据罗列(与受众任务"相信并行动"不匹配)
核心主张: (未写)
故事脊柱: 开头 → 中间 → 结尾
消息线: 第一段讲一点,第二段讲一点,第三段讲一点
节奏: 正常速度
不做清单: (未写)
→ 没有证据,没有 Adopt / Reject,无法支撑后续写作
剧本设计产出应写入 02-design.md 的以下结构:
## Script Design — [内容名称]
### 核心主张
[一句话主张——看完后受众应该相信/决定什么]
### 故事脊柱
1. 起点: [情境描述]
2. 张力: [问题或冲突]
3. 转折: [关键证据或发现]
4. 结论/行动: [明确下一步]
### 段落消息线
| 段落/页面 | 核心消息 | 节奏标记 |
|-----------|---------|---------|
| [段落 1] | [一个消息] | 快/慢/停顿 |
| [段落 2] | [一个消息] | 快/慢/停顿 |
### Adopt / Reject(叙事模式)
| 模式 | 来源 | 决定 | 理由 |
|------|------|------|------|
| [模式 A] | [来源层] | Adopt | [具体理由] |
| [模式 B] | [来源层] | Reject | [冲突点] |
### 不做清单
- [不做项 1]: [冲突来源或证据]
- [不做项 2]: [冲突来源或证据]
02-design.mdSOC 職業分類に基づく
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比,或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作,或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复,或提到"保存""save""checkpoint""挂起"
架构决策记录(ADR)。当面临技术选型、架构决策、方案取舍需要记录,或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物,或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署,或提到"合并""merge""PR""land"