get-shit-done 的 /gsd:autonomous 自治里程碑工作流一次跑完 Discuss → 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-doneget-shit-doneGSD是面向 Claude Code 的轻量级元提示、上下文工程与规格驱动开发系统。/gsd:autonomous是它的“自动驾驶”入口给定一个已初始化的里程碑自动对每个未完成阶段执行 discuss → plan → execute 三段式流水线并在全部阶段完成后自动触发 audit → complete → cleanup 的生命周期收尾。读完全文你将掌握该命令的四个参数--from/--to/--only/--interactive的用法与语义、每个阶段的验证路由规则passed / human_needed / gaps_found、可用的配置开关以及底层gsd-sdk query与 UI 安全门等源码实现从而能够在自己的项目中安全地运行并排障这条自治流水线。工作流定义位于 workflows/autonomous.md斜杠命令入口位于 commands/gsd/autonomous.md二者构成“命令壳 工作流本体”的分离结构命令 frontmatter 声明allowed-toolsRead/Write/Bash/Glob/Grep/AskUserQuestion/Agent与参数提示[--from N] [--to N] [--only N] [--interactive]并通过execution_context引用~/.claude/get-shit-done/workflows/autonomous.md安装路径与ui-brand.md品牌样式文件。自治模式的定位只为用户决策而暂停工作流的purpose明确了自治模式的核心契约驱动范围全部剩余阶段或用--from N/--to N指定区间或用--only N只跑单个阶段每阶段流水线discuss → plan → execute全部通过Skill()平铺调用flat invocations暂停条件仅在显式用户决策处暂停——灰区grey area方案接受、blocker 处理、验证请求动态感知每个阶段结束后重新读取 ROADMAP.md以捕获执行过程中动态插入的阶段如 5.1 这类十进制阶段。与execute-phase、quick等命令不同autonomous 模式会自动串联code review 与 fix 两个环节后者在别的命令里只作提示阶段流转也由它自身管理因此内部调用 execute-phase 时始终附带--no-transition。命令行参数解析--from/--to/--only/--interactive初始化步骤从$ARGUMENTS中解析四个标志。工作流原文给出的解析脚本如下支持十进制阶段号如--from 5.1FROM_PHASE if echo $ARGUMENTS | grep -qE \-\-from\s[0-9]; then FROM_PHASE$(echo $ARGUMENTS | grep -oE \-\-from\s[0-9]\.?[0-9]* | awk {print $2}) fi TO_PHASE if echo $ARGUMENTS | grep -qE \-\-to\s[0-9]; then TO_PHASE$(echo $ARGUMENTS | grep -oE \-\-to\s[0-9]\.?[0-9]* | awk {print $2}) fi ONLY_PHASE if echo $ARGUMENTS | grep -qE \-\-only\s[0-9]; then ONLY_PHASE$(echo $ARGUMENTS | grep -oE \-\-only\s[0-9]\.?[0-9]* | awk {print $2}) FROM_PHASE$ONLY_PHASE fi INTERACTIVE if echo $ARGUMENTS | grep -q \-\-interactive; then INTERACTIVEtrue fi各参数的语义与行为约束在文档success_criteria中逐条列出参数作用关键行为--from N从阶段 N 开始过滤掉number N的阶段数值比较支持十进制阶段号--to N跑到阶段 N 后停止过滤掉number N的阶段与--from组合可实现“从 M 跑到 N”部分完成时跳过 lifecycle停止时给出Resume with: /gsd:autonomous --from {下一个未完成阶段}提示--only N单阶段模式阶段列表最多含一个阶段若该阶段已完成则直接退出并提示完成后跳过 lifecycle不触发 audit/complete/cleanup干净退出--interactive交互式讨论 后台执行discuss 在主上下文内联运行真实提问、等待回答plan 与 execute 派发为后台 Agent支持流水线并行Phase N 后台构建的同时与用户讨论 Phase N1可与--from/--to/--only组合一个值得注意的实现细节--only N会同时把FROM_PHASE设为相同值这样无需新写一套过滤逻辑直接复用既有的 from 过滤即可保证“恰好只剩一个阶段”。第 1 步初始化与里程碑引导启动时通过里程碑级 init 引导运行时上下文INIT$(gsd-sdk query init.milestone-op) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi该查询返回 JSON需要解析的字段为milestone_version、milestone_name、phase_count、completed_phases、roadmap_exists、state_exists、commit_docs。两个前置检查roadmap_exists为 false → 报错 “No ROADMAP.md found. Run/gsd:new-milestonefirst.”state_exists为 false → 报错 “No STATE.md found. Run/gsd:new-milestonefirst.”即autonomous 依赖/gsd:new-milestone已经建立了.planning/ROADMAP.md与.planning/STATE.md这决定了它的适用前提项目已完成规划处于执行期。通过后显示启动横幅含里程碑版本与名称、阶段总数与已完成数以及各标志对应的提示行如Single phase mode: Phase ${ONLY_PHASE}、Mode: Interactive (discuss inline, planexecute in background)。从源码结构看init.milestone-op对应 SDK 的initMilestoneOp处理器见 sdk/src/query/init-workstream-milestone-op.test.ts。该测试文件覆盖了一个重要回归问题#3196workstream工作流分支解析——带--ws参数、.planning/active-workstream指针文件或GSD_WORKSTREAM环境变量时init 会读取.planning/workstreams/{ws}/ROADMAP.md而非根目录.planning/优先级为--ws标志 环境变量 active-workstream 文件。如果你在多 workstream 仓库里跑 autonomous这个解析链决定了它操作的是哪份 ROADMAP。第 2 步发现阶段Discover PhasesROADMAP$(gsd-sdk query roadmap.analyze)解析返回 JSON 的phases数组后按以下顺序做过滤与排序只保留未完成阶段disk_status ! complete或roadmap_complete false磁盘状态与 ROADMAP 标记双轨判断应用--from N丢弃number N的阶段数值比较正确处理 5.1 这类十进制阶段应用--to N丢弃number N的阶段应用--only N丢弃number ! N的阶段按number数值升序排序。空结果有三条干净的退出路径全部带提示语TO_PHASE已设且无剩余阶段 →All phases through ${TO_PHASE} are already completed. Nothing to do.ONLY_PHASE已设且无剩余阶段 →Phase ${ONLY_PHASE} is already complete. Nothing to do.过滤后完全无未完成阶段 → 显示AUTONOMOUS ▸ COMPLETE / All phases complete!横幅并退出。非空时显示“阶段计划表”## Phase Plan | # | Phase | Status | |---|-------|--------| | 5 | Skill Scaffolding Phase Discovery | In Progress | | 6 | Smart Discuss | Not Started | | 7 | Auto-Chain Refinements | Not Started | | 8 | Lifecycle Orchestration | Not Started |随后对每个阶段拉取详情备用在进度横幅与流转消息中DETAIL$(gsd-sdk query roadmap.get-phase ${PHASE_NUM})提取phase_name、goal、success_criteria字段。第 3 步执行单个阶段Execute Phase每个阶段开始时显示进度横幅GSD ► AUTONOMOUS ▸ Phase {N}/{T}: {Name} [████░░░░] {P}%这里的T 必须是phase_count本里程碑阶段总数而不是剩余阶段数——文档特别用“61–67 号阶段、跑到 63 时显示Phase 63/7而非Phase 63/3”举例说明。P 为已完成阶段占比最新roadmap analyze中disk_status为 complete 的阶段数 / T × 100进度条固定 8 格宽█ 满 / ░ 空。当多里程碑项目导致全局阶段号超过本里程碑阶段数N T时改用Phase {N} ({position}/{T})格式避免 “Phase 63/5” 这类误导性显示。单个阶段内部是一条 3a → 3a.5 → 3b → 3c → 3c.5 → 3d → 3d.5 的子步骤链。3a. Smart Discuss三档跳过的智能讨论先检查本阶段是否已有上下文PHASE_STATE$(gsd-sdk query init.phase-op ${PHASE_NUM}) # 解析 has_context三种情况依次判断has_context为 true→ 跳过 discuss显示Phase ${PHASE_NUM}: Context exists — skipping discuss.直接进入 3b。文档特别强调单遍约束--auto模式下 discuss 绝不允许循环has_context检查是权威判据——一旦为 true无论上下文文件看起来有无“缺口”该阶段的 discuss 都视为完成。workflow.skip_discuss为 true→ 完全跳过 discussROADMAP 阶段描述即规格。为让下游 plan-phase 有合法输入会写入一份最小化 CONTEXT.md含Phase Boundary ROADMAP 的 goalImplementation Decisions下只有一个 “Claudes Discretion” 小节Mode: Auto-generated (discuss skipped via workflow.skip_discuss)并提交gsd-sdk query commit docs(${PADDED_PHASE}): auto-generated context (discuss skipped) --files ${phase_dir}/${padded_phase}-CONTEXT.md默认skip_discuss 为 false 或未设→ 按--interactive分支interactive内联执行标准 discuss-phase skillSkill(skillgsd-discuss-phase, args${PHASE_NUM})真实提问并等待用户回答非 interactive默认执行 smart_discuss 步骤批量表格提案见下文专节。讨论完成后再次执行init phase-op校验has_context若仍为 false转入 handle_blocker“Discuss for phase N did not produce CONTEXT.md.”3a.5. UI 安全门前端阶段的 UI 设计契约这是流水线中一个容易忽略的“隐形分支”。判断当前阶段是否属于前端阶段PHASE_SECTION$(gsd-sdk query roadmap.get-phase ${PHASE_NUM} 2/dev/null) GSD_REPO_ROOT$(git rev-parse --show-toplevel 2/dev/null || echo .) printf %s $PHASE_SECTION | node ${GSD_REPO_ROOT}/bin/lib/ui-safety-gate.cjs /dev/null 21 HAS_UI$? UI_SPEC_FILE$(ls ${PHASE_DIR}/*-UI-SPEC.md 2/dev/null | head -1) UI_PHASE_CFG$(gsd-sdk query config-get workflow.ui_phase 2/dev/null || echo true)只有当HAS_UI为 0检出前端指示词且 UI-SPEC 尚不存在且workflow.ui_phase不为 false时才调用Skill(skillgsd-ui-phase, args${PHASE_NUM})生成 UI 设计契约并在之后重新检查*-UI-SPEC.md若仍为空显示警告 “UI-SPEC generation did not produce output — continuing without design contract” 并继续非阻塞。否则静默跳过。这一检测的实现是 bin/lib/ui-safety-gate.cjs值得作为源码级细节展开词表为 11 个 UI 指示词UI、interface、frontend、component、layout、page、screen、view、form、dashboard、widget采用 ASCII 词边界锚定(^|[^a-zA-Z0-9])(TOKEN)([^a-zA-Z0-9]|$)等价于 POSIX[^[:alnum:]]意图——micro-frontend、micro frontend会命中而复合词microfrontend不会误命中对应问题 #3718用 Node.js 实现而非 bash one-liner是因为后者在 Windows PowerShell/cmd.exe 下因 locale 环境变量前缀不被识别而静默失效对应 #3706CLI 从stdin读取阶段文本以规避操作系统 ARG_MAX 限制退出码对齐 grep 语义0 找到 UI 词1 未找到2 使用错误。3b. Plan交互式模式下的后台化非 interactive默认内联执行Skill(skillgsd-plan-phase, args${PHASE_NUM})interactive派发后台 Agent 以隔离主上下文Agent( descriptionPlan phase ${PHASE_NUM}: ${PHASE_NAME}, run_in_backgroundtrue, promptRun plan-phase for phase ${PHASE_NUM}: Skill(skill\gsd-plan-phase\, args\${PHASE_NUM}\) )记录 task_id在下一阶段讨论完成或没有下一阶段后等待该 Agent 结束才进入 execute。无论哪种模式plan 结束后都要重新执行init phase-op校验has_plans为 false 则走 handle_blocker“Plan phase N did not produce any plans.”3c. Execute始终带--no-transition非 interactiveSkill(skillgsd-execute-phase, args${PHASE_NUM} --no-transition)interactive先等待 plan Agent 完成并校验计划存在再派发后台 execute Agent同样带--no-transition。之所以禁用 transition是因为阶段间的状态流转由 autonomous 工作流自己统一管理。3c.5. 代码审查与自动修复链CODE_REVIEW_ENABLED$(gsd-sdk query config-get workflow.code_review 2/dev/null || echo true)配置为false→ 显示 “Code review skipped (workflow.code_reviewfalse)” 直接进入 3d否则调用Skill(skillgsd-code-review, args${PHASE_NUM})解析 REVIEW.md frontmatter 的 statusclean/skipped→ 进入 3d有 findings →自动续跑Skill(skillgsd-code-review, args${PHASE_NUM} --fix --auto)两个 Skill 中任一失败都只作非阻塞提示继续 3d。这正是文档中强调的差异点autonomous 模式自动串联 review 与 fix而 execute-phase/quick 只提示修复。3d. Post-Execution Routing按验证状态四路分派execute 返回后读取验证结果VERIFY_STATUS$(grep ^status: ${PHASE_DIR}/*-VERIFICATION.md 2/dev/null | head -1 | cut -d: -f2 | tr -d )PHASE_DIR来自 3a 的init phase-op返回值若变量不在作用域内则重新获取。四种状态的路由status行为空无 VERIFICATION.md 或无 status 字段走 handle_blocker“Execute phase N did not produce verification results.”passed显示Phase N ✅ {Name} — Verification passed直接进入 iteratehuman_needed读取 human_verification 条目询问 “Validate now” / “Continue without validation”前者再问 “All good — continue” / “Found issues”后者带用户报告的问题走 handle_blocker后者显示⏭ Human validation deferred并继续gaps_found显示缺口分数Score: {N}/{M} must-haves verified询问 “Run gap closure” / “Continue without fixing” / “Stop autonomous mode”gap closure 的防死循环设计选 “Run gap closure” 时执行一轮闭环上限 1 次——Skill(skillgsd-plan-phase, args${PHASE_NUM} --gaps) Skill(skillgsd-execute-phase, args${PHASE_NUM} --no-transition)重新读取 VERIFICATION.md 的 status若变passed/human_needed按正常路由若仍是gaps_found显示 “Gaps persist after closure attempt.” 并只给 “Continue anyway” / “Stop autonomous mode” 两个选项。这个单次自动重试上限是工作流明确声明的防无限循环机制。关于交互提问文档还定义了text mode若$ARGUMENTS含--text或 init JSON 的text_mode为 true所有AskUserQuestion调用都替换为“纯文本编号列表 用户输入序号”——这是非 Claude 运行时OpenAI Codex、Gemini CLI 等无AskUserQuestion工具的兼容路径。3d.5. UI Review前端阶段的评审审计UI_SPEC_FILE$(ls ${PHASE_DIR}/*-UI-SPEC.md 2/dev/null | head -1) UI_REVIEW_CFG$(gsd-sdk query config-get workflow.ui_review 2/dev/null || echo true)当存在 UI-SPEC 且workflow.ui_review不为 false 时调用Skill(skillgsd-ui-review, args${PHASE_NUM})显示 UI-REVIEW.md 的评分摘要。注意其定位UI review 是咨询性的advisory不阻塞——无论得分如何都继续进入 iterate。这与 3c.5 的 code review会触发自动修复形成对照。Smart Discuss 深潜批量灰区提案协议smart_discuss步骤的完整指令在 references/autonomous-smart-discuss.md是gsd-discuss-phase的“自治优化变体”以批量表格形式提出灰区答案用户按领域接受或覆盖最终写出与 discuss-phase完全相同结构的 CONTEXT.md。其内部子步骤加载既有上下文读.planning/PROJECT.md愿景/原则/不可妥协项、REQUIREMENTS.md验收标准/约束、STATE.md进度/既有决策并遍历所有早于当前阶段的*-CONTEXT.md抽取decisions已锁定偏好与specifics构建内部prior_decisions不落盘代码库侦察优先读.planning/codebase/*.mdCONVENTIONS/STRUCTURE/STACK没有才做定向 grepgrep -rl {term} src/ app/ ...读 3–5 个最相关文件构建内部codebase_context可复用资产 / 既有模式 / 集成点要求控制在约 5% 上下文以内基础设施检测在生成灰区之前先判断当目标关键词命中 scaffolding/plumbing/setup/configuration/migration/refactor/rename/restructure/upgrade/infrastructure、成功标准全是技术性的file exists/test passes/config valid/command runs且不描述任何用户可见行为时判定为纯基础设施阶段跳过提案直接写最小 CONTEXT.md生成灰区提案非基础设施阶段按领域类型用户 SEE → visual / CALL → interface / RUN → execution / READ → content / 被 ORGANIZED → organization生成3–4 个灰区、每区约 4 个问题每题预选推荐答案依据prior decisions 一致性、代码库模式、领域惯例、ROADMAP 成功标准外加 1–2 个备选并附注先前决策与代码上下文按区呈现一次一个区展示# | Question | ✅ Recommended | Alternative(s)表格用 AskUserQuestion 给出 “Accept all / Change Q1…QN / Discuss deeper”选项上限 6 个“Change QN” 时展开该题备选加 “You decide”映射到 Claudes Discretion修改后重显示表格并重新请求接受“Discuss deeper” 只对当前区切换交互式逐题问答。超范围诉求按 scope creep 话术记为 deferred idea写 CONTEXT.md落盘到${phase_dir}/${padded_phase}-CONTEXT.md严格使用domain/decisions/code_context/specifics/deferred五段结构与 discuss-phase 输出一致提交docs(${PADDED_PHASE}): smart discuss context并显示 “Decisions captured: {count} across {area_count} areas” 确认。这个协议的设计意图很清晰把“开放式对话”压缩成“可批量批准的表格”从而让自治流水线在保留用户对设计决策最终裁量权的同时把交互轮次压到每区常为一次按键。第 4 步Iterate —— 动态阶段捕获与流水线并行每个阶段完成后--only已设→ 不迭代直接进 lifecycle单阶段模式下 lifecycle 会干净退出--to N已设且当前阶段号 ≥ N→ 显示--to ${TO_PHASE} REACHED横幅含 “Completed through phase N as requested. Remaining phases were not executed.” 与Resume with: /gsd:autonomous --from ${next_incomplete_phase}直接进 lifecycle 处理“部分完成”跳过 audit/complete/cleanup否则→ 重新执行roadmap.analyze用与 discover 相同的过滤逻辑重建未完成列表这正是捕获执行期间插入的十进制阶段如 5.1的机制同时cat .planning/STATE.md检查 Blockers/Concerns 小节发现 blocker 即转 handle_blocker。interactive 模式的流水线并行是这里最精巧的部分Phase N 的 discuss 一结束就把 planexecute 派成后台 Agent主上下文立刻开始讨论 Phase N1但在为 N1 启动 plan 之前必须等待 N 的 execute Agent 完成并处理其执行后路由验证、gap 闭环等。净效果用户始终在做轻量的讨论回答而规划与代码生成在后台进行主上下文只累积 discuss 对话——plan 与 execute 的上下文完全隔离在各自 Agent 中。这对长里程碑的上下文预算context budget控制至关重要。第 5 步Lifecycle —— audit → complete → cleanup--only模式下跳过整个 lifecycle单阶段不触发收尾显示PHASE N COMPLETE ✓并提示 “run /gsd:autonomous without --only after all phases complete to trigger audit/complete/cleanup.”否则全部阶段完成后显示AUTONOMOUS ▸ LIFECYCLE过渡横幅“All phases complete → Starting lifecycle: audit → complete → cleanup”然后依次5a. AuditSkill(skillgsd-audit-milestone)随后解析审计结果AUDIT_FILE.planning/v${milestone_version}-MILESTONE-AUDIT.md AUDIT_STATUS$(grep ^status: ${AUDIT_FILE} 2/dev/null | head -1 | cut -d: -f2 | tr -d )status 为空文件缺失/无 status 字段→ handle_blockerpassed→ 自动进入 5b不打断用户文档标注 “per CTRL-01”即 CTRL-01 允许此类自动推进gaps_found→ 询问 “Continue anyway — accept gaps” / “Stop — fix gaps manually”停止时提示手动运行/gsd:audit-milestone与/gsd:complete-milestonetech_debt→ 展示技术债摘要后询问 “Continue with tech debt” / “Stop — address debt first”。5b. Complete MilestoneSkill(skillgsd-complete-milestone, args${milestone_version})并校验归档产物存在ls .planning/milestones/v${milestone_version}-ROADMAP.md不存在则走 handle_blocker。5c. CleanupSkill(skillgsd-cleanup)。清理本身带 dry-run 并在内部向用户征求删除批准——文档明确这属于 CTRL-01 允许的暂停因为这是关于文件删除的显式决策。5d. Final CompletionGSD ► AUTONOMOUS ▸ COMPLETE Milestone: {milestone_version} — {milestone_name} Status: Complete ✅ Lifecycle: audit ✅ → complete ✅ → cleanup ✅ Ship it! 第 6 步Handle Blocker —— 三选项兜底任何阶段操作失败或检测到 blocker 时通过 AskUserQuestion 呈现固定三选项“Phase {N} ({Name}) encountered an issue: {description}”Fix and retry— 重跑本阶段失败的步骤discuss/plan/execute 中的具体一步若重试后仍失败再次呈现这三个选项Skip this phase— 记录Phase {N} ⏭ {Name} — Skipped by user继续下一个未完成阶段Stop autonomous mode— 显示进度摘要Completed / Skipped / Remaining 三列清单并干净退出退出信息里自动生成恢复命令Resume with: /gsd:autonomous ${ONLY_PHASE ? --only ONLY_PHASE : --from next_phase}${TO_PHASE ? --to TO_PHASE : }注意该命令保留了原始标志组合--only优先于--from--to原样拼接使得中断后一条命令即可精确续跑。配置开关与默认值速查工作流内通过gsd-sdk query config-get workflow.key读取的配置项及其在流程中的作用配置键未设时的回退作用workflow.skip_discussfalsetrue 时跳过 discuss用 ROADMAP 阶段目标作规格并生成最小 CONTEXT.mdworkflow.ui_phasetrue控制前端阶段是否自动生成 UI-SPEC 设计契约workflow.ui_reviewtrue控制执行后是否运行 UI review 审计咨询性、非阻塞workflow.code_reviewtrue控制 3c.5 的自动 code review fix 链text_modeinit JSON /--text—非 Claude 运行时兼容AskUserQuestion 降级为纯文本编号选择在 SDK 的类型定义中WorkflowConfig接口声明了skip_discuss、ui_phase、text_mode等字段见 sdk/src/config.ts并且 SDK 还带有一个与自治讨论直接相关的参数max_discuss_passes“auto/headless 模式下强制推进前的最大自讨论轮数”默认 3——从字段注释看这是为自动模式下的 discuss 环节提供的额外防循环保险与 autonomous 工作流层面 “discuss must be single-pass” 的约束互为补充。与仓库测试体系的对应关系这条工作流的行为并非纸面契约仓库tests/目录下有一组直接以 autonomous 命名的回归测试文件覆盖了本文各节的参数行为与分支tests/autonomous-allowed-tools.test.cjs — 命令 frontmatter 的allowed-tools声明含 Agent 工具interactive 后台派发依赖它tests/autonomous-decomposition.test.cjs — 工作流分解/步骤结构tests/autonomous-interactive.test.cjs —--interactive的内联 discuss 与后台 plan/execute 派发tests/autonomous-to-flag.test.cjs —--to的停止、过滤与 resume 消息tests/autonomous-ui-steps.test.cjs — 3a.5 / 3d.5 两个 UI 分支。另有 tests/ui-safety-gate-false-positives.test.cjs 与tests/bug-3706*命名对应的 UI 词边界误报回归如microfrontend不应命中以及 tests/feat-3309-human-verify-mode.test.cjs 覆盖 human_needed 验证的两种模式mid-flight/end-of-phase——后者正是 3d 路由中 human_verification 段落的配置来源。成功标准工作流自身的验收清单workflows/autonomous.md末尾的success_criteria是工作流实现者的验收清单也是运行者排障时最完整的“应有行为”索引核心条目包括所有未完成阶段按序执行smart discuss → ui-phase → plan → execute → ui-review 各自就位execute-phase 一律带--no-transition验证路由读 VERIFICATION.md 的 statusgap closure 限 1 次自动重试plan/execute 失败必走 handle_blocker每阶段后重读 ROADMAP.md、每阶段前检查 STATE.md blockers--only跳过 lifecycle 且单阶段完成后干净退出--to在 iterate 处停下并在 resume 消息中保留自身标志--interactive的上下文隔离主上下文只累积 discuss 对话、后台 Agent 等待语义、流水线并行lifecycle 各环audit/complete/cleanup通过Skill()真实调用而非“建议用户手动运行”audit 的技术性失败无文件/无 status路由到 handle_blockerUI review 非阻塞、受workflow.ui_phase/workflow.ui_review双开关控制。小结/gsd:autonomous把 GSD 的“规划—执行—验证—收尾”全生命周期压成一条命令其工程要点可以归纳为五层参数层用四个标志控制驱动范围与交互形态发现层用roadmap.analyze的disk_status/roadmap_complete双轨状态加数值化阶段过滤天然兼容十进制插入阶段执行层把 discuss/plan/execute 串成可跳过的子步骤链并为前端阶段叠加 UI-SPEC 与 UI review 两条非阻塞支线路由层以 VERIFICATION.md 的passed/human_needed/gaps_found三态分派决策用单次 gap closure 重试上限杜绝死循环收尾层自动触发 audit → complete → cleanup并保留 CTRL-01 允许的用户决策暂停点。配合workflow.skip_discuss、workflow.ui_phase、workflow.ui_review、workflow.code_review、text_mode五个开关同一条流水线既可以以“全自治”方式无人值守跑完里程碑也可以切到--interactive模式让讨论始终留在人的手里。【免费下载链接】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），仅供参考 get-shit-done 的 /gsd:autonomous 自治里程碑工作流：一次跑完 Discuss → Plan → Execute 全链路
get-shit-done 的 /gsd:autonomous 自治里程碑工作流一次跑完 Discuss → 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-doneget-shit-doneGSD是面向 Claude Code 的轻量级元提示、上下文工程与规格驱动开发系统。/gsd:autonomous是它的“自动驾驶”入口给定一个已初始化的里程碑自动对每个未完成阶段执行 discuss → plan → execute 三段式流水线并在全部阶段完成后自动触发 audit → complete → cleanup 的生命周期收尾。读完全文你将掌握该命令的四个参数--from/--to/--only/--interactive的用法与语义、每个阶段的验证路由规则passed / human_needed / gaps_found、可用的配置开关以及底层gsd-sdk query与 UI 安全门等源码实现从而能够在自己的项目中安全地运行并排障这条自治流水线。工作流定义位于 workflows/autonomous.md斜杠命令入口位于 commands/gsd/autonomous.md二者构成“命令壳 工作流本体”的分离结构命令 frontmatter 声明allowed-toolsRead/Write/Bash/Glob/Grep/AskUserQuestion/Agent与参数提示[--from N] [--to N] [--only N] [--interactive]并通过execution_context引用~/.claude/get-shit-done/workflows/autonomous.md安装路径与ui-brand.md品牌样式文件。自治模式的定位只为用户决策而暂停工作流的purpose明确了自治模式的核心契约驱动范围全部剩余阶段或用--from N/--to N指定区间或用--only N只跑单个阶段每阶段流水线discuss → plan → execute全部通过Skill()平铺调用flat invocations暂停条件仅在显式用户决策处暂停——灰区grey area方案接受、blocker 处理、验证请求动态感知每个阶段结束后重新读取 ROADMAP.md以捕获执行过程中动态插入的阶段如 5.1 这类十进制阶段。与execute-phase、quick等命令不同autonomous 模式会自动串联code review 与 fix 两个环节后者在别的命令里只作提示阶段流转也由它自身管理因此内部调用 execute-phase 时始终附带--no-transition。命令行参数解析--from/--to/--only/--interactive初始化步骤从$ARGUMENTS中解析四个标志。工作流原文给出的解析脚本如下支持十进制阶段号如--from 5.1FROM_PHASE if echo $ARGUMENTS | grep -qE \-\-from\s[0-9]; then FROM_PHASE$(echo $ARGUMENTS | grep -oE \-\-from\s[0-9]\.?[0-9]* | awk {print $2}) fi TO_PHASE if echo $ARGUMENTS | grep -qE \-\-to\s[0-9]; then TO_PHASE$(echo $ARGUMENTS | grep -oE \-\-to\s[0-9]\.?[0-9]* | awk {print $2}) fi ONLY_PHASE if echo $ARGUMENTS | grep -qE \-\-only\s[0-9]; then ONLY_PHASE$(echo $ARGUMENTS | grep -oE \-\-only\s[0-9]\.?[0-9]* | awk {print $2}) FROM_PHASE$ONLY_PHASE fi INTERACTIVE if echo $ARGUMENTS | grep -q \-\-interactive; then INTERACTIVEtrue fi各参数的语义与行为约束在文档success_criteria中逐条列出参数作用关键行为--from N从阶段 N 开始过滤掉number N的阶段数值比较支持十进制阶段号--to N跑到阶段 N 后停止过滤掉number N的阶段与--from组合可实现“从 M 跑到 N”部分完成时跳过 lifecycle停止时给出Resume with: /gsd:autonomous --from {下一个未完成阶段}提示--only N单阶段模式阶段列表最多含一个阶段若该阶段已完成则直接退出并提示完成后跳过 lifecycle不触发 audit/complete/cleanup干净退出--interactive交互式讨论 后台执行discuss 在主上下文内联运行真实提问、等待回答plan 与 execute 派发为后台 Agent支持流水线并行Phase N 后台构建的同时与用户讨论 Phase N1可与--from/--to/--only组合一个值得注意的实现细节--only N会同时把FROM_PHASE设为相同值这样无需新写一套过滤逻辑直接复用既有的 from 过滤即可保证“恰好只剩一个阶段”。第 1 步初始化与里程碑引导启动时通过里程碑级 init 引导运行时上下文INIT$(gsd-sdk query init.milestone-op) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi该查询返回 JSON需要解析的字段为milestone_version、milestone_name、phase_count、completed_phases、roadmap_exists、state_exists、commit_docs。两个前置检查roadmap_exists为 false → 报错 “No ROADMAP.md found. Run/gsd:new-milestonefirst.”state_exists为 false → 报错 “No STATE.md found. Run/gsd:new-milestonefirst.”即autonomous 依赖/gsd:new-milestone已经建立了.planning/ROADMAP.md与.planning/STATE.md这决定了它的适用前提项目已完成规划处于执行期。通过后显示启动横幅含里程碑版本与名称、阶段总数与已完成数以及各标志对应的提示行如Single phase mode: Phase ${ONLY_PHASE}、Mode: Interactive (discuss inline, planexecute in background)。从源码结构看init.milestone-op对应 SDK 的initMilestoneOp处理器见 sdk/src/query/init-workstream-milestone-op.test.ts。该测试文件覆盖了一个重要回归问题#3196workstream工作流分支解析——带--ws参数、.planning/active-workstream指针文件或GSD_WORKSTREAM环境变量时init 会读取.planning/workstreams/{ws}/ROADMAP.md而非根目录.planning/优先级为--ws标志 环境变量 active-workstream 文件。如果你在多 workstream 仓库里跑 autonomous这个解析链决定了它操作的是哪份 ROADMAP。第 2 步发现阶段Discover PhasesROADMAP$(gsd-sdk query roadmap.analyze)解析返回 JSON 的phases数组后按以下顺序做过滤与排序只保留未完成阶段disk_status ! complete或roadmap_complete false磁盘状态与 ROADMAP 标记双轨判断应用--from N丢弃number N的阶段数值比较正确处理 5.1 这类十进制阶段应用--to N丢弃number N的阶段应用--only N丢弃number ! N的阶段按number数值升序排序。空结果有三条干净的退出路径全部带提示语TO_PHASE已设且无剩余阶段 →All phases through ${TO_PHASE} are already completed. Nothing to do.ONLY_PHASE已设且无剩余阶段 →Phase ${ONLY_PHASE} is already complete. Nothing to do.过滤后完全无未完成阶段 → 显示AUTONOMOUS ▸ COMPLETE / All phases complete!横幅并退出。非空时显示“阶段计划表”## Phase Plan | # | Phase | Status | |---|-------|--------| | 5 | Skill Scaffolding Phase Discovery | In Progress | | 6 | Smart Discuss | Not Started | | 7 | Auto-Chain Refinements | Not Started | | 8 | Lifecycle Orchestration | Not Started |随后对每个阶段拉取详情备用在进度横幅与流转消息中DETAIL$(gsd-sdk query roadmap.get-phase ${PHASE_NUM})提取phase_name、goal、success_criteria字段。第 3 步执行单个阶段Execute Phase每个阶段开始时显示进度横幅GSD ► AUTONOMOUS ▸ Phase {N}/{T}: {Name} [████░░░░] {P}%这里的T 必须是phase_count本里程碑阶段总数而不是剩余阶段数——文档特别用“61–67 号阶段、跑到 63 时显示Phase 63/7而非Phase 63/3”举例说明。P 为已完成阶段占比最新roadmap analyze中disk_status为 complete 的阶段数 / T × 100进度条固定 8 格宽█ 满 / ░ 空。当多里程碑项目导致全局阶段号超过本里程碑阶段数N T时改用Phase {N} ({position}/{T})格式避免 “Phase 63/5” 这类误导性显示。单个阶段内部是一条 3a → 3a.5 → 3b → 3c → 3c.5 → 3d → 3d.5 的子步骤链。3a. Smart Discuss三档跳过的智能讨论先检查本阶段是否已有上下文PHASE_STATE$(gsd-sdk query init.phase-op ${PHASE_NUM}) # 解析 has_context三种情况依次判断has_context为 true→ 跳过 discuss显示Phase ${PHASE_NUM}: Context exists — skipping discuss.直接进入 3b。文档特别强调单遍约束--auto模式下 discuss 绝不允许循环has_context检查是权威判据——一旦为 true无论上下文文件看起来有无“缺口”该阶段的 discuss 都视为完成。workflow.skip_discuss为 true→ 完全跳过 discussROADMAP 阶段描述即规格。为让下游 plan-phase 有合法输入会写入一份最小化 CONTEXT.md含Phase Boundary ROADMAP 的 goalImplementation Decisions下只有一个 “Claudes Discretion” 小节Mode: Auto-generated (discuss skipped via workflow.skip_discuss)并提交gsd-sdk query commit docs(${PADDED_PHASE}): auto-generated context (discuss skipped) --files ${phase_dir}/${padded_phase}-CONTEXT.md默认skip_discuss 为 false 或未设→ 按--interactive分支interactive内联执行标准 discuss-phase skillSkill(skillgsd-discuss-phase, args${PHASE_NUM})真实提问并等待用户回答非 interactive默认执行 smart_discuss 步骤批量表格提案见下文专节。讨论完成后再次执行init phase-op校验has_context若仍为 false转入 handle_blocker“Discuss for phase N did not produce CONTEXT.md.”3a.5. UI 安全门前端阶段的 UI 设计契约这是流水线中一个容易忽略的“隐形分支”。判断当前阶段是否属于前端阶段PHASE_SECTION$(gsd-sdk query roadmap.get-phase ${PHASE_NUM} 2/dev/null) GSD_REPO_ROOT$(git rev-parse --show-toplevel 2/dev/null || echo .) printf %s $PHASE_SECTION | node ${GSD_REPO_ROOT}/bin/lib/ui-safety-gate.cjs /dev/null 21 HAS_UI$? UI_SPEC_FILE$(ls ${PHASE_DIR}/*-UI-SPEC.md 2/dev/null | head -1) UI_PHASE_CFG$(gsd-sdk query config-get workflow.ui_phase 2/dev/null || echo true)只有当HAS_UI为 0检出前端指示词且 UI-SPEC 尚不存在且workflow.ui_phase不为 false时才调用Skill(skillgsd-ui-phase, args${PHASE_NUM})生成 UI 设计契约并在之后重新检查*-UI-SPEC.md若仍为空显示警告 “UI-SPEC generation did not produce output — continuing without design contract” 并继续非阻塞。否则静默跳过。这一检测的实现是 bin/lib/ui-safety-gate.cjs值得作为源码级细节展开词表为 11 个 UI 指示词UI、interface、frontend、component、layout、page、screen、view、form、dashboard、widget采用 ASCII 词边界锚定(^|[^a-zA-Z0-9])(TOKEN)([^a-zA-Z0-9]|$)等价于 POSIX[^[:alnum:]]意图——micro-frontend、micro frontend会命中而复合词microfrontend不会误命中对应问题 #3718用 Node.js 实现而非 bash one-liner是因为后者在 Windows PowerShell/cmd.exe 下因 locale 环境变量前缀不被识别而静默失效对应 #3706CLI 从stdin读取阶段文本以规避操作系统 ARG_MAX 限制退出码对齐 grep 语义0 找到 UI 词1 未找到2 使用错误。3b. Plan交互式模式下的后台化非 interactive默认内联执行Skill(skillgsd-plan-phase, args${PHASE_NUM})interactive派发后台 Agent 以隔离主上下文Agent( descriptionPlan phase ${PHASE_NUM}: ${PHASE_NAME}, run_in_backgroundtrue, promptRun plan-phase for phase ${PHASE_NUM}: Skill(skill\gsd-plan-phase\, args\${PHASE_NUM}\) )记录 task_id在下一阶段讨论完成或没有下一阶段后等待该 Agent 结束才进入 execute。无论哪种模式plan 结束后都要重新执行init phase-op校验has_plans为 false 则走 handle_blocker“Plan phase N did not produce any plans.”3c. Execute始终带--no-transition非 interactiveSkill(skillgsd-execute-phase, args${PHASE_NUM} --no-transition)interactive先等待 plan Agent 完成并校验计划存在再派发后台 execute Agent同样带--no-transition。之所以禁用 transition是因为阶段间的状态流转由 autonomous 工作流自己统一管理。3c.5. 代码审查与自动修复链CODE_REVIEW_ENABLED$(gsd-sdk query config-get workflow.code_review 2/dev/null || echo true)配置为false→ 显示 “Code review skipped (workflow.code_reviewfalse)” 直接进入 3d否则调用Skill(skillgsd-code-review, args${PHASE_NUM})解析 REVIEW.md frontmatter 的 statusclean/skipped→ 进入 3d有 findings →自动续跑Skill(skillgsd-code-review, args${PHASE_NUM} --fix --auto)两个 Skill 中任一失败都只作非阻塞提示继续 3d。这正是文档中强调的差异点autonomous 模式自动串联 review 与 fix而 execute-phase/quick 只提示修复。3d. Post-Execution Routing按验证状态四路分派execute 返回后读取验证结果VERIFY_STATUS$(grep ^status: ${PHASE_DIR}/*-VERIFICATION.md 2/dev/null | head -1 | cut -d: -f2 | tr -d )PHASE_DIR来自 3a 的init phase-op返回值若变量不在作用域内则重新获取。四种状态的路由status行为空无 VERIFICATION.md 或无 status 字段走 handle_blocker“Execute phase N did not produce verification results.”passed显示Phase N ✅ {Name} — Verification passed直接进入 iteratehuman_needed读取 human_verification 条目询问 “Validate now” / “Continue without validation”前者再问 “All good — continue” / “Found issues”后者带用户报告的问题走 handle_blocker后者显示⏭ Human validation deferred并继续gaps_found显示缺口分数Score: {N}/{M} must-haves verified询问 “Run gap closure” / “Continue without fixing” / “Stop autonomous mode”gap closure 的防死循环设计选 “Run gap closure” 时执行一轮闭环上限 1 次——Skill(skillgsd-plan-phase, args${PHASE_NUM} --gaps) Skill(skillgsd-execute-phase, args${PHASE_NUM} --no-transition)重新读取 VERIFICATION.md 的 status若变passed/human_needed按正常路由若仍是gaps_found显示 “Gaps persist after closure attempt.” 并只给 “Continue anyway” / “Stop autonomous mode” 两个选项。这个单次自动重试上限是工作流明确声明的防无限循环机制。关于交互提问文档还定义了text mode若$ARGUMENTS含--text或 init JSON 的text_mode为 true所有AskUserQuestion调用都替换为“纯文本编号列表 用户输入序号”——这是非 Claude 运行时OpenAI Codex、Gemini CLI 等无AskUserQuestion工具的兼容路径。3d.5. UI Review前端阶段的评审审计UI_SPEC_FILE$(ls ${PHASE_DIR}/*-UI-SPEC.md 2/dev/null | head -1) UI_REVIEW_CFG$(gsd-sdk query config-get workflow.ui_review 2/dev/null || echo true)当存在 UI-SPEC 且workflow.ui_review不为 false 时调用Skill(skillgsd-ui-review, args${PHASE_NUM})显示 UI-REVIEW.md 的评分摘要。注意其定位UI review 是咨询性的advisory不阻塞——无论得分如何都继续进入 iterate。这与 3c.5 的 code review会触发自动修复形成对照。Smart Discuss 深潜批量灰区提案协议smart_discuss步骤的完整指令在 references/autonomous-smart-discuss.md是gsd-discuss-phase的“自治优化变体”以批量表格形式提出灰区答案用户按领域接受或覆盖最终写出与 discuss-phase完全相同结构的 CONTEXT.md。其内部子步骤加载既有上下文读.planning/PROJECT.md愿景/原则/不可妥协项、REQUIREMENTS.md验收标准/约束、STATE.md进度/既有决策并遍历所有早于当前阶段的*-CONTEXT.md抽取decisions已锁定偏好与specifics构建内部prior_decisions不落盘代码库侦察优先读.planning/codebase/*.mdCONVENTIONS/STRUCTURE/STACK没有才做定向 grepgrep -rl {term} src/ app/ ...读 3–5 个最相关文件构建内部codebase_context可复用资产 / 既有模式 / 集成点要求控制在约 5% 上下文以内基础设施检测在生成灰区之前先判断当目标关键词命中 scaffolding/plumbing/setup/configuration/migration/refactor/rename/restructure/upgrade/infrastructure、成功标准全是技术性的file exists/test passes/config valid/command runs且不描述任何用户可见行为时判定为纯基础设施阶段跳过提案直接写最小 CONTEXT.md生成灰区提案非基础设施阶段按领域类型用户 SEE → visual / CALL → interface / RUN → execution / READ → content / 被 ORGANIZED → organization生成3–4 个灰区、每区约 4 个问题每题预选推荐答案依据prior decisions 一致性、代码库模式、领域惯例、ROADMAP 成功标准外加 1–2 个备选并附注先前决策与代码上下文按区呈现一次一个区展示# | Question | ✅ Recommended | Alternative(s)表格用 AskUserQuestion 给出 “Accept all / Change Q1…QN / Discuss deeper”选项上限 6 个“Change QN” 时展开该题备选加 “You decide”映射到 Claudes Discretion修改后重显示表格并重新请求接受“Discuss deeper” 只对当前区切换交互式逐题问答。超范围诉求按 scope creep 话术记为 deferred idea写 CONTEXT.md落盘到${phase_dir}/${padded_phase}-CONTEXT.md严格使用domain/decisions/code_context/specifics/deferred五段结构与 discuss-phase 输出一致提交docs(${PADDED_PHASE}): smart discuss context并显示 “Decisions captured: {count} across {area_count} areas” 确认。这个协议的设计意图很清晰把“开放式对话”压缩成“可批量批准的表格”从而让自治流水线在保留用户对设计决策最终裁量权的同时把交互轮次压到每区常为一次按键。第 4 步Iterate —— 动态阶段捕获与流水线并行每个阶段完成后--only已设→ 不迭代直接进 lifecycle单阶段模式下 lifecycle 会干净退出--to N已设且当前阶段号 ≥ N→ 显示--to ${TO_PHASE} REACHED横幅含 “Completed through phase N as requested. Remaining phases were not executed.” 与Resume with: /gsd:autonomous --from ${next_incomplete_phase}直接进 lifecycle 处理“部分完成”跳过 audit/complete/cleanup否则→ 重新执行roadmap.analyze用与 discover 相同的过滤逻辑重建未完成列表这正是捕获执行期间插入的十进制阶段如 5.1的机制同时cat .planning/STATE.md检查 Blockers/Concerns 小节发现 blocker 即转 handle_blocker。interactive 模式的流水线并行是这里最精巧的部分Phase N 的 discuss 一结束就把 planexecute 派成后台 Agent主上下文立刻开始讨论 Phase N1但在为 N1 启动 plan 之前必须等待 N 的 execute Agent 完成并处理其执行后路由验证、gap 闭环等。净效果用户始终在做轻量的讨论回答而规划与代码生成在后台进行主上下文只累积 discuss 对话——plan 与 execute 的上下文完全隔离在各自 Agent 中。这对长里程碑的上下文预算context budget控制至关重要。第 5 步Lifecycle —— audit → complete → cleanup--only模式下跳过整个 lifecycle单阶段不触发收尾显示PHASE N COMPLETE ✓并提示 “run /gsd:autonomous without --only after all phases complete to trigger audit/complete/cleanup.”否则全部阶段完成后显示AUTONOMOUS ▸ LIFECYCLE过渡横幅“All phases complete → Starting lifecycle: audit → complete → cleanup”然后依次5a. AuditSkill(skillgsd-audit-milestone)随后解析审计结果AUDIT_FILE.planning/v${milestone_version}-MILESTONE-AUDIT.md AUDIT_STATUS$(grep ^status: ${AUDIT_FILE} 2/dev/null | head -1 | cut -d: -f2 | tr -d )status 为空文件缺失/无 status 字段→ handle_blockerpassed→ 自动进入 5b不打断用户文档标注 “per CTRL-01”即 CTRL-01 允许此类自动推进gaps_found→ 询问 “Continue anyway — accept gaps” / “Stop — fix gaps manually”停止时提示手动运行/gsd:audit-milestone与/gsd:complete-milestonetech_debt→ 展示技术债摘要后询问 “Continue with tech debt” / “Stop — address debt first”。5b. Complete MilestoneSkill(skillgsd-complete-milestone, args${milestone_version})并校验归档产物存在ls .planning/milestones/v${milestone_version}-ROADMAP.md不存在则走 handle_blocker。5c. CleanupSkill(skillgsd-cleanup)。清理本身带 dry-run 并在内部向用户征求删除批准——文档明确这属于 CTRL-01 允许的暂停因为这是关于文件删除的显式决策。5d. Final CompletionGSD ► AUTONOMOUS ▸ COMPLETE Milestone: {milestone_version} — {milestone_name} Status: Complete ✅ Lifecycle: audit ✅ → complete ✅ → cleanup ✅ Ship it! 第 6 步Handle Blocker —— 三选项兜底任何阶段操作失败或检测到 blocker 时通过 AskUserQuestion 呈现固定三选项“Phase {N} ({Name}) encountered an issue: {description}”Fix and retry— 重跑本阶段失败的步骤discuss/plan/execute 中的具体一步若重试后仍失败再次呈现这三个选项Skip this phase— 记录Phase {N} ⏭ {Name} — Skipped by user继续下一个未完成阶段Stop autonomous mode— 显示进度摘要Completed / Skipped / Remaining 三列清单并干净退出退出信息里自动生成恢复命令Resume with: /gsd:autonomous ${ONLY_PHASE ? --only ONLY_PHASE : --from next_phase}${TO_PHASE ? --to TO_PHASE : }注意该命令保留了原始标志组合--only优先于--from--to原样拼接使得中断后一条命令即可精确续跑。配置开关与默认值速查工作流内通过gsd-sdk query config-get workflow.key读取的配置项及其在流程中的作用配置键未设时的回退作用workflow.skip_discussfalsetrue 时跳过 discuss用 ROADMAP 阶段目标作规格并生成最小 CONTEXT.mdworkflow.ui_phasetrue控制前端阶段是否自动生成 UI-SPEC 设计契约workflow.ui_reviewtrue控制执行后是否运行 UI review 审计咨询性、非阻塞workflow.code_reviewtrue控制 3c.5 的自动 code review fix 链text_modeinit JSON /--text—非 Claude 运行时兼容AskUserQuestion 降级为纯文本编号选择在 SDK 的类型定义中WorkflowConfig接口声明了skip_discuss、ui_phase、text_mode等字段见 sdk/src/config.ts并且 SDK 还带有一个与自治讨论直接相关的参数max_discuss_passes“auto/headless 模式下强制推进前的最大自讨论轮数”默认 3——从字段注释看这是为自动模式下的 discuss 环节提供的额外防循环保险与 autonomous 工作流层面 “discuss must be single-pass” 的约束互为补充。与仓库测试体系的对应关系这条工作流的行为并非纸面契约仓库tests/目录下有一组直接以 autonomous 命名的回归测试文件覆盖了本文各节的参数行为与分支tests/autonomous-allowed-tools.test.cjs — 命令 frontmatter 的allowed-tools声明含 Agent 工具interactive 后台派发依赖它tests/autonomous-decomposition.test.cjs — 工作流分解/步骤结构tests/autonomous-interactive.test.cjs —--interactive的内联 discuss 与后台 plan/execute 派发tests/autonomous-to-flag.test.cjs —--to的停止、过滤与 resume 消息tests/autonomous-ui-steps.test.cjs — 3a.5 / 3d.5 两个 UI 分支。另有 tests/ui-safety-gate-false-positives.test.cjs 与tests/bug-3706*命名对应的 UI 词边界误报回归如microfrontend不应命中以及 tests/feat-3309-human-verify-mode.test.cjs 覆盖 human_needed 验证的两种模式mid-flight/end-of-phase——后者正是 3d 路由中 human_verification 段落的配置来源。成功标准工作流自身的验收清单workflows/autonomous.md末尾的success_criteria是工作流实现者的验收清单也是运行者排障时最完整的“应有行为”索引核心条目包括所有未完成阶段按序执行smart discuss → ui-phase → plan → execute → ui-review 各自就位execute-phase 一律带--no-transition验证路由读 VERIFICATION.md 的 statusgap closure 限 1 次自动重试plan/execute 失败必走 handle_blocker每阶段后重读 ROADMAP.md、每阶段前检查 STATE.md blockers--only跳过 lifecycle 且单阶段完成后干净退出--to在 iterate 处停下并在 resume 消息中保留自身标志--interactive的上下文隔离主上下文只累积 discuss 对话、后台 Agent 等待语义、流水线并行lifecycle 各环audit/complete/cleanup通过Skill()真实调用而非“建议用户手动运行”audit 的技术性失败无文件/无 status路由到 handle_blockerUI review 非阻塞、受workflow.ui_phase/workflow.ui_review双开关控制。小结/gsd:autonomous把 GSD 的“规划—执行—验证—收尾”全生命周期压成一条命令其工程要点可以归纳为五层参数层用四个标志控制驱动范围与交互形态发现层用roadmap.analyze的disk_status/roadmap_complete双轨状态加数值化阶段过滤天然兼容十进制插入阶段执行层把 discuss/plan/execute 串成可跳过的子步骤链并为前端阶段叠加 UI-SPEC 与 UI review 两条非阻塞支线路由层以 VERIFICATION.md 的passed/human_needed/gaps_found三态分派决策用单次 gap closure 重试上限杜绝死循环收尾层自动触发 audit → complete → cleanup并保留 CTRL-01 允许的用户决策暂停点。配合workflow.skip_discuss、workflow.ui_phase、workflow.ui_review、workflow.code_review、text_mode五个开关同一条流水线既可以以“全自治”方式无人值守跑完里程碑也可以切到--interactive模式让讨论始终留在人的手里。【免费下载链接】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），仅供参考