GSD --chain 模式全解：交互式讨论后自动推进 plan→execute 的中间态流水线

GSD --chain 模式全解：交互式讨论后自动推进 plan→execute 的中间态流水线

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

导读

在 get-shit-done（GSD）这套基于 Claude Code 的规格驱动开发系统中，discuss-phase的--chain模式提供了一条介于"全人工"与"全自动"之间的折中流水线：讨论环节完全交互式（提问、灰色地带选择、追问与默认模式行为完全一致），讨论结束后自动推进到 plan-phase 再到 execute-phase（下游行为与--auto一致）。读完本文你将掌握--chain的触发条件、auto_advance步骤的完整执行序列、链标志在配置中的持久化机制，以及它与--auto、--all等模式的关键区别——这些内容全部有源码与测试用例支撑，可直接用于日常提交流程编排。

--chain模式的完整定义位于 get-shit-done/workflows/discuss-phase/modes/chain.md，其父流程为 get-shit-done/workflows/discuss-phase.md。

一、模式定位：讨论阶段的三档自动化梯度

discuss-phase 的所有模式文件都集中在get-shit-done/workflows/discuss-phase/modes/目录下。--chain是其中承上启下的一档：

chain.md的开头明确概括了--chain的 Effect：

• Discussion isfully interactive— questions, gray-area selection, and follow-ups behave exactly the same as default mode.
• After discussion completes,auto-advance to plan-phase → execute-phase(same downstream behavior as--auto).
• This is the middle ground: the user controls the discuss decisions, then plan and execute run autonomously.

也就是说，--chain与--auto的区别只发生在讨论环节：--auto会跳过交互（参见 modes/auto.md 中的 "discuss_areas：for each discussion question, choose the recommended option without using AskUserQuestion"），而--chain完整保留交互问答；两者的下游自动推进行为完全一致，这也是为什么二者共享同一个auto_advance实现。

父流程 discuss-phase.md 的成功标准（<success_criteria>）也直接对这两个模式作出了验收约束：

• --chaintriggers interactive discuss followed by auto plan+execute (no auto-answering)
• --chainand--autoboth persist chain flag and auto-advance to plan-phase

这两条验收标准在后面的测试章节有对应的自动化断言。

二、Lazy-loaded 加载机制：chain.md 为何被延迟读取

chain.md文件头部标注了 "Lazy-loaded.Read this file fromworkflows/discuss-phase.mdwhen--chainis present in$ARGUMENTS, or when the parent'sauto_advancestep needs to dispatch to plan-phase under--auto."

这是 GSD 工作流架构中的一个刻意设计：父文件 discuss-phase.md 的<progressive_disclosure>章节维护了一张"何时读取哪个模式文件"的查表：

这种懒加载的动机在注释中写得很清楚：让父文件保持在 500 行工作流预算之内（issue #2551，镜像了 #2361 的 agent 预算约束）。从源码结构看，对应的守门测试是tests/workflow-size-budget.test.cjs——discuss-phase.md 的成功标准中明确提到 "Per-mode bodies, templates, and advisor flow are lazy-loaded — parent stays under the workflow size budget enforced bytests/workflow-size-budget.test.cjs"。

同理，模式文件内部的变量替换也遵循懒加载：write_context步骤才读取 CONTEXT.md 模板、git_commit步骤才读取 DISCUSSION-LOG.md 模板。因此--chain模式运行时不读取其他模式文件，只加载default.md（交互行为基线）与chain.md（自动推进）。

三、auto_advance 步骤逐条拆解（父文件执行）

chain.md的主体是一个由父文件 discuss-phase.md 的auto_advance步骤（位于<process>末尾）触发的执行序列。父文件在该步骤中写明：

If--auto,--chain, orworkflow.auto_advanceis enabled, Read that file now and execute itsauto_advancestep (which handles flag-syncing, banner display, plan-phase Skill dispatch, and return-status branching).

也就是说：只要--auto、--chain或持久化配置workflow.auto_advance三者任一为真，都会读取并执行 chain.md 的 auto_advance 逻辑。下面逐条展开其 7 个步骤。

步骤 1：解析--auto与--chain标志（--all不是触发器）

从$ARGUMENTS中解析--auto和--chain。文档特别强调了一个易混淆点：

Note:--allis NOT an auto-advance trigger — it only affects area selection. A session with--allbut without--autoor--chainreturns to manual next-steps after discussion completes.

--all只影响"灰色地带选择"阶段（自动全选所有讨论区域，参见modes/all.md），它不会触发自动推进。如果用户只加了--all而没有--auto/--chain，讨论结束后仍会回到手动下一步（confirm_creation）。

步骤 2：链标志与意图同步（清除残留状态）

如果用户是手动调用（$ARGUMENTS中既无--auto也无--chain），则清除上一次被中断的--auto链路残留的临时链标志：

if [[ ! "$ARGUMENTS" =~ --auto ]] && [[ ! "$ARGUMENTS" =~ --chain ]]; then gsd-sdk query config-set workflow._auto_chain_active false || true fi

这里的关键语义是：它只清除workflow._auto_chain_active（临时运行态字段），绝不触碰workflow.auto_advance（用户的持久化设置偏好）。二者的区别：

从配置表 planning-config.md 可以看到workflow._auto_chain_active的官方描述为 "Internal: tracks whether autonomous chaining is active"。它之所以带下划线前缀，是因为它是内部状态而非用户可设置的合法配置项——测试 bug-2530-valid-config-keys.test.cjs 明确断言workflow._auto_chain_active不在VALID_CONFIG_KEYS中（"internal runtime state and must not be user-settable"），但同时被isValidConfigKey接受，因为工作流会通过config-set写入它（plan-phase、execute-phase、discuss-phase、transition 都会用到）。

步骤 3：读取合并后的自动模式状态

通过gsd-sdk query check auto-mode一次性读取合并结果：

AUTO_MODE=$(gsd-sdk query check auto-mode --pick active 2>/dev/null || echo "false")

active= 临时链标志OR用户持久化偏好。这一步的底层实现在 sdk/src/query/check-auto-mode.ts，它取代了过去"成对调用config-get workflow.auto_advance+config-get workflow._auto_chain_active"的做法（见sdk/src/query/QUERY-HANDLERS.md中check.auto-mode的说明）。源码中的合并逻辑：

export type AutoModeSource = 'auto_chain' | 'auto_advance' | 'both' | 'none'; function resolveSource(autoChainActive: boolean, autoAdvance: boolean) { if (autoChainActive && autoAdvance) return { active: true, source: 'both' }; if (autoChainActive) return { active: true, source: 'auto_chain' }; if (autoAdvance) return { active: true, source: 'auto_advance' }; return { active: false, source: 'none' }; }

返回的 JSON 包含active、source（none/auto_chain/auto_advance/both）、auto_chain_active与auto_advance四个字段；工作流常用--pick active或--pick auto_chain_active只取所需字段。配套单测见 check-auto-mode.test.ts。

步骤 4：持久化链标志

如果--auto或--chain标志存在 且AUTO_MODE尚不为 true：将链标志写入配置，以处理"绕过 new-project 直接使用"的场景：

gsd-sdk query config-set workflow._auto_chain_active true

这保证后续流程（如 plan-phase 第 15 步、execute-phase）即使没有原始参数也能感知到当前处于自动链路中。测试 chain-flag-plan-phase.test.cjs 的 "plan-phase persists chain flag to config before auto-advancing" 用例即断言 plan-phase 存在config-set workflow._auto_chain_active true这一行。

步骤 5：显示 banner 并启动 plan-phase

如果--auto标志存在 或--chain标志存在 或AUTO_MODE为 true：显示 banner 并启动 plan-phase：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► AUTO-ADVANCING TO PLAN ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Context captured. Launching plan-phase...

启动方式使用Skill 工具而非 Task 会话：

Skill(skill="gsd-plan-phase", args="${PHASE} --auto ${GSD_WS}")

文档给出的理由非常具体：避免嵌套 Task 会话——深层 agent 嵌套会导致运行时冻结（issue #686）。使用 Skill 保持自动推进链路扁平化：discuss、plan、execute 都运行在同一嵌套层级，而不是不断派生出越来越深的 Task agent。

这个设计在 plan-phase 侧有对称实现：plan-phase.md 第 15 步（Auto-Advance Check）以相同思路启动 execute-phase：

Skill(skill="gsd-execute-phase", args="${PHASE} --auto --no-transition ${GSD_WS}")

其中--no-transition让 execute-phase 在验证后返回状态而不是继续链式推进，从而保持链路扁平（flat），各阶段运行在同一嵌套层级。另外，plan-phase 的 UI 安全门（第 5.6 步）也会读取check auto-mode --pick auto_chain_active：若处于--chain/--auto链路中，会自动生成 UI-SPEC 而不提示（Skill(skill="gsd-ui-phase", args="${PHASE} --auto ${GSD_WS}")），保证无人值守时前端阶段也不会卡在交互门控上。

步骤 6：处理 plan-phase 的返回状态

Skill(skill="gsd-plan-phase", ...)返回后，根据状态分支处理：

① PHASE COMPLETE → 整条链路成功，显示完成横幅：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► PHASE ${PHASE} COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Auto-advance pipeline finished: discuss → plan → execute /clear then: Next: /gsd:discuss-phase ${NEXT_PHASE} ${WAS_CHAIN ? "--chain" : "--auto"} ${GSD_WS}

注意这里对下一个阶段使用的标志做了智能回传：如果当前链路是从--chain进入的，下一个阶段继续用--chain；否则用--auto。

② PLANNING COMPLETE → 计划完成但执行未完成，提供部分完成提示：

Auto-advance partial: Planning complete, execution did not finish. Continue: /gsd:execute-phase ${PHASE} ${GSD_WS}

③ PLANNING INCONCLUSIVE / CHECKPOINT → 停止链路（计划需要用户输入）：

Auto-advance stopped: Planning needs input. Continue: /gsd:plan-phase ${PHASE} ${GSD_WS}

④ GAPS FOUND → 停止链路（执行过程中发现缺口）：

Auto-advance stopped: Gaps found during execution. Continue: /gsd:plan-phase ${PHASE} --gaps ${GSD_WS}

步骤 7：兜底路由

如果--auto、--chain均不存在且配置也未启用：路由到confirm_creation步骤（现有行为——展示手动下一步），即讨论正常收尾、由用户决定是否继续。

四、与--auto的差异边界与组合规则

--chain与--auto共享 auto_advance，但讨论环节行为截然不同。对照 modes/auto.md 可以明确各自的边界：

• --auto的讨论环节：check_existing自动选 "Update it"/"Resume"/"Continue and replan after"；cross_reference_todos自动折叠相关度 ≥ 0.4 的 todo；present_gray_areas自动全选；discuss_areas对每个问题直接选推荐项（第一个选项或显式标记 "recommended" 的选项），完全不使用 AskUserQuestion，仅内联记录选择日志供审计。
• --chain的讨论环节：与默认模式完全一致——每个区域以 AskUserQuestion 逐题交互、可追加问题、可继续探索更多灰色地带，全部由用户拍板。

--auto还有一个硬性约束：单次通过上限（single-pass cap）。它从配置读取workflow.max_discuss_passes（默认 3），一旦写完成提交 CONTEXT.md 就立即进入 auto_advance，禁止回读自己的 CONTEXT.md 去"找缺口"形成自我喂养循环。

组合规则（定义在 auto.md 与 default.md 中）：

• --auto --text/--auto --batch：文本/批处理叠加层在 auto 模式下是 no-op（没有用户提示需要渲染）；
• --auto --analyze：权衡表仍可记录进审计轨迹，但选择仍走推荐项；
• --auto --power：--power优先（power 模式生成离线答题文件，与自主选择不兼容）；
• 叠加层按固定顺序 outer→inner 应用：--analyze→--batch→--text。

由于--chain的讨论环节就是默认交互流，--chain --text、--chain --batch、--chain --analyze等叠加层可以正常生效，不会出现 auto 模式下的 no-op 情况。

五、源码与测试层面的对称验证

--chain并非孤立设计，仓库中有完整的对称实现与自动化验证：

1. 标志清理守卫的对称性。chain-flag-plan-phase.test.cjs 专门验证了 #1620（讨论→计划→执行自动推进无需人工干预）的修复。它的三个核心断言：

• plan-phase 的守卫必须同时检查--auto和--chain两个标志（"The guard that clears _auto_chain_active must require BOTH flags to be absent"）；
• plan-phase 在自动推进前必须持久化链标志（config-set workflow._auto_chain_active true）；
• plan-phase 与 discuss-phase 使用相同的双标志守卫模式——测试会同时读取plan-phase.md和chain.md，若chain.md被误删（#2551 拆分后的回归），整个套件会直接失败（"Fail loudly if either source is missing"）。

2. 查询层合并语义。check-auto-mode的"任一为真即激活"语义与 execute-phase.md 保持一致（automation applies when either the ephemeral chain flag or the persistent user preference is true），相关实现见 check-auto-mode.ts 与 QUERY-HANDLERS.md。

3. init 数据冗余设计。plan-phase 第 15 步要求直接使用 INIT JSON 中已解析的auto_chain_active与auto_advance字段，不要重复发起config-get调用——注释明确警告："Issuing redundantconfig-getcalls for values already in INIT can cause infinite read loops on some runtimes." 对应的 init 实现见 sdk/src/query/init.ts（auto_chain_active: !!config.workflow._auto_chain_active），单测见 init.test.cjs 中 #2192 相关用例（默认 false、配置置 true 时正确反映）。

4. 检查点自动模式的联动。当workflow._auto_chain_active或workflow.auto_advance为 true 时，checkpoints.md 定义了自动模式对检查点的绕过规则：human-verify 自动批准、decision 自动选第一个选项，但human-action 仍会停止（认证门控无法自动化）。也就是说，--chain链路并非完全无人工介入——涉及真实操作的安全关口依然会停下来。

六、实战建议：什么时候用--chain

综合以上机制，--chain的最典型使用场景是：

1. 决策已清晰、执行可放手：你（产品负责人）对当前阶段的做法已有明确想法，希望把"做什么"亲自敲定，但把"怎么做计划、怎么写代码、怎么验证"交给 GSD 全自动跑完。
2. 从--auto链路降级恢复：中断的--auto链路残留了_auto_chain_active: true，手动调用--chain同样会被识别并继续自动推进。
3. 作为持久化偏好的补充：即使不传任何标志，只要配置中workflow.auto_advance: true，讨论结束后也会走同一条 auto_advance 逻辑——--chain标志提供的是"一次性、当前会话生效"的显式控制，不会改变用户的持久化设置。

启动方式示例（在 Claude Code 中）：

/gsd:discuss-phase 3 --chain

讨论全程交互进行；结束后 banner 提示 "AUTO-ADVANCING TO PLAN"，随后 plan-phase 与 execute-phase 依次自动执行。若计划阶段需要输入（INCONCLUSIVE / CHECKPOINT）或发现缺口（GAPS FOUND），链路会礼貌地停下来并给出对应的继续命令，不会无限自动下去——这正是"中间态"设计的价值：该你决定的时候，它把决定权还给你；不需要你的时候，它绝不打扰。

参考文件索引

• 模式主体：get-shit-done/workflows/discuss-phase/modes/chain.md
• 父工作流：get-shit-done/workflows/discuss-phase.md
• 对比模式：modes/auto.md、modes/default.md
• 配置表：get-shit-done/references/planning-config.md
• 查询实现：sdk/src/query/check-auto-mode.ts、sdk/src/query/init.ts
• 测试用例：tests/chain-flag-plan-phase.test.cjs、sdk/src/query/check-auto-mode.test.ts、tests/bug-2530-valid-config-keys.test.cjs
• 关联参考：get-shit-done/references/checkpoints.md

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done