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-doneGSD这套基于 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是其中承上启下的一档模式讨论环节讨论之后适用场景默认无标志完全交互式每次一个问题的多轮问答停留在confirm_creation给出人工下一步用户想逐步掌控每个决策--chain完全交互式与默认模式完全相同自动推进 plan-phase → execute-phase用户掌控讨论决策但计划和执行全自动--auto全自动Claude 直接选推荐项不用 AskUserQuestion自动推进 plan-phase → execute-phase需要整条链路无人值守chain.md的开头明确概括了--chain的 EffectDiscussion 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_areasfor each discussion question, choose the recommended option without using AskUserQuestion而--chain完整保留交互问答两者的下游自动推进行为完全一致这也是为什么二者共享同一个auto_advance实现。父流程 discuss-phase.md 的成功标准success_criteria也直接对这两个模式作出了验收约束--chaintriggers interactive discuss followed by auto planexecute (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 parentsauto_advancestep needs to dispatch to plan-phase under--auto.这是 GSD 工作流架构中的一个刻意设计父文件 discuss-phase.md 的progressive_disclosure章节维护了一张何时读取哪个模式文件的查表条件$ARGUMENTS 或配置需要读取的文件--auto存在modes/auto.mdmodes/chain.md自动推进--chain存在modes/default.mdmodes/chain.md--power存在modes/power.md读后退出标准流程--text或workflow.text_mode: truemodes/text.md叠加层--batchmodes/batch.md叠加层--analyzemodes/analyze.md叠加层ADVISOR_MODE true存在 USER-PROFILE.mdmodes/advisor.md无任何标志modes/default.md这种懒加载的动机在注释中写得很清楚让父文件保持在 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用户的持久化设置偏好。二者的区别配置键类型默认值含义workflow.auto_advancebooleanfalse用户持久化的自动推进偏好见 planning-config.md 配置表workflow._auto_chain_activebooleanfalse内部运行态字段跟踪自主链路是否正在激活从配置表 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_advanceconfig-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、sourcenone/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(skillgsd-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-phaseSkill(skillgsd-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(skillgsd-ui-phase, args${PHASE} --auto ${GSD_WS})保证无人值守时前端阶段也不会卡在交互门控上。步骤 6处理 plan-phase 的返回状态Skill(skillgsd-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 aftercross_reference_todos自动折叠相关度 ≥ 0.4 的 todopresent_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 absentplan-phase 在自动推进前必须持久化链标志config-set workflow._auto_chain_active trueplan-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.tsauto_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的最典型使用场景是决策已清晰、执行可放手你产品负责人对当前阶段的做法已有明确想法希望把做什么亲自敲定但把怎么做计划、怎么写代码、怎么验证交给 GSD 全自动跑完。从--auto链路降级恢复中断的--auto链路残留了_auto_chain_active: true手动调用--chain同样会被识别并继续自动推进。作为持久化偏好的补充即使不传任何标志只要配置中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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
