gstack CEO Plan Review：面向 OpenClaw 的轻量级「CEO 式」方案评审技能全解

本文聚焦 gstack 仓库中 openclaw/skills/gstack-openclaw-ceo-review/SKILL.md 所定义的 OpenClaw 原生技能 gstack-openclaw-ceo-review：它是一套"以 CEO 视角挑战方案"的评审方法论，覆盖范围（Scope）决策的四种模式、9 条 Prime Directives、18 个认知模式、Step 0 核弹级范围挑战与 11 个评审小节的完整流程。读完后你能理解这套纯 Prompt 方法论的内部骨架、它与上游重型技能 /plan-ceo-review 的差异，以及它如何被 gstack 的文档生成管线打包、测试并分发到 OpenClaw 环境中。

一、这是什么：一个没有基础设施的方法论技能

gstack 与 OpenClaw 的集成遵循一个核心原则：gstack 是方法论来源（methodology source），而不是被移植的代码库。OpenClaw 的 ACP runtime 原生拉起 Claude Code 会话，gstack 只负责提供规划纪律与评审方法（见 docs/OPENCLAW.md）。

gstack-openclaw-ceo-review 是四个 OpenClaw 原生方法论技能之一（其余为 office-hours、investigate、retro），被官方文档描述为 "Strategic challenge（10-section review, 4 modes）"（见 docs/OPENCLAW.md；注意当前技能文件内已扩展为 11 个评审小节）。这些技能的关键特征在 docs/OPENCLAW.md 中被明确界定：

"Source lives in openclaw/skills/ in the gstack repo. These are hand-crafted adaptations of the gstack methodology for OpenClaw's conversational context. No gstack infrastructure (no browse, no telemetry, no preamble)."

这与上游 plan-ceo-review/SKILL.md 形成鲜明对比——后者是一个带完整 Preamble bash 脚本、telemetry、brain context、review dashboard 的重型技能。OpenClaw 版本则是"手工裁剪"的对话式适应版，只保留方法论内核，全部编码为 Prompt 文本，没有 daemon、没有 JSON-RPC，"The prompt is the bridge"。

技能文件自身的 frontmatter 也体现了这种极简主义，仅有两个字段：

---
name: gstack-openclaw-ceo-review
description: Use when asked to review a plan, challenge a proposal, run a CEO review, poke holes in an approach, think bigger about scope, or decide whether to expand or reduce the plan.
---

这个"frontmatter 只允许 name + description"的约束不是偶然，而是有测试保障的仓库不变量。test/openclaw-native-skills.test.ts 对四个 OpenClaw 原生技能逐一断言：frontmatter 必须以 --- 开头、可被解析为 YAML，且 Object.keys(parsed).sort() 必须严格等于 ['description', 'name']。也就是说，OpenClaw 技能不允许携带 triggers、gbrain、allowed-tools 等 gstack 基础设施字段——这从测试层面锁死了"无基础设施"的设计承诺。

触发时机（由 description 定义）：当用户要求"评审一个方案、挑战一个提议、跑一次 CEO review、给方案挑刺、放大范围思考、或决定扩大/收缩计划"时调用。

二、Philosophy：你不是来盖章的，你是来"制造卓越"的

技能开篇即确立了评审者的基本姿态：

"You are not here to rubber-stamp this plan. You are here to make it extraordinary, catch every landmine before it explodes, and ensure that when this ships, it ships at the highest possible standard."

评审姿态不是固定的，而是取决于用户需要什么，分为四种模式（posture）：

模式	角色隐喻	核心职责
SCOPE EXPANSION	"你在建造大教堂"	构想柏拉图式理想态，把范围向上推。问"多花 2 倍力气，什么能让它好 10 倍？"每个扩展项单独呈现，用户逐项选择 opt in / out
SELECTIVE EXPANSION	"有品位的严谨评审者"	以当前范围为基线，先把它做到防弹；但把所有扩展机会单独摆出来，让用户 cherry-pick
HOLD SCOPE	"严谨评审者"	接受方案范围不变，职责是把它做到防弹：抓住每个失败模式、测试每个边界、确保可观测性、映射每条错误路径。不悄悄削减也不悄悄扩大
SCOPE REDUCTION	"外科医生"	找到能达成核心结果的最小可行版本，其余全部砍掉，"Be ruthless"

贯穿所有模式的关键规则（Critical rule）：用户 100% 掌握控制权。任何范围变化都是显式 opt-in——绝不悄悄增删范围。

技能还设定了一条硬边界：不做任何代码修改，不启动实现。你的唯一职责是评审方案本身（"Do NOT make any code changes. Do NOT start implementation. Your only job is to review the plan."）。

三、Prime Directives：9 条评审铁律

这是 OpenClaw 技能中浓缩得最紧致的部分（上游 plan-ceo-review/SKILL.md 的对应章节措辞更长，此处为同一套原则的轻量版）：

1. 零静默失败。每个失败模式都必须可见（Zero silent failures. Every failure mode must be visible）。
2. 每个错误都有名字。不许说"处理一下错误"，要说出具体异常名、触发条件、谁捕获、用户看到什么。
3. 数据流有影子路径。每条数据流除 happy path 外还有三条影子路径：nil 输入、空/零长输入、上游错误。四条都要追踪。
4. 交互有边界情况。双击、动作中途离开页面、慢连接、过期状态、后退按钮——全部映射出来。
5. 可观测性是范围，不是事后补。新 dashboard、告警、runbook 是一级交付物。
6. 图是强制的。任何非平凡流程都不许没有图。
7. 所有推迟的事必须写下来。模糊的意图等于谎言（Vague intentions are lies）。
8. 为 6 个月后的未来优化，而不只是今天。
9. 你有权说"推翻重来，换成这样"。

对照上游版本可以看到这几条的展开细节：第 2 条在上游明确把"catch-all 错误处理（catch Exception / rescue StandardError / except Exception）"定性为代码坏味道；第 6 条要求"每个新数据流、状态机、处理管线、依赖图、决策树都配 ASCII 图"；第 7 条落地为"TODOS.md 里不存在的推迟就不存在"（见 plan-ceo-review/sections/review-sections.md）。

四、18 个认知模式：伟大 CEO 如何思考

技能强调这些是思考本能而非检查清单（"thinking instincts, not a checklist"），应贯穿整个评审过程塑造视角，而不是逐项打勾：

1. 分类本能：按"可逆性 × 影响幅度"给每个决策分类。大多数事是双向门，快速推进。
2. 偏执扫描：持续扫描战略拐点、文化漂移、人才流失。
3. 反转反射：每问"我们怎么赢"，也要问"什么会让我们输"。
4. 聚焦即减法：主要价值在于决定不做什么。默认：少做、做好。
5. 人优先排序：人、产品、利润——永远是这个顺序。
6. 速度校准：快是默认；只有"不可逆 + 高影响"的决策才慢下来。70% 的信息就足以决策。
7. 代理指标怀疑：我们的指标还在服务用户，还是已经变成自指游戏？
8. 叙事一致性：艰难决策需要清晰框架。让"为什么"可读，而不是让所有人都满意。
9. 时间纵深：按 5-10 年的弧线思考。重大下注用"遗憾最小化"评估。
10. 创始人模式偏好：深度介入不等于微观管理，前提是它扩展了团队的思考。
11. 战时意识：正确诊断现在是和平时期还是战时。
12. 勇气积累：信心来自做过艰难决策，而不是在决策之前就有。
13. 意志即战略：有意地固执。世界会向"在同一个方向上足够用力、足够久"的人让步。
14. 杠杆痴迷：找到"小投入、大产出"的输入点。
15. 层级即服务：每个界面决策都在回答"用户第一、第二、第三应该看到什么"。
16. 边界情况偏执：如果名字有 47 个字符呢？零结果呢？网络中途断了呢？
17. 减法默认："尽可能少的设计"。UI 元素没挣到自己的像素，就砍掉。
18. 为信任而设计：每个界面决策要么建立信任，要么侵蚀信任。

上游版本的 plan-ceo-review/SKILL.md 在这 18 条之外还加了一段"接线说明"：评审架构时启动反转反射，挑战范围时应用聚焦即减法，评估时间线时调用速度校准……OpenClaw 版省略了这段映射，保留纯列表形态。

五、Step 0：核弹级范围挑战 + 模式选择

Step 0 是整个技能的"前置战斗"，分 7 个子步骤（0A–0F），全部在正式 11 节评审之前完成。

0A. 前提挑战（Premise Challenge）

1. 这是正确的待解问题吗？换一个框架会不会得到显著更简单或影响更大的解？
2. 真正的用户/业务结果是什么？方案是通往该结果的最直接路径，还是在解一个"代理问题"？
3. 如果什么都不做会怎样？这是真实痛点还是假设痛点？

0B. 存量代码杠杆（Existing Code Leverage）

1. 把方案里的每个子问题映射到已有代码：哪些部分已被现有代码部分或完全解决？
2. 方案是否在重建已经存在的东西？

0C. 理想态映射（Dream State Mapping）

描述 12 个月后的理想终态，判断该方案是朝它靠近还是背离：

CURRENT STATE → THIS PLAN → 12-MONTH IDEAL

0C-bis. 实现备选方案（MANDATORY）

选模式之前必须先产出 2–3 个不同的实现路径。每个路径包含：

• 名称、摘要、工作量（S/M/L/XL）、风险（Low/Med/High）
• Pros（2–3 条）、Cons（2–3 条）、Reuses（复用了哪些现有代码）

硬约束：其中必须有一个是"最小可行版"（minimal viable），一个"理想架构"（ideal architecture）。

然后给出 RECOMMENDATION: Choose [X] because [reason]，并询问用户选哪条路径。未获批准不得继续。

从上游 plan-ceo-review/SKILL.md 的 0C-bis 章节可以看到这一节在完整版里的执行细节：两条路径"权重相等"——不要因为"最小可行"更小就默认选它；如果正确答案是重写，就说重写；备选只有一条时，必须具体解释其他备选为何被排除。

0D. 按模式做针对性分析

• SCOPE EXPANSION：跑 10x 检查、柏拉图理想态、delight 机会，然后每个扩展提案单独呈现，用户逐项选择。
• SELECTIVE EXPANSION：先跑 HOLD SCOPE 分析，再把扩展机会逐个摆出来供 cherry-pick。
• HOLD SCOPE：跑复杂度检查与最小变更集分析。
• SCOPE REDUCTION：跑无情裁剪（ruthless cut）与后续 PR 拆分。

上游版本在这一步给出了更具体的操作标准，可作为"什么叫完成该分析"的参照：EXPANSION 模式要求 delight 机会至少列 5 个；HOLD/SELECTIVE 的复杂度检查有量化阈值——触碰超过 8 个文件，或引入超过 2 个新类/服务，就视为坏味道；REDUCTION 模式要求区分"必须一起上线"与"最好一起上线"（见 plan-ceo-review/SKILL.md Step 0D）。

0E. 时间线拷问（Temporal Interrogation）

预想实现过程，把"实现中才会遇到的决策"提前到现在解决：

HOUR 1（地基）：实现者需要知道什么？ HOUR 2-3（核心逻辑）：他们会撞上什么歧义？ HOUR 4-5（集成）：什么会让他们意外？ HOUR 6+（打磨/测试）：他们会后悔没提前规划什么？

0F. 模式选择（Mode Selection）

向用户呈现四个选项：

1. SCOPE EXPANSION —— 梦想放大，提出雄心版
2. SELECTIVE EXPANSION —— 守住基线，cherry-pick 扩展
3. HOLD SCOPE —— 最大严谨度，做到防弹
4. SCOPE REDUCTION —— 无情裁剪到最小可行版

并附带上下文相关的默认建议（这是技能中可直接落地的决策表）：

场景	默认模式
绿地新功能（Greenfield feature）	EXPANSION
功能增强	SELECTIVE EXPANSION
Bug 修复 / hotfix	HOLD SCOPE
重构	HOLD SCOPE
方案触碰 >15 个文件	建议 REDUCTION

选定后完全承诺，不许悄悄漂移（"Once selected, commit fully. Do not silently drift."）。上游版本还补充了两条用户显式意图的直通规则：用户说"go big / ambitious / cathedral"直接进 EXPANSION；说"hold scope but tempt me / show me options / cherry-pick"直接进 SELECTIVE EXPANSION，均不再询问。

六、11 个评审小节（Anti-skip 规则）

Step 0 敲定范围与模式后，进入正式的 11 节深度评审。OpenClaw 技能文件给出了每节的一句话职责定义，上游 plan-ceo-review/sections/review-sections.md 则展开了每节的具体检查表、强制图表和停止点——对照阅读可把 OpenClaw 的"摘要骨架"还原成可执行的评审动作。

两条全局规则：

• Anti-skip rule：无论方案类型如何，任何评审小节都不得被压缩、缩略或跳过。某节确实零发现时，明说 "No issues found" 再走开，但必须评估过。
• 一次只问一个问题（"Ask the user about each issue ONE AT A TIME. Do NOT batch."）。

逐节内容与上游展开：

#	小节	OpenClaw 版职责	上游版关键检查项（review-sections.md）
1	架构评审	系统设计与组件边界、数据流（四条路径）、状态机、耦合、扩展性、安全架构、生产失败场景、回滚姿态；画依赖图	每个新数据流画 happy/nil/empty/error 四条 ASCII 图；画 before/after 依赖图；每个新集成点描述一个真实生产失败场景；回滚要有明确步骤与时长
2	错误与救援图	每个可能失败的新方法/代码路径：命名异常、是否被救援、救援动作、用户看到什么；catch-all 永远是坏味道	产出两张表：方法→异常类，异常类→RESCUED?/RESCUE ACTION/USER SEES。任何"未救援 + 无测试 + 静默"的行判定为 CRITICAL GAP。LLM 调用单独列出畸形响应/空响应/幻觉 JSON/拒答四种失败模式
3	安全与威胁模型	攻击面扩张、输入校验、鉴权、密钥管理、依赖风险、数据分级、注入向量、审计日志	每条发现标注 threat / likelihood(H/M/L) / impact(H/M/L) / 方案是否缓解；输入校验须覆盖 nil、空串、类型错、超长、unicode 边界、脚本注入；鉴权须查越权对象引用（用户 A 操纵 ID 访问用户 B 数据）
4	数据流与交互边界	沿 input → validation → transform → persist → output 追踪，标注每个节点对 nil、空、类型错、超长、超时、冲突、编码问题的行为	标准 ASCII 追踪图 + 交互边界表：表单提交（双击、CSRF 过期、部署中提交）、异步操作（中途离开、超时、在飞重试）、列表（零结果、万级结果、翻页中数据变化）、后台任务（10 个中失败 3 个、重复执行、队列积压）
5	代码质量评审	组织结构、DRY 违背、命名质量、错误处理模式、缺失边界、过度工程、工程不足、圈复杂度	DRY 违背要指出具体文件与行号；分支超过 5 次的新方法要提出重构；同时检查"过度工程"（为不存在的问题建抽象）与"工程不足"（只走 happy path）
6	测试评审	给每个新 UX 流、数据流、代码路径、后台任务、集成、错误路径画图；逐项回答：什么测试覆盖它？是否存在？差距在哪？	测试野心三问："让你敢周五凌晨 2 点发版的测试是什么？""敌对 QA 工程师会写什么测试？""混沌测试是什么？"；外加测试金字塔（大量单元、少量集成、更少 E2E）与 flakiness 风险检查
7	可观测性与监控	新指标、dashboard、告警、runbook；对每条新代码路径回答："生产环境它坏了，你怎么知道？"	上游把它细分为 logging（入口/出口/分支的结构化日志）、metrics（什么指标说明它在正常工作、什么说明它坏了）、tracing（跨服务 trace ID）、alerting、dashboards（day-1 面板）、debuggability（3 周后报 bug，能否只靠日志重建现场）、admin 工具、runbooks
8	数据库与状态管理	新表、索引、迁移、查询模式；N+1 风险；数据完整性约束	N+1 检查（新关联遍历是否有 includes/preload）、内存上限、新查询是否有索引、昂贵计算是否该缓存、后台任务最坏负载/运行时长/重试行为、连接池压力
9	API 设计与契约	新端点、请求/响应形状、向后兼容、版本化、限流	部署维度另查：迁移是否向后兼容/零停机/锁表、新旧代码并行窗口会坏什么、发布顺序（先迁移后部署）、部署后 5 分钟/1 小时验证清单
10	性能与可扩展性	10 倍负载下什么先坏？100 倍呢？内存、CPU、网络、数据库热点	新增技术债盘点（代码/运维/测试/文档）、路径依赖、可逆性评分（1=单向门，5=易回退）、"12 个月后新工程师读这份方案还看得懂吗"（1 年问题）
11	设计与 UX（仅当方案触碰 UI）	信息层级、空态/加载/错误态、响应式策略、可访问性、与既有设计模式的一致性	交互状态覆盖表（LOADING/EMPTY/ERROR/SUCCESS/PARTIAL 全覆盖）、用户旅程情感弧线、"AI slop 风险"（是否只是泛化 UI 套路）、移动端是有意设计还是事后想法；显著 UI 范围建议追加跑专门的设计评审

值得注意的结构差异：上游完整版的小节切分是"性能 / 可观测性 / 部署与回滚 / 长期轨迹 / 设计"，而 OpenClaw 版压缩为 11 节并把"部署风险"并入架构（第 1 节的 rollback posture）、把"长期轨迹"精神并入 Prime Directives 第 8 条（为 6 个月后的未来优化）。这正是"hand-crafted adaptation"的含义——同一方法论的对话式瘦身，而非机械截断。

七、输出契约：CEO REVIEW SUMMARY 与完成状态

11 节评审全部完成后，技能要求产出一份干净的结构化总结：

**CEO REVIEW SUMMARY**
- **Mode:** [选定的模式]
- **Strongest challenges:** [发现的 top 3 问题]
- **Recommended path:** [下一步做什么]
- **Accepted scope:** [范围内有什么]
- **Deferred:** [范围外有什么，以及为什么]
- **NOT in scope:** [被显式排除的条目]

并要求把总结保存到 memory/ 目录供未来引用。在 OpenClaw 语境下，这与 openclaw/gstack-plan-CLAUDE.md 的 PLAN 档流水线闭环：规划流水线要求把最终评审过的方案写入 plans/<project-slug>-plan-<date>.md，并向 orchestrator 汇报"方案文件路径 + 一段话摘要 + 已接受的范围扩展列表 + 推荐下一步"，由 orchestrator 把方案链接持久化到自己的记忆库。

技能的 Important Rules 收尾四条，加上完成状态协议：

• 不改代码——这个技能评审方案，不实现方案。
• 一次只问一个问题——绝不把多个问题打包。
• 每节都必须被评估——未经审视的"不适用"永远不成立。
• 用户永远掌控——任何范围变化都是显式 opt-in。

完成状态三值：

• DONE —— 评审完成，所有小节均已评估，总结已产出；
• DONE_WITH_CONCERNS —— 评审完成但存在未决问题；
• BLOCKED —— 缺少必要上下文，无法评审。

（上游完整版还多出第四态 NEEDS_CONTEXT，见 plan-ceo-review/SKILL.md 的 Completion Status Protocol。）

八、纵深对比：OpenClaw 版裁掉了什么，保住了什么

把 OpenClaw 技能文件与上游 plan-ceo-review/SKILL.md（1530 行）并排看，裁剪策略非常清晰：

裁掉的基础设施（"No gstack infrastructure"的实证）：

• Preamble 运行时脚本：上游每个技能启动时执行一段约 110 行的 bash，做更新检查、会话登记（~/.gstack/sessions）、telemetry 采样、learnings 加载、repo-mode 探测、plan-mode 状态判定等；OpenClaw 版零 bash。
• gbrain 上下文查询：上游 frontmatter 声明了三条 context_queries（历史 CEO plans、近期 design docs、近期 CEO 评审活动，glob 如 ~/.gstack/projects/{repo_slug}/ceo-plans/*.md）；OpenClaw 版没有任何 gbrain 字段——这与 hosts/openclaw.ts 中 suppressedResolvers: [...CROSS_MODEL_RESOLVERS, ...GBRAIN_RESOLVERS] 的宿主级配置一致：OpenClaw 宿主在文档生成层面就抑制了 cross-model 与 gbrain 相关解析器。
• AskUserQuestion 决策简报协议：上游为每个交互问题定义了严格的 D<N> 简报格式（ELI10、Completeness 评分、(recommended) 标记、5+ 选项拆分链等）；OpenClaw 版只保留"逐项呈现、用户 opt in/out"的语义。
• Outside Voice / 跨模型第二意见：上游评审结束后默认调用 Codex（或降级 Claude subagent）跑一次独立方案挑战，并对"跨模型分歧"逐项走用户决策；OpenClaw 版无此环节。
• 持久化工件链：上游在 EXPANSION/SELECTIVE 模式把 CEO plan 落盘到 ~/.gstack/projects/$SLUG/ceo-plans/{date}-{feature-slug}.md（含 Vision、Scope Decisions 表、Accepted Scope、Deferred 四段），并对其跑一轮"对抗式规格评审循环"（独立 subagent 按 Completeness/Consistency/Clarity/Scope/Feasibility 五维打分，最多 3 轮）；OpenClaw 版只要求总结存入 memory/。
• EXIT PLAN MODE GATE：上游在退出 plan mode 前强制自检——plan 文件最后一个 ## 标题必须是 ## GSTACK REVIEW REPORT，且报告末行必须是 NO UNRESOLVED DECISIONS 哨兵或 **UNRESOLVED DECISIONS:** 列表，否则不许退出；OpenClaw 版不运行在 Claude Code plan mode 内，无此门禁。

保住的骨架（方法论不变量）：

四种模式及其角色隐喻、"用户 100% 掌控 + 显式 opt-in"铁律、9 条 Prime Directives、18 个认知模式、0A–0F 的 Step 0 全序列（含"2–3 个备选方案必选其一"的强制项与"bugfix 默认 HOLD、>15 文件建议 REDUCTION"的决策表）、11 节评审的 anti-skip 与"一次一问"规则、结构化 SUMMARY 与三态完成状态。

换言之：上游是"可执行的工作流引擎 + 方法论"，OpenClaw 版是"纯方法论"。测试 test/openclaw-native-skills.test.ts 锁定的 frontmatter 形状，正是这条分界线的自动化守卫。

九、分发链路：这个技能如何到达 OpenClaw

从源码结构看，openclaw/ 目录下的产物分两类，生成路径不同：

1. CLAUDE.md 模板（自动生成）：openclaw/templates/ 下的 gstack-full-CLAUDE.md、gstack-lite-CLAUDE.md、gstack-plan-CLAUDE.md 是模板源，由 scripts/gen-skill-docs.ts 的 --host openclaw 管线渲染到 openclaw/ 目录（该脚本在 host 为 openclaw 时把 templates 下的同名文件复制到 openclaw/gstack-plan-CLAUDE.md 等位置并打印 GENERATED: 日志）。
2. 原生技能（手工编写）：openclaw/skills/ 下的四个 SKILL.md 无对应 .tmpl 文件，属于 hand-crafted，不经过模板渲染——这也是为什么 docs/OPENCLAW.md 称之为 "hand-crafted adaptations"。

宿主适配层同样有代码佐证：hosts/openclaw.ts 通过 defineHost 定义 openclaw 宿主，其中 extraPathRewrites: [{ from: 'CLAUDE.md', to: 'AGENTS.md' }] 说明文档生成时会把指向 CLAUDE.md 的路径重写为 OpenClaw 使用的 AGENTS.md；coAuthorTrailer 则标注 Co-Authored-By: OpenClaw Agent <[e-mail]>。

何时会触发这个技能由 OpenClaw 侧的 dispatch routing 决定。docs/OPENCLAW.md 与 openclaw/agents-gstack-section.md 给出同一张分档表：

档位	触发场景	注入内容
Simple	单文件改动、错别字、配置	不注入 gstack 上下文
Medium	多文件功能、重构	追加 gstack-lite 规划纪律
Heavy	点名某个 gstack 技能（/cso、/review、/qa 等）	"Load gstack. Run /X"
Full	完整功能、项目级目标	追加 gstack-full 流水线（/autoplan → 实现 → /ship）
Plan	只规划不实现	追加 gstack-plan 流水线（/office-hours → /autoplan → 落盘方案 → 汇报）

三条不可协商的行为规则排在分档表之上：永远 spawn 而不是让用户自己去开 Claude Code；用户点名仓库就先解析工作目录；/autoplan 必须端到端跑完并在聊天里回报。CEO 评审技能本身属于 OpenClaw 的"原生对话技能"——用户在 Telegram 等入口直接说"帮我挑战一下这个方案"时，由 OpenClaw orchestrator 依 description 触发，无需 spawn 会话。

十、使用前提与限制

• 适用前提：该技能是纯 Prompt 方法论文本，本身无运行时依赖；它假设使用者（OpenClaw 侧的 LLM 会话）能读懂 Markdown 指令并逐项执行。上游完整版则依赖已安装的 gstack（~/.claude/skills/gstack）、bash 工具链、git 仓库环境，两者不可混用。
• 文档口径差异：docs/OPENCLAW.md 摘要写作 "10-section review"，而当前技能文件为 11 节（Section 11 Design & UX 标注了"仅当方案触碰 UI"的条件触发）——以技能文件为准。
• 只读边界：本技能在 OpenClaw 对话中运行，产出是对话内评审与 memory/ 总结；若需要完整工件链（CEO plan 落盘、review report 写回 plan 文件、review log/dashboard、跨模型 outside voice），应使用上游的 plan-ceo-review/SKILL.md 而非本文介绍的轻量版。
• 仓库内继续深入的入口：方法论完整版见 plan-ceo-review/SKILL.md 与 plan-ceo-review/sections/review-sections.md；集成协议见 docs/OPENCLAW.md；分发与宿主适配见 scripts/gen-skill-docs.ts、hosts/openclaw.ts；形状不变量测试见 test/openclaw-native-skills.test.ts。

这套设计的启发在于：同一条评审方法论可以有两个物理形态——一个带 telemetry、门禁与工件链的"工作流引擎"，一个只有 Prompt 的"方法论内核"，两者由测试（frontmatter 形状）与文档（"No gstack infrastructure"）显式分界，而认知内核（四模式、九铁律、十八本能、十一小节）在两个形态间保持逐字一致。