z-pyramid（金字塔原理）
一句话：自上而下表达——先给答案，再给支撑答案的分组理由，每组下面才是证据。
help 用法卡
调用消息或斜杠参数恰为 help / 帮助 / 怎么用（整条仅此一词）时，逐字输出本卡后停，不进入任何流程；请求含其他内容时按正常流程走。
【z-pyramid 用法卡】金字塔原理——拆问题、重构表达。
| 场景 | 你这样说 | 会发生什么 |
|---|---|---|
| 拆问题 | 「帮我把 X 拆成问题树 / issue tree」 | 一句话复述 → 直接拆解 |
| 重构表达 | 「这份汇报结论后置了，按金字塔重构」 | 先点评+确认 → 重构稿 |
单轮任务不占轮次。跨系列问法见 z-flow-kickoff help。
三条铁律（覆盖下文所有规则）
- 用户没让改文档，就不改。 用两句点评（结论现在落在哪、什么被压在什么下面）加一个问题（要不要重构）收尾，然后停下等确认。动手改别人没让改的稿子，等于替他重写。
- 时间顺序即内容的东西不套金字塔：时间线、runbook、教程、流水账、日志——按时间排就是对的顺序，把结论提到序列之上反而错了。
- 不虚构：不加源材料里没有的事实、数字、结论（包括对源数字自行推算的结果）。
被 z-系列其他 skill（z-clarify、z-chain、z-assess、z-init）作为方法论层调用时，调用上下文即视为授权，跳过第 1 条的"先问"，直接提供方法；第 2、3 条仍然生效。
Gate：动手前先判断适不适用
问一个问题：这份材料或这个任务，是否需要读者接受一个判断、或做出一个决定？
- 是（提案、汇报、分析结论、评审意见、带诉求的总结）→ 适用，继续。
- 否（时间线、操作手册、教程、笔记）→ 不适用，一句话说明并停："这是事件时间线，时间顺序就是对的顺序。"
Gate 优先于场景分派：命中"否"时按本节一句话说明并停，不进入场景 A/B/C，也不适用铁律 1 的"点评+问题"收尾。
开场协议（轻量级，z-系列工作模式）
开工前用一句话复述并入首条回复："我理解你要 X（含一个具体事实），按 Y 做，理解偏了随时打断。"不单独占一轮。Gate 判定不适用时先按 Gate 一句话说明并停，不做复述。被 z-flow-kickoff 编排进入时沿用其契约与横幅。
核心结构
答案（一句话）
┌──────────┼──────────┐
理由组 1 理由组 2 理由组 3
│ │ │
证据 证据 证据
结论先行
自上而下表达，先给答案再给论据。读者在几句话内决定要不要继续读；带着读者走完过程、最后才到结论，是讲故事，不是做汇报。
SCQA 开场
答案不冷启动。SCQA 把读者放到他们已经接受的立场上，让结论成为他们心中问题的答案：
- Situation 情境——读者已经接受的事实
- Complication 冲突——打破情境的变化：出问题了、冲突了、不管用了
- Question 疑问——冲突引出的问题，通常隐含不写
- Answer 回答——你的结论，就是塔尖
S 和 C 只给"让读者产生疑问"所需的量。读者已知道情境时一个从句就够；S+C 的长度永不超过答案本身。
纵向三规则（Minto）
- 纵向概括：每一层是对它下面那组的概括，每组回答它父节点引出的问题。答不上父节点的问题，说明放错位置。
- 同类分组：同组内必须是同一类想法。
- 逻辑顺序：演绎、时间、结构、程度四选一。刻意选了一个顺序不算数，必须是这四种之一。
分组只有两种类型：
- 归纳（inductive）：同类想法并列、共同支撑上面的观点。这是常见情形，由 MECE 检验。
- 演绎（deductive）：前提共同推出结论（这是真的，那也是真的，所以）。MECE 不检验演绎链；演绎链要短，因为它没法跳读。
MECE 拆解（issue tree）
把大问题拆成子问题时，用树形拆分：相互独立（子项不重叠）、完全穷尽（对要回答的那个问题无遗漏——不是对全世界无遗漏）。
- 每层两个检验：子项之间问"有重叠吗"；拆完一层问"漏了什么才能回答父问题"。
- 常用切分法：流程步骤、组成结构、二分法（内部/外部、必选/可选）、程度排序。
- 输出 issue tree 时标注每个分支用的切分法，避免读者误以为分类随意。
两种建塔方式
自上而下（结论明确或可推断时）：
结论 → 列出支撑它需要的理由（问"读者不信这个结论，是因为缺什么"）→ 归组 → MECE 检验 → 每组下面填证据。
自下而上（素材在手、结论未明时）：
罗列素材 → 找共性归组 → 每组提炼一句话结论（So What）→ 向上概括至总结论 → 回头检验总结论是否回答了真正的问题。
两种方式可混用：先自下而上找分组，再自上而下补缺口。
So What 提炼
从素材归纳出有观点的结论，而不是罗列事实：
- 每组下面连续问"所以呢？"，直到答案是一个判断（"X 是问题，因为 Y"），不是一个清单。
- 检验：把证据全部拿掉，这句话还能当结论吗？能，它就是塔上的一层；不能，它只是素材标题。
- 事实罗列的典型症状：句子里只有名词没有判断；说了"三个方面"，却讲不清三方面共同指向什么。
输出与交互
场景 A：拆解问题（用户给一个模糊大问题）
输出 issue tree：父问题 → 子问题树（标注切分法）→ 每个子问题一句"回答了它，对父问题意味着什么"。被 z-clarify 调用时用此场景，把大需求拆成可逐项澄清的子问题。
场景 B：重构文稿（用户让改，或 gate 通过且已被授权）
先把原稿每段归类为 答案/理由/证据/场外，再按"SCQA 开场 + 塔形结构"落位，改完附一段"改了什么、为什么"的说明。
场景 C：点评文稿（用户没让改）
按铁律第 1 条执行：两句点评 + 一个问题，停。
所有场景通用：不虚构（铁律 3）；用户材料里的"事实（现状/约束）"与"判断（观点/推断）"分开标注，不混淆；语言与用户一致。
与 z-系列的关系
本 skill 是全系列的方法论底座：
z-flow-kickoff（编排：开场协议→契约→横幅→交接→续跑）
└─ z-pyramid(本 skill：拆解) → z-clarify(澄清→登记册) ⇄ z-chain(生态/干系人事实)
↓
z-assess(四维+风险+假设 → Go/No-Go)
↓ Go
z-init(工程文档基线化) → 下游 spec/开发（松耦合，AGENTS.md 契约）
分工要清楚：本 skill 管"怎么想、怎么表达"（拆解、结构、检验）；"评估什么维度、下什么结论"是 z-assess 的事，"生态事实"是 z-chain 的事，"澄清流程"是 z-clarify 的事。系列内被引用的典型位置：z-clarify 用场景 A 拆大需求、用纵向三规则验报告；z-assess 用结论先行组织评估报告。
边界
- 本 skill 不做需求澄清（那是 z-clarify 的事）、不做可行性/立项评估（评估内容框架与 Go/No-Go 结论是 z-assess 的事）、不做技术方案设计、不做工作量评估。
- 用户点名"需求澄清/需求评审"时应由 z-clarify 主导流程，本 skill 只在拆解或报告检验环节被引用；点名"可行性/立项评估"时由 z-assess 主导，本 skill 只供表达结构。
