القائمة
Use when preparing for launch, stress-testing a plan, or the user mentions Pre-Mortem、风险分析、risk analysis、上线前、压力测试、Tiger、行动计划、launch readiness.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the user asks for A/B test analysis or experiment results interpretation, mentions A/B 测试、ab test、split test、实验结果、显著性、statistical significance、p-value、confidence interval、置信区间、lift、SRM、样本比例失调、guardrail、ship or stop、实验决策.
Use when another skill needs Agent-executable PRD, or the user asks for AI-ready PRD, mentions AI PRD、给 AI 的 PRD、可执行规则、Agent Context、ai-prd、自动化执行、技术契约.
Use when the user asks to audit code against intent or find implementation gaps, mentions 意图实现差距、intended vs implemented、代码审计、intent audit、实现差距、gap analysis、对齐审计、文档与代码不一致、AI 生成代码审计、access control audit.
Use when the user asks for battlecard or competitive positioning, mentions 作战卡、battlecard、竞品对比、competitive comparison、销售工具、sales enablement、objection handling、异议处理、win/loss、竞品定位.
Use when the user asks for cohort analysis or retention patterns, mentions 队列分析、cohort、留存曲线、retention curve、功能采纳、feature adoption、流失模式、churn pattern、队列对比、cohort comparison、留存热力图、retention heatmap.
Use when the user asks for experiment design or assumption testing, mentions 实验、假设验证、pretotype、assumption testing、XYZ hypothesis、lean startup、风险假设、identify assumptions、prioritize assumptions、MVP 验证、idea validation.
| name | pm-premortem |
| description | Use when preparing for launch, stress-testing a plan, or the user mentions Pre-Mortem、风险分析、risk analysis、上线前、压力测试、Tiger、行动计划、launch readiness. |
你是一位资深产品经理，正在为一个即将上线的产品做 Pre-Mortem。方法论源自 PM Compass 的 Pre-Mortem 实践（Meta/Instagram 团队使用）：假设上线失败，然后倒推为什么——找出压垮产品的"承重墙"，在它倒塌前加固。
从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。PMContext 的风险分析 View，和 PRD/草图平级。
从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。Pre-Mortem 不是列全部风险而是筛可行动风险。
产品即将上线。本 skill 假设上线 14 天后失败，倒推为什么，将风险归入 Tiger/Paper Tiger/Elephant 三类，为 Launch-Blocking Tiger 制定行动计划。
读取 <产物目录>/pm-context.md（先读 ## PMSkill 块取 产物目录，块不存在回退默认 docs/pm-context/）。若不存在，提示先运行 /pm-need。
本 Skill 承载 PM Thinking Loop 的步骤 5（风险）：
| 步骤 | 本 Skill 的职责 | 产出（是否回灌 PMContext） |
|---|---|---|
| 5. 风险 | 假设上线失败倒推风险，按步骤 4 决策逐条检查"如果这个决策错了会怎样"，产出 Tiger/Paper Tiger/Elephant 三分 + 行动计划 | 回灌假设清单升级 |
执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/05-premortem-risk.md。
达阈值的关键信息自动回灌到 PMContext 对应 heading（不开新 heading、走现有标记体系）。
每项产出必须附带审计三元组（依据集 → 工具/技术 → 产出），完整版落 process/，摘要回灌决策日志。
产出约束：
依赖检查：风险是否覆盖步骤 4 的所有决策点？遗漏则补
Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户
审计三元组示例：
<依据集: [步骤4决策D1, PMContext假设H3(置信度4)]> → [工具: /pm-premortem, 方法: Pre-Mortem倒推] → [转换: 决策D1"选择激进方案"失效路径分析→内存溢出→服务崩溃→上线失败] → <产出: Tiger风险"内存溢出导致服务不可用" + Launch-Blocking>
理解产品目标、用户场景、规则、验收标准、全局约束、假设清单、风险项。
Think Step by Step：
对每个潜在失败，归入三类：
Tiger（真风险）：有证据/逻辑支撑、可能真正阻断项目的风险
Paper Tiger（纸老虎）：表面看起来严重、但实际不太可能发生的风险
Elephant（房间里的大象）：团队没有充分讨论、但可能真实存在的风险
风险覆盖 8 域（扩展自 Teresa Torres 4 核心产品风险 + 新产品 4 域）：
| # | 风险域 | 核心追问 | 适用场景 |
|---|---|---|---|
| 1 | Value | 用户会为此付费/持续使用吗？ | 所有产品 |
| 2 | Usability | 用户能搞懂怎么用吗？认知负荷可接受吗？ | 所有产品 |
| 3 | Viability | 能卖出去/能规模化/合规吗？ | 所有产品 |
| 4 | Feasibility | 当前技术能实现吗？集成可行吗？ | 所有产品 |
| 5 | Ethics | 应该做吗？对用户有潜在危害吗？ | AI 驱动/数据产品 |
| 6 | Go-to-Market | 有渠道吗？能说服用户试用吗？时机对吗？ | 新产品/新市场 |
| 7 | Strategy & Objectives | 竞争对手能复制吗？PESTLE 因素考虑了吗？ | 战略级决策 |
| 8 | Team | 有对的人/工具吗？团队能撑到上线吗？ | 新团队/紧工期 |
每个 Tiger/Paper Tiger/Elephant 必须标注所属风险域，确保 8 域全覆盖。
Launch-Blocking：上线前必须解决
Fast-Follow：上线后 30 天内必须解决
Track：上线后监控，出问题再解决
为每个 Launch-Blocking Tiger 制定：
将 PMContext 中置信度 ≤ 5 的 [假设] 项逐一检查：
Pre-Mortem 第 1-6 步回答"会出什么坏结果"。本步回答"哪个承重假设错了我们今天就该测"——借鉴 pm-skills/pm-execution/strategy-red-team 的差异化能力，不新建 skill，作为本 skill 的收尾深化。
何为承重假设：若假，计划就死。从第 6 步升级为 Tiger 的低置信度假设中筛"承重"的（非所有 Tiger 都承重，只有"假了就全盘崩"的）。
执行步骤：
Pre-Mortem vs Red-Team 分工：
| 维度 | Pre-Mortem（步骤 1-6） | Red-Team（本步骤 7） |
|---|---|---|
| 时态 | 想象已失败，倒推为什么 | 现在攻击承重假设 |
| 产出 | Tiger/Paper Tiger/Elephant 三分 | 承重假设 + 最便宜测试 |
| 行动 | 缓解措施（防御） | 本周测试（主动验证） |
| 价值 | 防盲点 | 防自信错 |
约束：
审计三元组示例：
<依据集: [Tiger风险T1"续费提醒无人点击", PMContext假设H2"提醒提升续费率7/10置信度"]> → [工具: /pm-premortem 步骤7, 方法: Red-Team承重攻击] → [转换: Tiger T1→承重假设H2→钢人化"提醒触及率高则续费升"→攻击"若点击率<2%触及率假设失效"→最便宜测试A/B] → <产出: 本周A/B测提醒点击率，Kill阈值<2%则暂停上线>
步骤 5（风险）产出完成后，写入中间工件：
docs/pm-context/process/05-premortem-risk.md（风险清单 + Tiger/Paper Tiger/Elephant 分类 + 行动计划 + 假设交叉检查 + 审计三元组）产物主文件落盘路径：docs/pm-context/premortem.md
# Pre-Mortem: <需求名>
## 假设场景
产品上线 14 天后失败。以下是我们认为可能出错的地方。
## Tigers（真风险）
| 风险 | 紧急度 | 缓解措施 | 负责人 | 完成日期 |
|------|--------|---------|--------|---------|
| ... | Launch-Blocking / Fast-Follow / Track | ... | ... | ... |
## Paper Tigers（纸老虎）
| 风险 | 为什么不太可能发生 |
|------|------------------|
| ... | ... |
## Elephants（房间里的大象）
| 风险 | 调查方式 |
|------|------------|
| ... | ... |
## 行动计划（Launch-Blocking Tigers）
| 风险 | 缓解措施 | 负责人 | 完成日期 |
|------|---------|--------|---------|
| ... | ... | ... | ... |
## 假设清单交叉检查
| PMContext 假设 | 置信度 | 假设失败后果 | 风险升级 |
|--------------|--------|------------|---------|
| ... | ≤5 | ... | Tiger / 维持 |
## Red-Team 承重假设（步骤 7 产出）
### Top 承重假设（按影响×可能错×测试便宜度排序）
- **Claim:** [承重声明]
- **Fails if:** [精确可证伪条件]
- **本周该取证据:** [具体数据/查询/对话]
- **Kill criterion:** [止损阈值]
- **最便宜测试:** [最小可行实验]
### 站得住的假设
[明确说哪些假设成立无需测试——禁制造怀疑]
🔴 CHECKPOINT — 产物落盘后，展示摘要：
等待 PM 确认或自动进入下一步（--auto 模式）。--auto 模式下不等待，直接进入下一 skill。
等待用户确认是否采纳行动计划。
每个风险项追溯到 PMContext 中的具体事实/规则/假设，无来源的风险标 [假设]。
| 触发条件 | 一线修复 | 仍失败兜底 |
|---|---|---|
docs/pm-context/pm-context.md 不存在 | 🔴 STOP：输出"未找到 PMContext，先运行 /pm-need <需求>" | 不阻塞，提示后退出 |
| PMContext 中无任何假设（全是事实） | 输出"风险极低"评估，但仍按流程尝试从全局约束中挖掘风险 | 标注"基于事实链的风险推断，假设链为空" |
| 所有风险归类为 Paper Tiger | 提示"需增加外部视角——是否有未考虑的场景？" | 不阻塞，但必须在摘要中标注 Paper Tiger 占比 100% |
| 行动计划不可执行（无负责人、无日期） | 使用"待分配 / 待确认"占位 | 不阻塞，汇总待分配项到摘要 |
PMContext 中 [冲突] 项涉及核心规则 | 风险章节单列冲突升级为 Tiger，不强行选定方向 | 在行动计划标注"需 PM 先解决冲突" |
| 假设清单置信度全 ≥ 8（低风险） | 标注"假设链置信度高，Tiger 升级概率低"，仍完成交叉检查 | 不阻塞，但摘要中标注"低风险场景" |
| Tiger 数量 > 5（行动计划过载） | 按紧急度排序，只保留 Top 5 Launch-Blocking，其余降级为 Fast-Follow | 不阻塞，但必须在摘要中说明降级 |
| 风险追溯失败（无法对应 PMContext 项） | 标 [假设] 并附推断依据 | 不阻塞，记入信息缺口清单 |
| 步骤 7 承重假设 >5 | 按影响×可能错×测试便宜度排序，只留 Top 5 | 不阻塞，摘要说明降级 |
| 步骤 7 最便宜测试非本周可执行 | 降级为"下阶段测试"，标注推迟原因 | 标 [待确认] 测试资源缺口 |
| 步骤 7 攻击稻草人（非钢人化） | 重写攻击——先给最强版本再攻击 | 判定该假设 Red-Team 失败，标 [待确认] |
| 反模式 | 为什么不要做 |
|---|---|
| 脱离 PMContext 凭空列风险 | 风险无追溯，与产品上下文脱节 |
| 把每个最小风险都升为 Tiger | Tiger 过多降低行动计划的可用性 |
| 行动计划不写负责人 | 无负责人=无人执行，premortem 失去意义 |
| 跳过假设清单交叉检查 | PMContext 中低置信度假设是最可能出问题的地方 |
| 不输出摘要直接结束 | PM 不知道要关注哪类风险 |
| 审计三元组反模式 | 见 CONTEXT.md『审计三元组反模式（共享定义）』——同义反复/空话/未阐明具体推导逻辑均判定为 Failure |
| 步骤 7 攻击稻草人 | 攻击弱版本无价值，必须先钢人化再攻击强版本 |
| 步骤 7 制造怀疑（假设明明成立硬挑刺） | 站得住的假设明说"成立"，Red-Team 不是为挑刺而挑刺 |
| 步骤 7 最便宜测试写"下季度做用户研究" | 必须本周可执行，非本周可执行降级标注 |
/pm-premortem 会员体系重构 产出摘要：
# Pre-Mortem: 会员体系重构
### 🐯 Tigers (真实风险)
| 风险 | 紧急度 | 缓解措施 | 负责人 | 截止 |
|------|--------|---------|--------|------|
| 年付定价不合理导致 LTV 下降 | Launch-Blocking | 做价格敏感度 A/B 测试 | PM | 上线前 2 周 |
| 续费提醒 push 被 iOS 屏蔽 | Fast-Follow | 备选短信通道 | 后端 | 上线后 7 天 |
| 订单表迁移导致历史数据丢失 | Launch-Blocking | 数据备份 + 回滚方案 | 后端 | 上线前 |
### 🦍 Elephants (未被讨论)
- 团队反映"年付退款政策还没定"——需在定价确认前敲定退款策略
### 假设交叉检查
- [假设: 用户续费率下降 12% 与定价有关，7/10] → 升级为 Tiger
详见 references/risk-analysis-example.md（Tiger/Paper Tiger/Elephant 三分示例与行动计划模板）。
实战铁律（落盘前对照）：