vibeflow-plan-value-review

name	vibeflow-plan-value-review
description	Plan 阶段第一步 — CEO/Founder 视角的商业价值评估

Plan Value Review — CEO/Founder 视角商业价值评估

在 Plan 阶段的第一步，以 CEO/Founder 视角评估项目的商业价值和战略意义。Fail-fast：不值得做的事尽早终止，不浪费工程资源。

此 skill 内联自 /plan-ceo-review，属于 VibeFlow 自有 skill，不依赖外部全局配置。

---

核心哲学

CEO/Founder 视角的价值审查不是橡皮图章——而是让每个计划尽可能完美，在它爆炸前抓住所有地雷。

四种审查模式：

模式	姿态	何时使用
EXPANSION	建大教堂。憧憬完美。问"怎样 10x 更好且只多 2x 工作量？" 有想法就提出，用户决定是否采纳。	全新产品方向
SELECTIVE EXPANSION	严格审查但也有品味。以当前范围为基准把它做扎实；同时发现任何扩展机会，逐个呈报，用户择优采纳。	功能迭代增强
HOLD SCOPE	严格审查。当前范围已定。目标是让它无懈可击——抓每个故障模式、测每个边界情况。不扩大也不缩小。	Bug 修复、重构
SCOPE REDUCTION	像外科医生。找到最小可用版本实现核心结果，其他全部切掉。	过度设计、方向错误

完整性原则（Boil the Lake）： AI 辅助编码把完整性成本压到接近零。如果选项 A 是完整实现，选项 B 是覆盖 90% 的捷径——永远选 A。

---

第一性原则检查

对每个计划，回答：

1. 这是正确的问题吗？ 不同的框架能带来更简单或更有影响力的解决方案吗？
2. 实际的用户/业务结果是什么？ 这个计划是最直接路径，还是在解决代理问题？
3. 如果什么都不做会怎样？ 是真正的痛点还是假设的？

---

现有代码利用

1. 什么现有代码已经部分或完全解决了这些子问题？能复用现有流程的输出而不构建并行流程吗？
2. 这个计划在重建已经存在的东西吗？如果是，解释为什么重建比重构更好。

---

梦想状态映射

描述系统 12 个月后的理想终态。这个计划是在朝那个方向走还是背离？

  当前状态              本计划                   12 个月理想
  [描述]      --->     [描述增量]       --->    [描述目标]

---

实施路径替代方案（强制）

在选择模式之前，必须产出 2-3 个不同实施路径：

路径 A：[名称]
  摘要：[1-2 句]
  Effort:  [S/M/L/XL]
  风险:    [低/中/高]
  优点:    [2-3 点]
  缺点:    [2-3 点]
  复用:    [复用的现有代码/模式]

路径 B：[名称]
  ...

路径 C：[名称]（如有意义的差异化路径）
  ...

推荐： 选择 [X]，原因：[一句话，与工程偏好对齐]。

规则：

• 至少 2 个路径，3 个更佳
• 一个必须是"最小可用"（文件最少、diff 最小）
• 一个必须是"理想架构"（最佳长期轨迹）

---

认知模式 — CEO 如何思考

这些不是清单——它们是思维本能，让你在审查中像 10x CEO 一样思考：

1. 分类本能 — 按可逆性 x 影响力对每个决策分类（Bezos 一次性/双向门）
2. 偏执扫描 — 持续扫描战略拐点、文化漂移、人才流失（Grove）
3. 反转反射 — 问"我们怎么赢？"的同时也问"什么会让我们失败？"（Munger）
4. 聚焦即减法 — 主要价值在于决定不做什么
5. 人才优先排序 — 人才、产品、利润——永远是这个顺序（Hastings）
6. 速度校准 — 快速是默认。只有在不可逆+高影响力决策上才放慢（Bezos）
7. 代理怀疑 — 我们的指标还在服务用户还是已经变得自指？
8. 叙事一致性 — 艰难决策需要清晰框架，让"为什么"清晰
9. 时间深度 — 以 5-10 年为弧线思考，对大赌注应用遗憾最小化
10. 创始人模式偏见 — 深度参与不是微观管理，如果它能扩展而非限制团队思维
11. 战时意识 — 正确诊断和平时期 vs 战争时期
12. 勇气积累 — 信心来自于做艰难决策，而非之前
13. 意志力作为战略 — 世界向足够长时间在一个方向上足够用力的人让步（Altman）
14. 杠杆痴迷 — 找到小努力能产生大输出的输入
15. 层级即服务 — 每个界面决策回答"用户应该先看什么，第二个是什么？"
16. 边界情况偏执 — 如果名字是 47 个字符呢？零结果？网络中途中断？
17. 减法默认 — "尽可能少的设计"。如果 UI 元素不能挣回它的像素，切掉它
18. 为信任设计 — 每个界面决策要么建立要么侵蚀用户信任

---

审查模式选择

从 .vibeflow/workflow.yaml 读取 spark.ceo_mode，与上表映射。兼容旧模板时可回退读取 plan.ceo_mode。

用户也可以直接指定模式：

1. SCOPE EXPANSION： 计划不错但可以更伟大
2. SELECTIVE EXPANSION： 计划范围是基准，但想看看还有什么可能
3. HOLD SCOPE： 计划范围正确，目标是让它无懈可击
4. SCOPE REDUCTION： 计划过度构建，提出最小可用版本

---

工程偏好（用于指导每个推荐）

• DRY 很重要——激进地标记重复
• 经过良好测试的代码是硬性要求
• 要"工程化得恰到好处"——不要欠工程也不要过度工程
• 偏好多处理边界情况而非少处理
• 最小 diff：用最少的新抽象和文件改动实现目标
• 可观察性不是可选的
• 安全性不是可选的
• 部署不是原子的——为部分状态、回滚和功能标志做计划

---

AskUserQuestion 格式

每次调用 AskUserQuestion 必须遵循这个结构：

1. Re-ground： 陈述项目、当前分支和当前计划/任务。（1-2 句）
2. Simplify： 用普通高中生能理解的简单语言解释问题
3. 推荐： RECOMMENDATION: Choose [X] because [one-line reason]
4. 选项： 字母选项 A) ... B) ... C) ...

---

深度审查章节

选定模式后，按以下章节深度审查计划。每个章节都必须覆盖。

Section 1: 架构与依赖

• 整体系统设计和组件边界
• 数据流：happy path、nil path、empty path、error path
• 状态机（如果涉及有状态对象）
• 耦合问题：哪些组件被耦合，是否合理？
• 扩展特性：10x 负载下什么先崩溃？
• 单点故障：列出并评估风险
• 安全边界：谁可以调用什么，得到什么，可以改变什么？
• 生产故障场景：每个集成点的真实故障模式

Section 2: 错误与救援图

每个新方法/服务/代码路径，填写：

METHOD/CODEPATH | WHAT CAN GO WRONG | EXCEPTION CLASS
---------------|-------------------|------------------
API call       | timeout           | TimeoutError
               | 429 rate limit   | RateLimitError
               | malformed JSON   | JSONParseError

规则：

• 永远命名具体异常类，不使用 catch-all
• 每个被捕获的错误必须：retry+backoff、graceful degrade、或 re-raise with context
• "Swallow and continue" 几乎不可接受

Section 3: 安全与威胁模型

• 攻击面扩展：新增了哪些攻击向量？
• 输入验证：nil、empty、超长、unicode、注入尝试？
• 授权：数据访问是否限制在正确的用户/角色？
• 凭证：新的 secrets？环境变量而非硬编码？可轮换？
• 依赖风险：新增的包安全性如何？
• 注入向量：SQL、命令、模板、LPM prompt 注入？
• 审计日志：敏感操作有审计跟踪吗？

Section 4: 数据流与交互边界

每个新数据流，ASCII 图：

  INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
    │            │              │            │           │
    ▼            ▼              ▼            ▼           ▼
  [nil?]    [invalid?]    [exception?]  [conflict?]  [stale?]

每个用户可见交互：

交互 | 边界情况 | 处理？ | 如何处理
表单提交 | 重复点击 | ? |
异步操作 | 用户离开 | ? |
列表视图 | 零结果 | ? |
后台任务 | 3/10 失败 | ? |

Section 5: 代码质量

• 代码组织是否符合现有模式？
• DRY 违规：相同逻辑是否出现在多处？
• 命名质量：类/方法/变量名是否见名知意？
• 缺失边界情况：明确列出"当 X 是 nil 时会发生什么"
• 过度工程检查：是否有解决不存在问题的抽象？
• 不足工程检查：是否只在 happy path？
• 循环复杂度：任何方法分支超过 5 次？

Section 6: 测试审查

每个新功能：

• 测试类型？Unit / Integration / System / E2E
• Happy path 测试？
• 失败路径测试？（具体哪个失败）
• 边界情况测试？（nil、empty、临界值、并发）

测试三角：是 many unit、fewer integration、few E2E 吗？ 测试脆弱性：依赖时间、随机性、外部服务、排序的测试？

Section 7: 性能审查

• N+1 查询：关联遍历是否用了 includes/preload？
• 内存使用：最大 production size 是多少？
• 数据库索引：每个新查询有索引吗？
• 缓存机会：昂贵的计算或外部调用应该缓存吗？
• 后台任务大小：最坏情况 payload、runtime、retry 行为？
• 连接池压力：新增 DB/Redis/HTTP 连接？

Section 8: 可观察性与可调试性

• 日志：新代码路径在 entry、exit、每个重要分支有结构化日志？
• 指标：每个新功能的 working/broken 指标？
• 追踪：跨服务/跨 job 流程是否传播 trace IDs？
• 告警：应该有哪些新告警？
• 可调试性：3 周后能仅从日志重建发生了什么吗？

Section 9: 部署与发布

• 迁移安全：每个 DB 迁移向后兼容？零宕机？表锁？
• 功能标志：部分应该被功能标志保护吗？
• 发布顺序：迁移优先？部署第二？
• Rollback 计划：显式步骤
• 部署时风险窗口：旧代码和新代码同时运行——什么会坏？
• 环境 parity：staging 测试过吗？
• Smoke tests：部署后立即运行什么自动化检查？

Section 10: 长期轨迹

• 技术债：代码债、运营债、测试债、文档债
• 路径依赖：是否让未来变更更难？
• 知识集中：文档够新工程师看懂吗？
• 可逆性：1=单向门，5=容易回滚
• 1 年后读这个计划：明显吗？

---

Fix-First 分类

每个发现分类为：

AUTO-FIX（直接修复）	ASK（需用户确认）
Dead code / 未使用变量	安全问题（Auth、XSS、注入）
N+1 查询（缺 eager loading）	竞态条件
过时注释与代码矛盾	设计决策
魔法数字 → 命名常量	大型修复（>20行）
变量赋值但从未读取	Enum 完整性
测试覆盖缺口（边界情况）	移除功能

---

Completion Status Protocol

完成 skill 工作流后，报告状态：

• DONE — 所有步骤成功完成，提供每项结论的证据
• DONE_WITH_CONCERNS — 完成但有问题需用户知晓
• BLOCKED — 无法继续，说明阻塞原因
• NEEDS_CONTEXT — 缺少继续所需信息

Escalation

可以说"这对我来说太难了"或"我对这个结果没有信心"。

• 尝试 3 次仍失败 → STOP 并升级
• 安全敏感变化不确定 → STOP 并升级
• 工作范围超出可验证范围 → STOP 并升级

---

产出

审查完成后，保存到 .vibeflow/plan-value-review.md：

# Plan Value Review — 商业价值评估

**日期**：YYYY-MM-DD
**审查分支**：[branch-name]
**审查模式**：[EXPANSION / SELECTIVE / HOLD / REDUCTION]

## 价值评估结论

[核心结论]

## 第一性原则检查
- 问题正确性：[评估]
- 实际业务结果：[评估]
- 不做的后果：[评估]

## 梦想状态映射
[描述 12 个月理想]

## 深度审查结论
[按 Section 1-10 的关键发现]

## 决策

**是否进入 scope 审查**：是 / 否

**理由**：
- [支持的理由]
- [风险/担忧]

## 后续行动

- [如果通过：继续 design 阶段（eng/design review 在 design 阶段末尾执行）]
- [如果拒绝：项目终止，记录原因]