gstack-full Pipeline：gstack 面向 OpenClaw 的完整特性构建模板，从 /autoplan 评审到 /ship 交付 PR

gstack-full 是 gstack 为 OpenClaw 编排器准备的"Full 层级"注入模板，用于在自动生成的 Claude Code 会话中执行一次完整的特性构建：先理解项目上下文，再跑完整评审管线，然后实现、交付 PR 并向编排器汇报。读完本文，你将理解该模板五步流水线的每一步在做什么、它在 gstack 的 OpenClaw 集成架构中处于什么位置，以及"PR 就绪前不打扰人类"这条纪律背后的实现依据。

模板的定位：编排器注入的 Full 层级流水线

openclaw/templates/gstack-full-CLAUDE.md 是 gstack 仓库中面向 OpenClaw 的三份注入模板之一，文件开头两行就交代了它的运行方式：

Injected by the orchestrator for complete feature builds. Append to existing CLAUDE.md.

即：当 OpenClaw 的编排器判定用户请求属于"完整特性构建"时，会把这份模板的全文拼接到 spawn 出去的 Claude Code 会话的 prompt 前缀中（并追加到该仓库已有的 CLAUDE.md 语境里）。docs/OPENCLAW.md 明确说明 gstack 与 OpenClaw 的集成方式是"作为方法论来源，而非移植代码库"——没有守护进程、没有 JSON-RPC，"prompt 就是桥"。在分发路由表中，Full 层级的定义是：

层级	适用场景	Prompt 前缀
Full	完整特性、目标、项目（而非单一任务）	追加 gstack-full 流水线

与它并列的另外两个模板分别是 gstack-lite-CLAUDE.md（Medium 层级，约 15 行的规划纪律）和 gstack-plan-CLAUDE.md（Plan 层级，只做规划不实现）。gstack-full 介于两者之上：lite 只约束"怎么干活"，gstack-plan 只产出计划文件，而 gstack-full 是"从评审到交付 PR"的端到端闭环。

Full 流水线五步：逐条拆解

模板的核心内容是 ## Full Pipeline 一节，共五步加一条收尾纪律。原文步骤如下，下面逐步展开每一步在 gstack 侧对应的真实能力。

第 1 步：读取 CLAUDE.md，理解项目上下文

1. Read CLAUDE.md and understand the project context.

这一步要求会话先加载目标仓库的项目说明，而不是直接开写。由于模板明确"Append to existing CLAUDE.md"，这一步实际同时覆盖了两层上下文：目标仓库既有的项目指令 + 新追加的 gstack-full 流水线要求。docs/OPENCLAW.md 的 "CLAUDE.md collision handling" 一节强调：在已有 CLAUDE.md 的仓库中 spawn 会话时，gstack-lite/full 必须以新 section 追加，不得替换仓库既有指令。这是该模板能安全注入任意第三方仓库的前提。

第 2 步：运行 /autoplan 做三视角评审

2. Run /autoplan to review your approach (CEO + eng + design review pipeline).

/autoplan 是 gstack 的自动评审管线：它从磁盘读取完整的 CEO、design、eng（以及 DX）评审技能并顺序执行，用 6 条决策原则做自动决策，把品味类决策（接近的方案取舍、边界模糊的范围、跨模型分歧）留到最终审批关口。其 frontmatter 中的描述可作佐证：

Auto-review pipeline — reads the full CEO, design, eng, and DX review skills from disk and runs them sequentially with auto-decisions using 6 decision principles. (gstack)

对 gstack-full 会话而言，这一步的意义是把"CEO 会反对什么、工程师认为哪里有风险、设计师觉得哪里不对"在动手写代码之前全部暴露出来，产出一份经过多视角挑战的批准计划。

第 3 步：实现已批准的计划

3. Implement the approved plan. Follow the planning discipline above.

"Follow the planning discipline above" 指的是模板注入时与 gstack-lite 共享的规划纪律（先读后要修改的文件、写代码前陈述计划、歧义时偏好完整性/既有模式/可逆选择、交付前自我复查）。也就是说 gstack-full 会话不是"裸奔"实现，而是带着 lite 层级的纪律约束去执行 autoplan 批准的计划。

第 4 步：运行 /ship 创建 PR

4. Run /ship to create a PR with tests, changelog, and version bump.

/ship 的 frontmatter 描述完整覆盖这一步的承诺：

Ship workflow: detect + merge base branch, run tests, review diff, bump VERSION, update CHANGELOG, commit, push, create PR. (gstack)

即 /ship 不只是 git push：它包含检测并合并基础分支、跑测试、review diff、更新 VERSION 文件、写 CHANGELOG、提交、推送、创建 PR 的完整交付序列。模板中"with tests, changelog, and version bump"正是对这三项交付物的显式要求，保证 PR 到达评审者时是完整可合的。

第 5 步：向编排器汇报

5. Report back: PR URL, what shipped, decisions made, anything uncertain.

汇报格式是固定的四要素：PR 地址、交付了什么、做了哪些决策、有什么不确定的地方。OpenClaw 的派发规则 openclaw/agents-gstack-section.md 对 FULL 层级有对应的闭环约定：

**FULL:** build a complete feature, multi-day scope, needs planning + review
→ sessions_spawn(runtime: "acp", prompt: "<gstack-full content>\n\n<task>")
  Claude Code runs: /autoplan → implement → /ship → report back

即编排器 spawn 会话后，Claude Code 按 /autoplan → implement → /ship → report back 执行，结果回到 Telegram 等聊天界面，"用户永远不必离开 Telegram"。

收尾纪律：PR 就绪前不打扰人类

模板最后一行：

Do not ask for human input until the PR is ready for review.

这条纪律之所以能成立，依赖 gstack 对"被 spawn 的会话"的运行时检测。当 Claude Code 运行在 OpenClaw spawn 的会话内时，应设置 OPENCLAW_SESSION 环境变量，gstack 检测到后会：跳过交互式提问（自动选择推荐选项）、跳过升级检查和遥测提问、聚焦于完成任务和散文式汇报。这在 /ship 的前置脚本中可以直接看到（ship/SKILL.md 的 Preamble 段）：

[ -n "$OPENCLAW_SESSION" ] && echo "SPAWNED_SESSION: true" || true

同理，/autoplan 的 AskUserQuestion 处理逻辑中，SESSION_KIND 为 spawned 时"自动选择推荐选项，绝不阻塞"。因此 gstack-full 的"不打扰"不是靠 LLM 自觉，而是由 gstack 的技能层面对 spawned 会话的行为改写兜底的。docs/OPENCLAW.md 给出的配置方式为在 sessions_spawn 中传 env: { OPENCLAW_SESSION: "1" }。

模板如何被生成与维护

openclaw/ 目录下的产物（包括 openclaw/gstack-full-CLAUDE.md 与模板目录中的同名文件）由命令 bun run gen:skill-docs --host openclaw 生成，docs/OPENCLAW.md 的 "What gstack generates for OpenClaw" 一节列出了全部生成物。gstack-full 在其中被概括为"chain 现有 gstack 技能"的产物：读 CLAUDE.md → /autoplan（CEO + eng + design 评审）→ 实现 → /ship 创建 PR → 带 PR URL 和决策汇报。

从源码结构看，OpenClaw 作为一个宿主（host）在 hosts/openclaw.ts 中定义，其中一项关键配置是把 CLAUDE.md 引用重写为 AGENTS.md（extraPathRewrites: [{ from: 'CLAUDE.md', to: 'AGENTS.md' }]），并抑制 Claude 专属的前置说明段（suppressedResolvers）。可以推断，生成 OpenClaw 变体的技能文档时，宿主差异（指令文件名、前言行文、Co-Authored-By 署名 OpenClaw Agent <[e-mail]>）都在这层 host 定义中统一处理，而模板本身的五步流水线内容保持稳定。

何时选择 gstack-full：决策启发式

openclaw/agents-gstack-section.md 给出了编排器选择派发层级的完整启发式，其中落到 FULL 的判断是：

• 能 10 行以内改完？→ SIMPLE
• 动多个文件但路径显而易见？→ MEDIUM
• 用户点名了某个 gstack 技能（/cso、/review、/qa）？→ HEAVY
• 它是个特性、项目或目标（而非一个任务）？→ FULL
• 用户想先规划、暂不实现？→ PLAN

也就是说 gstack-full 的触发条件不是代码量大小，而是"目标级"工作：需要规划、需要评审、需要交付 PR 的完整特性构建。对应的 spawn 调用形态是 sessions_spawn(runtime: "acp", prompt: "<gstack-full content>\n\n<task>")——把模板全文作为前缀塞进 prompt。

小结

gstack-full 模板本身只有十几行，但它把 gstack 的两件重型武器（/autoplan 多视角评审、/ship 完整交付序列）串成了一条无人值守的特性构建流水线，并用 OPENCLAW_SESSION 检测机制让"PR 就绪前不打扰人类"成为可强制执行的纪律。对使用 OpenClaw 的开发者，它的价值在于：Telegram 里下达一个特性目标后，编排器 spawn 一个带该模板的 Claude Code 会话，等来的就是一张带 URL、决策记录和不确定点清单的 PR——这正是 gstack"prompt 即协议"集成哲学的典型落点。