gstack OpenClaw Plan 层详解用 gstack-plan 流水线为 Claude Code 项目产出全量评审过的实施计划【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstackgstack 与 OpenClaw 的集成把「方法论」当作注入式提示词文本而不是移植代码库。其中openclaw/gstack-plan-CLAUDE.md定义了五档分发路由中的Plan 层当用户只想「规划一个 Claude Code 项目」而先不写代码时编排器orchestrator会把这份模板追加到目标仓库的 CLAUDE.md驱动 Claude Code 依次跑/office-hours设计文档与/autoplan全量评审流水线最终产出一个落盘的计划文件并回报编排器。读完本文你能完整理解这条「只规划、不实现」流水线的每一步契约、它依赖的两个核心技能的内部机制以及计划如何交接给后续的实现会话。一、gstack 的 OpenClaw 集成一份轻量协议五档分发路由gstack 对 OpenClaw 的定位是「方法论来源」a methodology source不是移植的代码库。OpenClaw 的 ACP runtime 原生负责派生spawnClaude Code 会话gstack 则提供让会话更可靠的规划纪律与方法论。按 docs/OPENCLAW.md 的说法这是一份「编码为提示词文本的轻量协议。没有守护进程没有 JSON-RPC没有兼容矩阵——提示词本身就是桥」。集成架构如下引自 docs/OPENCLAW.mdOpenClaw gstack repo ───────────────────── ────────────── Orchestrator: messaging, Source of truth for calendar, memory, EA methodology planning │ │ ├── Native skills (conversational) ├── Generates native skills │ office-hours, ceo-review, │ via gen-skill-docs pipeline │ investigate, retro │ │ ├── Generates gstack-lite ├── sessions_spawn(runtime: acp) │ (planning discipline) │ │ │ │ └── Claude Code ├── Generates gstack-full │ └── gstack installed at │ (complete pipeline) │ ~/.claude/skills/gstack │ │ └── docs/OPENCLAW.md (this file) └── Dispatch routing (AGENTS.md)OpenClaw 在派生会话时决定使用哪一档 gstack 支持。完整的五档路由表见 docs/OPENCLAW.md 与 openclaw/agents-gstack-section.md档位适用场景注入内容Simple单文件修改、错别字、配置变更不注入 gstack 上下文Medium多文件功能、重构追加 gstack-lite CLAUDE.mdHeavy需要特定 gstack 技能Load gstack. Run /XFull完整功能、目标级项目追加 gstack-full 流水线Plan「帮我规划一个 Claude Code 项目」追加 gstack-plan 流水线对应的决策启发式decision heuristic改动小于 10 行代码→Simple涉及多文件但方案显而易见→Medium用户点名了某个技能/cso、/review、/qa→Heavy是功能、项目或目标而非单个任务→Full用户想在实现之前先做规划PLAN something without implementing yet→PlanPlan 档的派生动作在 openclaw/agents-gstack-section.md 中给出**PLAN:** user wants to plan a Claude Code project, spec out a feature, or design something before any code is written → sessions_spawn(runtime: acp, prompt: gstack-plan content\n\ntask) Claude Code runs: /office-hours → /autoplan → saves plan file → reports back Persist the plan link to memory/knowledge store. When the user is ready to implement, spawn a new FULL session pointing at the plan.三条不可协商的行为规则也写在分发路由之前永远派生、永不转介不要让用户自己去开 Claude Code、先解析仓库用户点名仓库就设置工作目录不知道就问、Autoplan 端到端跑完派生后让它跑完整条流水线再在聊天里回报结果用户永远不需要离开 Telegram。二、gstack-plan 流水线全解原文五步契约openclaw/gstack-plan-CLAUDE.md 全文仅约 20 行但每一步都是硬性契约。模板开头声明了它的注入时机与方式Injected by the orchestrator when the user wants to plan a Claude Code project. Append to existing CLAUDE.md.注意「Append」——这与 docs/OPENCLAW.md 中的 CLAUDE.md 冲突处理规则一致当目标仓库已有 CLAUDE.md 时以新增小节的形式追加绝不替换仓库既有的项目说明。Step 1读取 CLAUDE.md理解项目上下文流水线第一步是读 CLAUDE.md 并理解项目上下文。这一步与 gstack-full 的第一步完全一致见 openclaw/gstack-full-CLAUDE.md体现了 gstack 的基本假设项目根的 CLAUDE.md 是会话的首要上下文来源规划必须建立在项目既有约定之上而不是凭空设计。Step 2运行 /office-hours 产出设计文档第二步要求运行/office-hours产出一份包含**问题陈述problem statement、前提假设premises、备选方案alternatives**的设计文档。/office-hours技能的完整定义在 office-hours/SKILL.md值得注意的实现细节它自我定位为一个「YC office hours partner」职责是在提出任何解决方案之前确保问题被真正理解并根据构建者类型切换风格——创业公司创始人得到尖锐的追问个人开发者得到热情的协作者它有一条硬性门HARD GATE不得调用任何实现类技能、不得写任何代码、不得搭建任何脚手架——「你唯一的产出是一份设计文档」Startup 模式使用「六个强问题」six forcing questions暴露需求现实、现状、绝望的具体性、最窄切入点、观察与未来适配性Builder 模式则做设计思维头脑风暴它的 frontmatter 中声明了 gbrain 上下文查询prior office-hours sessions、builder profile、design-doc-history、prior eureka moments即如果配置了 gbrain 记忆库提问前会先加载项目相关的结构化上下文避免重复提问已知答案。gstack 还为 OpenClaw 提供了对话端的原生适配版本 openclaw/skills/gstack-openclaw-office-hours/SKILL.md「Product interrogation, 6 forcing questions」但 Plan 档真正驱动的是 Claude Code 里的完整版/office-hours。Step 3运行 /autoplan 做全量评审第三步是运行/autoplan评审设计评审构成是CEO 工程 设计 DX 四轮评审外加 Codex 对抗codex adversarial。/autoplan的完整实现见 autoplan/SKILL.md它是 gstack 的「自动评审流水线」从磁盘读取 CEO、设计、工程、DX 四份评审技能文件并逐个以完整深度执行唯一区别是中间的 AskUserQuestion 由 6 条决策原则自动裁决而品味型决策taste decisions留到最终审批门Final Approval Gate一次性呈现。理解 Plan 档的第三步关键在于理解 /autoplan 的这几个机制严格串行执行阶段必须按 CEO → Design → Eng → DX 顺序执行前一阶段完整产出写盘后才能进入下一阶段禁止并行——每个阶段都构建在前一个阶段之上。各阶段的完整定义分别位于 autoplan/sections/ceo-phase.md、autoplan/sections/design-phase.md、autoplan/sections/eng-phase.md、autoplan/sections/dx-phase.md。其中 Design 阶段仅在 Phase 0 检测到 UI 范围时运行DX 阶段仅在检测到面向开发者的范围时运行。6 条决策原则The 6 Decision Principles这是「自动裁决」的裁决依据选择完整性Choose completeness——做完整的东西选覆盖更多边界情况的方案烧干湖泊Boil lakes——修复「爆炸半径」内本计划修改的文件 直接 importer的所有问题在爆炸半径内且小于 1 天 CC 工作量 5 个文件、无新基础设施的扩张自动批准务实Pragmatic——两个方案解决同一问题时选更干净的5 秒决策而非 5 分钟DRY——与既有功能重复就拒绝复用已存在的显式优于巧妙Explicit over clever——10 行显而易见的修复优于 200 行抽象偏向行动Bias toward action——合并 评审循环 陈旧 deliberation标记顾虑但不阻塞。冲突时有上下文相关的裁定CEO 阶段由 P1 P2 主导Eng 阶段由 P5 P3 主导Design 阶段由 P5 P1 主导。决策分类与双声Dual Voices每个自动决策都被分类为Mechanical显然只有一个正确答案静默自动裁决、Taste合理的人会意见分歧自动裁决带推荐但上移到最终门、或User Challenge两个模型一致认为用户陈述的方向应当改变——这类永不自动裁决。每个阶段的评审都由「Codex Claude subagent」双声并行跑产出共识表consensus table这正是 Plan 档文档中「codex adversarial」的出处。Phase 0.5 还会做 Codex 认证与版本预检Codex 不可用时降级为仅 Claude 单声并在产物中标注。决策审计跟踪Decision Audit Trail每次自动裁决都以一行记录增量追加到计划文件## Decision Audit Trail表格Phase / Decision / Classification / Principle / Rationale / Rejected让审计落在磁盘上而不是堆积在对话上下文里。Pre-Gate 校验与最终审批门进入最终门之前有一份按阶段划分的输出校验清单前提挑战、错误与救援登记表、失败模式登记表、「NOT in scope」章节、架构 ASCII 图、测试计划落盘产物、各阶段共识表等缺任何一项都要回补最终门呈现「计划摘要、决策统计、User Challenges、品味型选择、各评审得分、跨阶段主题、被推迟到 TODOS.md 的项、聚合后的实现任务列表」用户可在「按现状批准 / 带覆写批准 / 追问 / 修订 / 拒绝」五个选项中裁决。Codex 文件系统边界所有发给 Codex 的提示词都必须前缀一段边界指令禁止它读取或执行磁盘上的 SKILL.md 文件——防止 Codex 发现 gstack 技能定义后去执行其指令而不是评审计划。Step 4把最终评审过的计划落盘第四步是 Plan 档最具体的产物契约Save the final reviewed plan to a file the orchestrator can reference later. Write it to:plans/project-slug-plan-date.mdin the current repo. Include the design doc, all review decisions, and the implementation sequence.三个要点命名规范plans/project-slug-plan-date.md写在当前仓库内而不是~/.gstack/私有目录——这是有意为之计划要成为编排器之后可以引用、且团队可见的产物落在仓库里才能被 git 跟踪、被后续会话和队友读取内容下限文件必须同时包含设计文档来自 Step 2、全部评审决策来自 Step 3 的各阶段共识表与审计跟踪以及实现顺序implementation sequence即 /autoplan 最终门聚合出的任务列表。三者缺一落盘文件就无法支撑后续实现会话可引用性「a file the orchestrator can reference later」——文件路径本身就是下一步的交接句柄。Step 5向编排器回报四件事第五步规定了回报给编排器的四项固定内容计划文件路径Plan file path一段话总结设计内容以及关键决策one-paragraph summary of what was designed and the key decisions已接受的 scope 扩张列表List of accepted scope expansions, if any——对应 /autoplan 中「Boil lakes」原则自动批准的爆炸半径内扩张推荐下一步Recommended next step通常是派生一个新的 gstack-full 会话去实现。这四项回报与 docs/OPENCLAW.md 中对 Plan 档的描述一一对应「Report back: plan path, summary, key decisions, recommended next step」。三、两条硬约束只规划、不实现 编排器负责持久化模板最后两行是整个 Plan 档的护栏Do not implement anything. This is planning only. The orchestrator will persist the plan link to its own memory/knowledge store.第一行把 Plan 会话的输出边界钉死这个会话的交付物只有计划文件与回报任何代码实现都属于越界。这与它调用的两个技能的自约束是自洽的——/office-hours有 HARD GATE只产出设计文档/autoplan在 plan mode 下的唯一合法编辑就是写计划文件。第二行定义了跨系统责任边界计划链接的持久化不是 Claude Code 会话的职责而是编排器的职责。docs/OPENCLAW.md 进一步说明编排器把计划链接存进它自己的记忆存储brain repo、知识库或 AGENTS.md 中配置的任意存储「当用户准备好构建时派生一个指向已保存计划的 FULL 会话」。也就是说Plan 档刻意把「规划」与「实现」拆成两个生命周期独立的会话中间靠落盘的计划文件 编排器记忆解耦。四、与 gstack-lite / gstack-full 的对照三档模板的分工Plan 档模板与另外两份注入模板构成递进关系对照阅读能快速理解每档的边界模板档位内容交付物openclaw/gstack-lite-CLAUDE.mdMedium约 15 行的规划纪律改前必读每个文件、写 5 行计划what/why/files/test/risk、歧义裁决原则、完成前自审、完成报告直接完成的多文件修改openclaw/gstack-full-CLAUDE.mdFull完整功能流水线读 CLAUDE.md → /autoplan 评审方案 → 实现 → /ship 出 PR → 回报 PR URL 与决策带测试、changelog、版本号的 PRopenclaw/gstack-plan-CLAUDE.mdPlan全量评审关卡Full Review Gauntlet/office-hours → /autoplan → 落盘计划 → 回报计划文件 四项回报零实现gstack-full 的完整流水线为读 CLAUDE.md → 跑 /autoplan 评审方案 → 实现已批准的计划 → 跑 /ship 创建 PR → 回报 PR URL、交付内容与不确定项并且「在 PR 准备好评审之前不向人要输入」。可以看到 Plan 档恰好是 Full 档的「前置半场」Plan 会话把设计与评审做完并落盘Full 会话从「实现已批准的计划」开始两者共享同一套评审基础设施但生命周期分离。五、模板的生成与维护方式三份 CLAUDE.md 模板都不是手维护的终点。从源码结构看源模板位于 openclaw/templates/gstack-plan-CLAUDE.md以及 gstack-full、gstack-lite 对应文件openclaw/ 目录下的成品文件由生成管线产出docs/OPENCLAW.md 明确说明「所有产物都位于openclaw/目录由bun run gen:skill-docs --host openclaw生成」对 gstack 开发者而言./setup --host openclaw会输出这份集成文档OpenClaw 用户侧的安装路径则是告诉 OpenClaw agent 「install gstack for openclaw」agent 会依次完成——把 gstack-lite CLAUDE.md 装入编码会话模板、安装 4 个原生方法论技能、把分发路由加入 AGENTS.md、用一次测试派生验证派生会话检测当 Claude Code 运行在 OpenClaw 派生的会话中时OPENCLAW_SESSION环境变量会被设置在 sessions_spawn 中通过env: { OPENCLAW_SESSION: 1 }传入。gstack 检测到它后自动调整行为跳过交互式提示自动选择推荐项、跳过升级检查与遥测提示、聚焦任务完成与文字回报——这正是 Plan 档能在无人值守的派生会话中端到端跑完的前提。office-hours/SKILL.md 的前置脚本中就有[ -n $OPENCLAW_SESSION ] echo SPAWNED_SESSION: true的检测逻辑。此外docs/OPENCLAW.md 还列出了「我们不做的事」清单划清了这条轻量协议的边界不做分发守护进程ACP 负责派生、不做 Clawvisor 中继、不做双向 learnings 桥brain repo 即知识存储、不做 JSON schema 或协议版本化、不从 gstack 输出 SOUL.md、不做完整技能移植编码技能保持 Claude Code 原生。六、小结Plan 档的完整数据流把以上证据串起来gstack-plan 档端到端的数据流是触发用户在 Telegram/聊天中说「帮我规划一个项目」OpenClaw 编排器按决策启发式判定为 Plan 档派生sessions_spawn(runtime: acp)prompt 为 gstack-plan 模板全文 任务描述环境带OPENCLAW_SESSION: 1注入模板追加到目标仓库 CLAUDE.md已有内容保留执行Claude Code 读 CLAUDE.md →/office-hours产出含问题陈述、前提、备选方案的设计文档HARD GATE不写代码→/autoplan以 CEO/Design/Eng/DX 串行阶段 Codex/Claude 双声做全量评审中间问题由 6 决策原则自动裁决品味型决策与 User Challenge 上移到最终门落盘评审过的最终计划写入仓库内plans/project-slug-plan-date.md含设计文档、全部评审决策、实现顺序回报会话回报计划路径、一段话总结、已接受的 scope 扩张、推荐下一步持久化编排器把计划链接存入自己的记忆/知识存储交接用户准备实现时编排器派生一个新的Full档会话注入 gstack-full指向已保存的计划执行「/autoplan增量→ 实现 → /ship」形成 Plan → Full 的两段式闭环。整套设计的核心取舍是用「会话拆分 磁盘计划文件 编排器记忆」替代了任何守护进程、协议版本化或双向同步机制提示词文本即协议git 仓库即交接介质五档路由即复杂度分级。对想在 OpenClaw或任何 ACP 风格编排器上复用 gstack 规划纪律的开发者openclaw/agents-gstack-section.md 中「Copy it into your OpenClaw AGENTS.md」的即用片段与本文所述的五档契约就是全部需要接入的内容。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
