GSD `--text` 模式深度解析：在 Claude Code 远程会话中让 discuss-phase 告别 TUI 菜单

GSD--text模式深度解析在 Claude Code 远程会话中让 discuss-phase 告别 TUI 菜单【免费下载链接】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导读--text模式是 get-shit-doneGSDdiscuss-phase 工作流中的一个纯文本渲染层plain-text overlay当该模式激活时工作流完全放弃 AskUserQuestion 交互式菜单改为输出带编号的纯文本问题列表让用户直接输入选项编号或用自由文本作答。它专为 Claude Code 远程会话/rc模式设计——因为 Claude App 无法把 TUI 菜单选择转发回宿主机。读完本文你将掌握--text模式的激活方式、问题渲染规范、回答解析逻辑、空回答兜底规则以及与--batch、--analyze等 overlay 的组合顺序。什么是--text模式一个懒加载的渲染层在 GSD 的架构里discuss-phase 的交互式提问默认依赖 Claude Code 的AskUserQuestion工具TUI 菜单。但在某些运行环境中这个菜单无法正常工作——最典型的场景就是 Claude Code 远程会话/rc模式Claude App 无法把 TUI 菜单中的选项选择转发回宿主机导致交互中断。--text模式正是为这种场景设计的替代渲染层。它定义在 modes/text.md按照 GSD 工作流的渐进式披露progressive disclosure设计原则懒加载仅当$ARGUMENTS中出现--text、或配置中设置了workflow.text_mode: true时才从父文件 workflows/discuss-phase.md 读取该文件。这个设计不是为了省事而是有硬性约束discuss-phase 的父工作流文件被限制在 500 行以内的预算对应仓库测试 workflow-size-budget.test.cjs 的 enforcementissue #2551。所有模式子文件、模板和 advisor 流程都懒加载父文件只保留分发逻辑。在 workflows/discuss-phase.md 的progressive_disclosure表中--text的分发条件与--power、--all、--auto、--chain、--batch、--analyze、ADVISOR_MODE 并列且明确写着不要读取模式文件除非对应 flag/条件已设置。核心效果当 text mode 激活时规则只有一个且非常严格完全不调用 AskUserQuestion 工具每个问题都以纯文本编号列表呈现请用户输入选项编号自由文本输入用户不选编号直接打字映射到等价 AskUserQuestion 调用的 Other 分支。激活方式会话级 flag 与项目级配置--text模式有两种激活途径二者等价且都是幂等的——一旦激活作用于当前会话中的所有工作流而不只是 discuss-phase。方式一会话级--textflag临时在任意命令后追加--text参数即可/gsd:discuss-phase --text从源码结构看该 flag 通过$ARGUMENTS传入工作流。父文件 workflows/discuss-phase.md 的initialize步骤中模式分发逻辑按固定顺序检查各 flag--power→--all→--auto→--chain→--text→--batch→--analyze→ ADVISOR_MODE → 默认命中--text时执行Read(workflows/discuss-phase/modes/text.md)并要求在任何 AskUserQuestion 调用之前完成读取。方式二项目级workflow.text_mode配置持久通过 GSD SDK 的配置命令设为项目默认gsd-sdk query config-set workflow.text_mode true该配置项的定义可在 references/planning-config.md 的完整字段参考表中查到配置键类型默认值允许值说明workflow.text_modebooleanfalsetrue/false用纯文本编号列表替代 AskUserQuestion 菜单配置默认值在 bin/lib/config.cjs 的硬编码默认配置对象中workflow.text_mode: false属于workflow.*命名空间。配置读取后会在 bin/lib/init.cjs 的initialize结果中随 JSON 一并下发text_mode: config.text_mode工作流无需再单独调用 config-get从而避免在某些模型如 Kimi K2.5见 issue #2192上因配置读取循环导致的死循环问题。注意workflow.text_mode是全局会话级开关。设置后当前会话里所有涉及 AskUserQuestion 的工作流discuss-phase、plan-phase、new-project、profile-user、execute-phase、ui-phase 等都会改为纯文本渲染而不只是 discuss-phase。如果你只想对单个命令生效用--textflag 更精准。问题渲染规范从 AskUserQuestion 到编号列表--text模式给出了明确的渲染替换规则。原 AskUserQuestion 写法AskUserQuestion( headerLayout, questionHow should posts be displayed?, options[Cards, List, Timeline] )在 text mode 下必须替换为如下纯文本形式Layout — How should posts be displayed? 1. Cards 2. List 3. Timeline 4. Other (type freeform) Reply with a number, or describe your preference.这个格式有几个值得注意的要点header 与 question 合并为一行用—分隔保留原语义选项保持原有顺序编号1.、2.、3.…末尾自动追加Other (type freeform)选项对应 AskUserQuestion 工具自动添加的 Other 分支默认模式的文档同样注明 AskUserQuestion adds Other automatically见 modes/default.md以明确的引导句收尾Reply with a number, or describe your preference.降低用户认知负担。与默认模式的本质区别默认交互模式见 modes/default.md每个 area 使用 4 轮 AskUserQuestion 单问题回合每轮通过 TUI 菜单选择且 header 有12 字符硬上限这个限制在 references/questioning.md 的using_askuserquestion一节有说明Headers longer than 12 characters (hard limit — validation will reject them)。text mode 则完全绕开这些 TUI 约束用编号列表等价承载同样的信息——选项质量要求具体而非抽象、Cards 而非 Option A在两个模式下保持一致。回答解析编号映射与自由文本回显渲染问题后工作流在正常提示符处等待用户回复然后按下述规则解析数字回复→ 直接映射到对应编号的选项自由文本→ 视为选择了 Other 分支。处理方式与默认模式下的 freeform 规则一脉相承把用户输入原样反映回去reflect it back、请求确认确认后再继续后续问题流。自由文本路径对应的正是 references/questioning.md 中freeform_rule的核心思想当用户想用自己的话描述时停止结构化提问改用普通文本跟进处理完自由文本后再恢复结构化提问。在 text mode 下由于本来就没有 AskUserQuestion这个规则自然收敛为把自由文本当作 Other 分支处理并回显确认。需要强调的是text mode 不会改变问题的内容质量只改变渲染通道。父文件 workflows/discuss-phase.md 中定义的通用规则universal rules依然全部生效包括用户回答中引用文档/spec/ADR 时立即读取并加入 canonical refs 累加器scope creep 记入 deferred ideas每个 area 完成后写增量 checkpoint${phase_dir}/${padded_phase}-DISCUSS-CHECKPOINT.jsonschema 见 templates/checkpoint.json讨论过程累计到 DISCUSSION-LOG 供git_commit步骤生成讨论日志。空回答处理与父文件一致的兜底链text mode 不放松任何校验。父文件 workflows/discuss-phase.md 的answer_validation节对所有模式统一适用text mode 完整继承Other 且内容为空用户想打字但没打→ 输出What would you like to discuss?停止生成、不重试 AskUserQuestion、不调用任何工具等待用户下一条消息回显后继续其他任何空回复→ 以相同参数重试一次仍为空则把选项降级为纯文本编号列表呈现绝不允许带着空输入继续推进流程Never proceed with empty input。之所以强调最后一条是因为 discuss-phase 的产出CONTEXT.md会直接喂给下游的 gsd-phase-researcher 和 gsd-planner——空输入产生的模糊决策会让下游每个阶段都靠猜代价会复利式放大references/questioning.md 对此有明确论述A vague PROJECT.md forces every downstream phase to guess. The cost compounds.。与其他模式叠加固定的--analyze → --batch → --text顺序text mode 本质上是一个渲染 overlay可以与默认模式及--all、--chain、--auto等模式组合。父文件的discuss_areas步骤给出了明确的叠加规则overlays combine and apply outer→inner in fixed order--analyze→--batch→--text例如--batch --analyze 每个问题组配权衡表再加--text则用纯文本渲染。叠加的语义参考 modes/batch.md 与--analyze模式文件--batch把每个 area 的提问从默认 4 轮单问题改为单轮 2–5 个编号问题支持--batch、--batchN、--batch N三种写法显式尺寸钳制在 2–5 之间。batch 模式本身就使用纯文本编号列表Authentication — please answer 1–4:因此与--text叠加时渲染规则天然一致--analyze每个问题前插入权衡分析表叠加时先应用--analyze的权衡表再套用--batch的分组最后由--text兜底为纯文本渲染最终呈现给用户的始终是带权衡表的分组编号问题列表。源码验证与适用前提总结一下与--text模式直接相关的仓库证据链关注点位置说明模式定义本体modes/text.md渲染规则、激活条件、解析逻辑模式分发逻辑workflows/discuss-phase.mdprogressive_disclosure表与initialize步骤中的 flag 检查顺序配置项定义references/planning-config.mdworkflow.text_mode字段默认false配置默认值bin/lib/config.cjsworkflow.text_mode: false配置下发bin/lib/init.cjstext_mode: config.text_mode进入 init JSON叠加顺序workflows/discuss-phase.md 的discuss_areas步骤--analyze → --batch → --text空回答规则workflows/discuss-phase.md 的answer_validation节所有模式统一适用提问质量规范references/questioning.mdheader 12 字符上限、freeform 规则、反模式清单适用前提与边界--text模式必须在 AskUserQuestion 不可用或不可靠的环境中使用典型场景是 Claude Code 远程会话/rc模式。在本地完整 TUI 环境下默认模式与 AskUserQuestion 即可正常工作无需此模式该模式只改变交互通道不改变决策语义选项内容、freeform 分支、空回答校验、checkpoint、canonical refs 累积等逻辑全部原样保留配置项workflow.text_mode是项目级持久开关会作用于会话内所有工作流如需临时使用优先选择--textflag。理解了这些规则你就能在远程会话中流畅地完成 discuss-phase 的灰区决策讨论并将结构化的 CONTEXT.md 决策安全地传递给下游的 researcher 与 planner。【免费下载链接】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），仅供参考