six-pager

/six-pager -- Amazon 风格叙事备忘录与 PRFAQ

生成 Amazon 自 2004 年 6 月 9 日以来一直采用的决策文档——那一天，Bezos 禁用了 PowerPoint，并要求每场会议都以一份书面叙事开场。

此技能负责生成文档，但不能取代严谨的写作过程。Amazon 最初的做法需要一周时间（起草 → 评审 → 搁置 → 修改 → 定稿）。此技能压缩了流程，但保留了对文字质量的要求。

为什么有效

三种独立传统汇聚于同一原则：写作是思考的工具，而不是思考的记录。

• Bezos（Amazon，2004）： “写一份结构清晰的六页叙事备忘录，就不可能没有清晰的思路。”
• Strunk（1918，由 E.B. White 于 1959 年重述）： “有力的写作简洁明了。同一句话不应包含多余的词，一个段落不应包含多余的句子，正如一幅画不应有多余的线条，一台机器不应有多余的零件一样。”（规则 17）
• Anthropic（Claude Code 最佳实践）： “逐行自问：如果删掉这一行，Claude 会犯错吗？如果不会，就删掉它。”

同一条规则，适用于三个层面：行、句子、指令。此技能会贯彻这三点。

何时使用此技能，何时使用同类技能

技能	用途	模式
/six-pager memo	决策、战略、状态，以及有重大影响的“我们该不该这样做？”	叙事备忘录，6 个章节，严格限制为 6 页
/six-pager prfaq	以客户成果为核心问题的产品／功能／发布想法	新闻稿 + 2 个常见问题解答，从发布目标倒推
长篇写作／语气技能	散文、叙事、感官写作	长篇起草，而非决策文档结构
/council-review	存在多个合理答案的开放问题	多 Agent 审议，而非文档生成
/adversarial-review	对已完成的产物进行压力测试（包括六页备忘录！）	单一批评者攻击模式

自然搭配： 使用 /six-pager 生成文档，再用 /adversarial-review 进行压力测试，最后用 /council-review 审议建议。这就是完整的 Amazon 风格决策流程。

参数

• 参数 1（必需）： 主题、草稿或文件路径。以下三者之一：
  • 简短的主题陈述："Should we migrate the API to cursor-based pagination?"
  • 现有草稿的路径：docs/pagination-decision-draft.md
  • 粘贴的一段背景信息
• 模式标志（可选）： memo（决策时的默认模式）或 prfaq（发布时使用）。如果省略，技能会自动分类并要求确认。
• --silent-read： 在输出中加入 20-30 分钟的“静默阅读”模拟，生成带注释的版本，其中包含资深评审者可能会写下的边注问题。
• --strunk-only： 跳过结构生成；将输入视为现有草稿，仅进行 Strunk + Anthropic 文风审查。适用于润色正在编写的文档。

流程

阶段 1：界定范围

1. 从 $ARGUMENTS 解析标志。
2. 对输入进行分类：
   • 主题 — 简短陈述，没有草稿。从头生成。
   • 文件路径 — 现有草稿。读取文件，并将其作为起点。
   • 粘贴的文本 — 作为背景信息处理。
3. 如果缺少模式标志：
   • 自动分类：输入包含“launch”／“ship”／“announce”／“new product”／“release” → 建议使用 prfaq。否则 → 建议使用 memo。
   • 继续前先向用户确认。
4. 用一句话向用户确认范围：“正在为[主题]生成 [memo|prfaq]。[可选：已启用 --silent-read。]”

阶段 2：起草

模式：memo（6 页纸）

生成六个标准章节。每个章节都有特定用途和严格的行文规范：

1. 简介（约 0.5 页） — 这份文档是什么？面向谁？要提出什么请求？用一段话说明决策。
2. 目标（约 0.5 页） — 具体、可衡量的成果。每个目标都必须可验证。尽可能提供数字。
3. 准则（约 0.5 页） — 本提案优先遵循的原则。不得使用限定语（遵循 Strunk 的“避免使用削弱语气的词”提醒）。准则是毫不含糊的承诺。格式：1. [准则名称]：[单句陈述句。]
4. 业务现状（约 1.5 页） — 当前数据。坦诚具体。提供具体数字、系统名称和有日期的事实。严格遵循 Strunk 规则 16（明确、具体、实在）。
5. 经验教训（约 1 页） — 过去的尝试带来了哪些教训？这次有什么不同？每条教训都要引用具体的过往事件或实验，而非抽象原则。
6. 战略优先事项（约 2 页） — 推荐的行动及理由。提供具体里程碑、负责人和时间安排。
7. 附录（不限） — 图表、支持数据、经过考虑并否决的替代方案（及其原因）。

（V2）事前验尸（必须放在战略优先事项或附录中）。 假设现在是 12 个月后，这项决策已经失败。从失败结果倒推，写出最可能的 3 个原因。这是一种面向未来的风险识别，而“经验教训”（回顾过去）在结构上无法做到这一点——这是 Kahneman 认为价值最高的决策技巧；它还应与验证相结合：每个事前验尸原因都应对应一项要监控的指标。不要写泛泛的“风险”，而要描述具体的失败场景。

硬性限制： 第 1 至第 6 节合计不得超过 6 页，正文使用 11pt 字号。该技能会计算页数，超出时会发出警告。

模式：prfaq（新闻稿 + 常见问题）

生成三份子文档。从结果倒推——先写新闻稿，假设产品已经发布。

1. 新闻稿（约 1 页） — 面向客户的语言。以利益为先。日期设为（假设的）发布日。格式遵循 Amazon 的内部公关规范：
   • 标题（一行，突出客户成果）
   • 副标题（一行，说明适用对象和主要优势）
   • 导语段落（城市、日期、“今天 X 宣布 Y……”）
   • 问题段落（产品问世前面临的困难）
   • 解决方案段落（产品如何解决问题）
   • 客户引言（虚构但可信）
   • 内部引言（团队成员说明这件事的重要性）
   • 行动号召／可用性
2. 外部常见问题（约 1 页） — 记者或客户可能会问的问题：
   • 这是什么？
   • 它与[显而易见的替代方案]有何不同？
   • 费用是多少？
   • 什么时候可以使用？
   • 它不做什么？
3. 内部常见问题（约 1–2 页） — Amazon 风格的管理层可能会问的问题：
   • 为什么是现在？
   • 成功是什么样的？（具体指标和具体日期）
   • 有哪些依赖项？
   • 失败模式是什么？
   • 我们选择不构建什么？
   • 什么情况会导致我们终止这个项目？

PRFAQ 检验： 如果你写不出一份可信的新闻稿，说明产品尚未真正成形——至少还没有达到关键形态。

阶段 3：约束

阶段 2 生成草稿后，进行测量：

# rough page count: assume 450 words/page at 11pt
WORDS=$(wc -w < draft.md)
PAGES=$(echo "scale=1; $WORDS / 450" | bc)

如果超出预算：

• 对于 memo：找出最长的章节，提出删减 30pct，同时保留承重内容
• 对于 prfaq：找出超长的常见问题子章节；提出合并或精简问题

绝不悄悄截断。始终向用户说明拟删减的内容及原因。

阶段 4：审计（Strunk + Anthropic）

对草稿进行 prose 质量审计。每项发现都注明规则：

检查项	规则	操作
被动语态	Strunk R14	标出每处被动表达；建议改为主动表达
含糊语言	Strunk R16	标出每处没有数字支撑的“改进”“各种”“一些”“许多”；要求具体说明
多余词语	Strunk R17 + Anthropic 可删性原则	标出冗长表达（“为了”→“要”；“由于……这一事实”→“因为”）
修饰语	E.B. White 的“水蛭”提醒	标出每处“相当”“非常”“少许”“颇为”“相当”“有些”——建议删除
平行结构	Strunk R19	标出列表／准则／目标中不一致的语法形式
句长单调	Strunk R18	标出连续 4 句以上、句长彼此相差不超过 5 个词的段落；建议调整句长
主题句	Strunk R13	标出任何将论点埋在铺垫之下的段落。每段开头都要点明主旨——一段只推进论证中的一个步骤。这是叙事备忘录的核心纪律
夸大其词	E.B. White，不要夸大其词	标出随意使用的最高级和毫无保留的炒作性表述（“巨大”“革命性”“庞大”“颠覆性”）。只要出现一处，就会让读者心生戒备，并影响对其余内容的信任——要求提供数字，或删掉
带有保留措辞的准则	Bezos 准则	准则代表承诺。“我们努力优化 X”→“我们优化 X”，或删掉
可删性测试	Anthropic	对每个段落都问：删掉它会让读者做出错误决策吗？如果不会，就删掉。

生成结构化审计报告：

## Prose Audit (Strunk + Anthropic)

**Findings:** N critical, M important, K nit

### Critical (block the document)
- Line 23: passive voice in Strategic Priorities ("It was decided that...") → "We decided to..."
- Line 47: vague Goal ("improve performance") → demand a number
- Tenet 3 hedges ("We strive to be customer-obsessed") → cut "strive to" or cut the tenet

### Important (fix in next pass)
- 4 sentences in a row of 18-22 words in State of Business → vary
- Parallel-form break in Goals: 3 noun-phrase goals + 1 verb-phrase goal
- State of Business ¶2 buries its claim in the final sentence → lead the paragraph with it
- Overstatement in Introduction ("a massive, game-changing opportunity") → name the number or cut

### Nit
- "in order to" appears 3 times → "to"
- "various improvements" → name them or cut

阶段 5：呈现

向用户展示：

1. 最终文档（如果使用了 --silent-read，则展示带审计批注的草稿）
2. 页数与预算对比
3. 审计摘要（严重／重要／细微问题的数量）
4. 并排展示：原始草稿与针对审计发现提出的改写

询问：“应用审计修正吗？（是 / 部分 / 否）”

如果用户回答“是”：直接应用修正（如果输入是文件，则进行精确修改；否则展示新的完整文档）。 如果用户回答“部分”：逐项处理每个修正。 如果用户回答“否”：交付未经审计的草稿，并注明已跳过审计。

阶段 6：保存

默认保存路径：与输入文件同目录（如果输入是文件），否则保存到 <cwd>/six-pager-<topic-slug>-<YYYY-MM-DD>.md。

如果使用了 --silent-read，还要生成 <same-name>-annotated.md，在其中用 HTML 注释或提示块加入边注问题。

静默阅读模拟（--silent-read）

这是 Amazon 最初的会议流程：会议开始时（不是会前）分发文档，静默阅读 20-30 分钟并做笔记，然后围绕具体的页码／行号批注展开讨论。

启用 --silent-read 后，生成文档后，该技能还会进行第二轮审阅：

针对每个部分，生成 2-4 个资深审阅者可能写在边注中的问题。示例：

• “23pct 这个数字有多可靠？是测量值还是估算值？”
• “准则 2 和准则 4 相互矛盾——发生冲突时以哪个为准？”
• “经验教训 #3 说上次尝试因 X 失败。有什么证据？”
• “战略优先事项 #1 没有指定负责人。”

这能在正式会议前发现“作者觉得内容清楚，读者却不明白”的问题。

质量标准

六页文档只有在以下所有检查均通过时才算合格。否则继续迭代。

• 页数 ≤ 6（备忘录），或符合相应子文档的长度要求（prfaq）
• 每个目标都有数字或具体、可验证的结果
• 每条准则都是不带限定语的陈述式承诺
• 每页的业务现状至少引用 5 个具体数字／具名系统／注明日期的事实
• 每项战略优先事项至少指定一位负责人
• Strunk 审计：严重问题为零（被动语态、含糊的目标、带保留措辞的准则）；重要问题可以接受，但须说明理由
• “什么情况会让我们终止这项工作？”这个问题（PRFAQ 内部常见问题）必须有真实、具体的答案，不能只说“如果性能下降”

注意事项

• 不得超过 6 页。 页数限制就是要求。如果内容放不下，说明还没想清楚。
• 不要用背景故事充斥「业务现状」。 只写当前数据。历史内容属于「经验总结」。
• 不要对原则含糊其辞。 带有「尽量」或「力争」的原则不算原则。
• 不要编造数字。 如果目标需要指标，而用户没有提供，就向用户询问。不接受通用占位符（「X%」）。
• 不要混淆目标与原则。 目标是结果（可衡量）。原则是准则（承诺）。两者缺一不可；混为一谈会模糊思路。
• 不要跳过审查。 阶段 4 并非可选步骤。整个流程的核心就是约束文风并梳理结构。
• 不要自动保存。 阶段 6 会与用户确认保存位置。
• 不要将此技能用于散文文章。 应改用专门的长文写作／文风技能——此技能用于决策文档，而非散文。

更新日志

V2（2026-05-27）

通过 skillforge optimize 优化（成果研究：决策备忘录效果 + 决策科学）。六页备忘录原本已很成熟；此次仅做聚焦且不重复的补充：

• 备忘录模式下必须进行事前验尸——面向未来的「假设它失败了，原因是什么？」失败分析，每个原因都要关联一个验证信号。这弥补了「经验总结」（回顾过去）留下的空白。这是 Kahneman 认为最有价值的决策技巧；与为 council-review V2 提供依据的决策科学脉络相同。
• 成果目标：让备忘录在决策前而非决策后揭示致命风险。资料来源：Kahneman（事前验尸）；Amazon 叙事写作实践（默读、从客户需求倒推）；理论基础同属决策科学脉络（事前验尸、中介评估）。

参考资料

Bezos / Amazon 经典资料：

• Bryar, Colin & Carr, Bill — Working Backwards: Insights, Stories, and Secrets from Inside Amazon（St. Martin's Press，2021）——权威著作
• Slab — Jeff Bezos 如何将叙事写作打造成 Amazon 的竞争优势
• Maestra — 如何撰写 Amazon 六页备忘录（附模板）
• Anecdote — Amazon 六页叙事结构可能是什么样的？

Strunk & White 经典资料：

• Strunk, William Jr. & White, E.B. — The Elements of Style，第 4 版（Pearson Allyn & Bacon，2000）
• Strunk 1918 年原版公有领域文本：Bartleby — The Elements of Style

Anthropic 文风规范：

• Anthropic — Claude Code 最佳实践——可删性测试

认知风格背景资料：

• Tufte, Edward — The Cognitive Style of PowerPoint（2003）——反对项目符号的论据

测试

这是一项仅包含提示词的技能。随附的 tests/eval.sh 会验证结构约定。要端到端验证其行为：

1. 选取一个真实决策："/six-pager Should we migrate the API to cursor-based pagination?"（备忘录模式）
2. 验证是否生成了全部 6 个章节、页数 ≤ 6，并且执行了审查且有审查结果
3. 选取一个发布创意："/six-pager prfaq Acme AI assistant public launch"（PRFAQ 模式）
4. 验证是否生成了新闻稿 + 2 个常见问题解答，以及「什么情况会让我们叫停？」是否有切实的答案
5. 对现有草稿运行 --strunk-only：验证只触发审查，不生成新结构
6. 运行 --silent-read：验证每个章节是否都生成了批注问题