plan-ceo-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CEO Plan Review

CEO计划评审

Pressure-test a plan that already exists. Decide whether it is ambitious enough, focused enough, sequenced well, and worth the opportunity cost.

Be opinionated. A useful review makes a clear scope call, names the strongest objection, and gives the smallest next move that would prove or disprove the recommendation.

对已有的计划进行压力测试。判断其是否足够有野心、重点是否明确、排序是否合理，以及是否值得付出机会成本。

要有明确的观点。一份有用的评审需要明确界定范围，指出最强烈的反对意见，并给出能验证或推翻建议的最小下一步行动。

When to Use

使用场景

The user asks for a CEO review, founder-mode review, strategy review, ambition review, or "think bigger" pass.
The user provides an implementation plan, product spec, roadmap proposal, issue plan, PR plan, strategy memo, launch plan, or pasted plan.
A
```
superteam
```
artifact needs advisory strategic critique before its owning teammate decides what to change.

用户请求CEO评审、创始人模式评审、战略评审、野心评估，或是要求“拓宽思路”。
用户提供了实施计划、产品规格、路线图提案、问题计划、PR计划、战略备忘录、发布计划，或是粘贴的计划内容。
```
superteam
```
的成果在负责的团队成员决定修改内容之前，需要得到战略性的咨询批评。

When Not to Use

不适用场景

The user has only an idea and no plan. Ask for the plan, or route to
```
office-hours
```
for pre-plan discovery.
The user wants customer discovery, demand validation, or a first design doc. Use
```
office-hours
```
.
The user wants code review, test review, or implementation quality review. Use the repo's review workflow.
Inside
```
superteam
```
, do not approve Gate 1, replace Planner, replace Reviewer, or alter Finisher shutdown. This skill is advisory only.

用户只有想法而没有计划。请索要计划，或引导至
```
office-hours
```
进行计划前的探索。
用户想要进行客户探索、需求验证或撰写第一份设计文档。使用
```
office-hours
```
。
用户想要代码评审、测试评审或实施质量评审。使用仓库的评审工作流程。
在
```
superteam
```
内部，不批准Gate 1、替换Planner、替换Reviewer，或更改Finisher的收尾工作。此技能仅提供咨询意见。

Inputs

输入

Identify the artifact before reviewing. If context is missing, ask at most three clarifying questions; otherwise state assumptions and proceed.

What kind of plan is it: implementation, product, strategy, roadmap, issue, PR, launch, or operations?
Who benefits: user, buyer, operator, maintainer, teammate, or sponsor?
What outcome, constraint, and evidence matter most?

在评审前先明确成果类型。如果上下文缺失，最多提出三个澄清问题；否则说明假设并继续。

这是什么类型的计划：实施、产品、战略、路线图、问题、PR、发布还是运营计划？
受益者是谁：用户、购买者、运营者、维护者、团队成员还是赞助商？
最重要的结果、约束条件和依据是什么？

Review Modes

评审模式

Choose exactly one mode for the verdict.

Mode	Use When	Behavior
`Expand`	Directionally right, but too local	Name the larger bet and the smallest credible move toward it
`Selectively expand`	Core scope is right, but one missing move would add leverage	Keep the center, add the highest-leverage move, gate later expansion
`Hold`	Scope is right and execution discipline matters most	Tighten premise, success criteria, sequencing, and surprise risk
`Reduce`	Plan is overloaded, premature, or trying to solve too much	Strip to the essential wedge and defer what has not earned its cost

为结论选择恰好一种模式。

模式	使用场景	行为
`Expand`	方向正确，但过于局限	指出更大的赌注，以及实现它的最小可行行动
`Selectively expand`	核心范围正确，但缺少一个能增加影响力的行动	保留核心内容，添加影响力最高的行动，后续扩张需通过验证
`Hold`	范围正确，且执行纪律最为重要	收紧前提、成功标准、排序和意外风险
`Reduce`	计划过载、不成熟，或试图解决过多问题	精简到最核心的部分，推迟那些尚未证明其价值的内容

Workflow

工作流程

Restate the plan in one sentence, using the user's concrete nouns.
Identify the outcome that would make the work matter.
Test the premise: what assumption, if false, makes the plan wasteful?
Test ambition: does this create a meaningful change or only tidy the local surface?
Test scope: should the plan expand, selectively expand, hold, or reduce?
Test user value: who benefits, what changes in their workflow, and what proof would validate it?
Test sequencing: what must happen first, what can wait, and what gate prevents thrash?
Test risks: premise, product, execution, and opportunity cost.
Recommend one decision, the smallest next move, and the next artifact to produce.

Keep the review concrete. Do not write a broad essay, generic strategy advice, or a second plan unless the user asks for one.

用用户使用的具体名词，用一句话重述计划。
确定能让这项工作产生价值的结果。
测试前提：如果哪个假设不成立，会导致计划白费？
测试野心：这能带来有意义的改变，还是仅仅优化了局部表面？
测试范围：计划应该扩张、选择性扩张、保持还是精简？
测试用户价值：谁受益，他们的工作流程会有什么变化，什么证据能验证这一点？
测试排序：什么必须先做，什么可以等待，什么决策节点能避免无效工作？
测试风险：前提风险、产品风险、执行风险和机会成本风险。
推荐一个决策、最小的下一步行动，以及接下来要生成的成果。

评审要具体。不要写宽泛的文章、通用的战略建议，或是另一份计划，除非用户要求。

Calibration

校准示例

```
Expand
```
: "This solves the admin problem, but the bigger bet is becoming the weekly operating review."
```
Selectively expand
```
: "Keep the importer, but add a saved failure report because it changes trust."
```
Hold
```
: "Do not add dashboard scope; the plan already proves the riskiest integration."
```
Reduce
```
: "Drop multi-account support until one account can complete the workflow cleanly."

```
Expand
```
：“这解决了管理问题，但更大的赌注是成为每周运营评审的核心工具。”
```
Selectively expand
```
：“保留导入功能，但添加保存失败报告的功能，因为这能提升信任度。”
```
Hold
```
：“不要添加仪表盘范围；该计划已经能验证风险最高的集成部分。”
```
Reduce
```
：“在单个账户能顺利完成工作流程之前，取消多账户支持。”

Output

输出格式

Use these headings:

```
Verdict
```
: one mode plus one-sentence rationale.
```
Premise check
```
: core assumption, why it might be false, evidence that would change the review.
```
Ambition check
```
: current ambition, stronger outcome, what would make this matter.
```
Scope decision
```
: add, keep, defer, remove.
```
User value
```
: beneficiary, workflow change, validating proof.
```
Sequencing
```
: first move, later moves, decision gates.
```
Risks
```
: premise, product, execution, and opportunity-cost risks.
```
Recommendation
```
: decision, smallest next move, next artifact to produce.

If a field does not apply, write

None

and explain why in one phrase.

使用以下标题：

```
Verdict
```
：一种模式加上一句话的理由。
```
Premise check
```
：核心假设、可能不成立的原因、能改变评审结果的证据。
```
Ambition check
```
：当前野心程度、更理想的结果、什么能让这项工作更有意义。
```
Scope decision
```
：添加、保留、推迟、移除。
```
User value
```
：受益者、工作流程变化、验证证据。
```
Sequencing
```
：首要行动、后续行动、决策节点。
```
Risks
```
：前提风险、产品风险、执行风险和机会成本风险。
```
Recommendation
```
：决策、最小的下一步行动、接下来要生成的成果。

如果某个字段不适用，填写

None

并附上一句话解释原因。

Red Flags

警示信号

The plan optimizes an internal artifact but cannot name a user workflow that improves.
The plan adds architecture, process, or polish before proving the premise.
The plan says "platform" but lacks a narrow wedge.
The plan is busy, but the expected outcome is small.
The plan claims strategic value without naming a business, user, or trust consequence.
The review stays neutral when the plan needs a decision.
The review asks broad discovery questions after the user has already supplied a plan.

计划优化了内部成果，但无法指出能改善的用户工作流程。
计划在验证前提之前就添加了架构、流程或优化内容。
计划提到“平台”但没有明确的核心切入点。
计划内容繁琐，但预期结果很小。
计划声称具有战略价值，但未提及对业务、用户或信任的影响。
当计划需要明确决策时，评审保持中立。
用户已经提供计划后，评审仍提出宽泛的探索性问题。