Menü
Plan 阶段第一步 — CEO/Founder 视角的商业价值评估
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | vibeflow-plan-value-review |
| description | Plan 阶段第一步 — 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。
对每个计划，回答：
描述系统 12 个月后的理想终态。这个计划是在朝那个方向走还是背离？
当前状态 本计划 12 个月理想
[描述] ---> [描述增量] ---> [描述目标]
在选择模式之前，必须产出 2-3 个不同实施路径：
路径 A：[名称]
摘要：[1-2 句]
Effort: [S/M/L/XL]
风险: [低/中/高]
优点: [2-3 点]
缺点: [2-3 点]
复用: [复用的现有代码/模式]
路径 B：[名称]
...
路径 C：[名称]（如有意义的差异化路径）
...
推荐： 选择 [X]，原因：[一句话，与工程偏好对齐]。
规则：
这些不是清单——它们是思维本能，让你在审查中像 10x CEO 一样思考：
从 .vibeflow/workflow.yaml 读取 spark.ceo_mode，与上表映射。兼容旧模板时可回退读取 plan.ceo_mode。
用户也可以直接指定模式：
每次调用 AskUserQuestion 必须遵循这个结构：
RECOMMENDATION: Choose [X] because [one-line reason]A) ... B) ... C) ...选定模式后，按以下章节深度审查计划。每个章节都必须覆盖。
每个新方法/服务/代码路径，填写：
METHOD/CODEPATH | WHAT CAN GO WRONG | EXCEPTION CLASS
---------------|-------------------|------------------
API call | timeout | TimeoutError
| 429 rate limit | RateLimitError
| malformed JSON | JSONParseError
规则：
每个新数据流，ASCII 图：
INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[nil?] [invalid?] [exception?] [conflict?] [stale?]
每个用户可见交互：
交互 | 边界情况 | 处理？ | 如何处理
表单提交 | 重复点击 | ? |
异步操作 | 用户离开 | ? |
列表视图 | 零结果 | ? |
后台任务 | 3/10 失败 | ? |
每个新功能：
测试三角：是 many unit、fewer integration、few E2E 吗？ 测试脆弱性：依赖时间、随机性、外部服务、排序的测试？
每个发现分类为：
| AUTO-FIX（直接修复） | ASK（需用户确认） |
|---|---|
| Dead code / 未使用变量 | 安全问题（Auth、XSS、注入） |
| N+1 查询（缺 eager loading） | 竞态条件 |
| 过时注释与代码矛盾 | 设计决策 |
| 魔法数字 → 命名常量 | 大型修复（>20行） |
| 变量赋值但从未读取 | Enum 完整性 |
| 测试覆盖缺口（边界情况） | 移除功能 |
完成 skill 工作流后，报告状态：
可以说"这对我来说太难了"或"我对这个结果没有信心"。
审查完成后，保存到 .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 阶段末尾执行）]
- [如果拒绝：项目终止，记录原因]
启动 VibeFlow 本地看板，实时查看阶段、功能、产物和最近事件。
查看 VibeFlow 项目当前状态（阶段、进度、待处理项）。
VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。
测试阶段的真实浏览器验证底座。用于页面交互、表单、路由、前端 API、视觉状态和运行时问题验证。优先使用 Playwright MCP 做真实交互验证，使用 Chrome DevTools MCP 做运行时诊断；MCP 不可用时回退到本地 Playwright CLI 脚本。
在此仓库中用于在会话开始时路由整个VibeFlow生命周期的工作。
系统测试通过后且工作流要求 UI QA 时使用 — 运行浏览器导向的 QA 验证并生成报告