GSD Manager 工作流实战get-shit-done 单终端里程碑调度中心与交互式仪表盘【免费下载链接】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/workflows/manager.md 为骨架结合 sdk/src/query/init-complex.ts 等源码实现系统讲解 GSD 的manager工作流如何在一个终端里以仪表盘视角纵览整个里程碑的所有相位Phase如何用「讨论内联、规划/执行后台」的并行模式推进多相位工作以及后台 Agent 失败时的错误分类与恢复策略。读完本文你将能理解 manager 的完整运行机制、gsd-sdk query init.manager的 JSON 契约、仪表盘状态映射规则并掌握manager.flags、刷新间隔等关键配置的实际用法。一、Manager 是什么单终端的里程碑指挥中枢在 GSDget-shit-done体系中一个里程碑Milestone被切分为多个相位Phase每个相位要依次经历「讨论discuss→ 规划plan→ 执行execute」的生命周期。常规做法是逐个相位串行调用 discuss-phase、plan-phase、execute-phase 等工作流但这样无法充分利用并行能力。manager工作流正是为解决这一痛点而设计的它是一个交互式命令中心Interactive command center让用户从一个终端管理整个里程碑以**仪表盘Dashboard**展示全部相位的可视化状态完成/进行中/待办/排队将讨论discuss内联执行因为它需要用户交互而把规划plan与执行execute分派给后台 Agent它们可以自主运行每次动作完成后自动回到仪表盘刷新实现「一个终端并行推进多个相位」。工作流的purpose原文定义如下get-shit-done/workflows/manager.mdInteractive command center for managing a milestone from a single terminal. Shows a dashboard of all phases with visual status, dispatches discuss inline and plan/execute as background agents, and loops back to the dashboard after each action. Enables parallel phase work from one terminal.对应的命令入口是gsd:managercommands/gsd/manager.md它的定位是Single-terminal command center for managing a milestone. Shows a dashboard of all phases with visual status indicators, recommends optimal next actions, and dispatches work — discuss runs inline, plan/execute run as background agents.该命令不直接创建任何文件而是通过Skill()分派现有 GSD 命令、通过后台 Task Agent 驱动相位推进它只读取.planning/STATE.md、.planning/ROADMAP.md及各相位目录来获取状态。二、启动条件与命令形态2.1 前置条件gsd:manager的 frontmatter 声明了requires: [phase]即必须存在一个活跃里程碑包含ROADMAP.md与STATE.md才能运行。若项目尚未初始化规划结构应先运行gsd:new-project或gsd:new-milestone创建里程碑。命令的allowed-tools明确限定了工作流可用的工具面Read, Write, Bash, Glob, Grep, AskUserQuestion, Skill, Agent其中AskUserQuestion用于交互式菜单Skill用于内联分派 discuss 等技能Agent用于派发后台规划/执行子代理。2.2 可选参数命令支持一个可选参数--analyze-depsargument-hint 为[--analyze-deps]。当$ARGUMENTS中包含该参数时manager 会先端到端执行 analyze-dependencies.md 工作流做依赖分析再进入常规管理循环。注意manager 本身「No arguments required」项目上下文、相位列表、依赖与推荐动作都在工作流内部通过gsd-sdk query init.manager解析无需启动时预先加载大量上下文——这是它保持轻量的关键设计。三、初始化gsd-sdk query init.manager的 JSON 契约工作流的第一步是引导Bootstrap初始化数据。无论首次启动还是每次刷新仪表盘都用同一段 Shell 调用 SDK 查询接口INIT$(gsd-sdk query init.manager) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi这段代码处理了两种返回形态SDK 可能直接返回 JSON 字符串也可能因数据量较大而返回file:路径形式的引用此时需要cat读取文件内容再解析。从 sdk/src/query/command-manifest.init.ts 可以看到该查询的注册信息{ family: init, canonical: init.manager, aliases: [init manager], mutation: false, outputMode: json }它属于init查询族、别名为init manager、只读mutation: false、输出 JSON——与工作流「每次刷新都重新读盘」的机制完全吻合。3.1 返回字段清单解析 JSON 后需提取以下核心字段字段说明milestone_version当前里程碑版本号milestone_name当前里程碑名称phase_count相位总数completed_count已完成相位数in_progress_count进行中相位数phases相位数组含状态、依赖、名称等详情recommended_actions推荐动作列表execute/plan/discussall_complete是否全部完成布尔waiting_signal.planning/WAITING.json中的等待信号可为空manager_flags配置透传的标志位见下文queued_milestone_version下一个里程碑版本可选queued_milestone_name下一个里程碑名称可选queued_phases下一个里程碑的相位预览可选其中queued_milestone_version/queued_milestone_name/queued_phases三件套是 SDK 修复2495-2496-2497中引入的对应 issue #2497「manager 仪表盘预览下一里程碑」。旧版 SDK 可能缺失这三个字段工作流要求将其视为空处理不能因缺失而报错。3.2manager_flags每类动作的透传标志manager_flags包含三个子键分别对应三类动作的透传参数manager_flags.discuss— 追加到/gsd:discuss-phase的参数例如--auto --analyzemanager_flags.plan— 追加到后台规划 Agent 的初始化命令manager_flags.execute— 追加到后台执行 Agent 的初始化命令。默认值均为空字符串。配置方式通过 SDK 写入gsd-sdk query config-set manager.flags.discuss --auto --analyze在源码 sdk/src/query/init-complex.ts 中这三个标志从config.manager.flags读取并经过sanitizeFlags白名单校验只有形如--xxx的长选项或xxx形式的普通 token字母数字及-_.才被放行其他非法字符会导致整个标志被置空——这是对命令注入的防御性设计。3.3 初始化失败的处理如果查询返回error字段例如 ROADMAP 缺失源码中对应No ROADMAP.md found. Run /gsd-new-milestone first.工作流要求展示错误信息并退出而不是继续渲染空仪表盘。四、仪表盘Dashboard状态的可视化核心Dashboard 是 manager 的「刷新点」每次到达该步骤都必须重新从磁盘读取状态重新执行gsd-sdk query init.manager以拾取后台 Agent 的进展。这是整个并行模型的基石——后台任务写入磁盘前台仪表盘通过读盘感知变化。4.1 启动横幅首次启动时渲染横幅标识当前里程碑与并行模式━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► MANAGER ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ {milestone_version} — {milestone_name} {phase_count} phases · {completed_count} complete ✓ Discuss → inline ◆ Plan/Execute → background Dashboard auto-refreshes when background work is active. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━4.2 状态符号与进度条状态符号✓表示完成done、◆表示进行中active、○表示待办pending、·表示排队queued。进度条20 字符宽的█░组合按完成百分比填充。列结构每个相位一行包含#序号、Phase名称、Deps依赖、D讨论、P规划、E执行三列状态及合并的Status列。4.3 状态映射规则disk_status → 三列显示这是仪表盘渲染最核心的映射表DDiscussPPlanEExecutedisk_statusDPEStatus 文本complete✓✓✓✓ Completepartial✓✓◆◆ Executing...planned✓✓○○ Ready to executediscussed✓○·○ Ready to planresearched◆··○ Ready to planempty/no_directoryis_next_to_discuss○··○ Ready to discussempty/no_directory其他情况···· Up next附加规则若某相位is_active其状态图标替换为◆并追加(active)后缀只要有任一相位is_active就在表格上方显示一行◆ Background: {action} Phase {N}, ...提示后台活动。从源码 sdk/src/query/init-complex.ts 可以印证disk_status的推导逻辑——它直接扫描各相位目录内的文件计数summaryCount planCount planCount 0 → complete summaryCount 0 → partial planCount 0 → planned hasResearch → researched hasContext存在 *-CONTEXT.md 或 CONTEXT.md→ discussed 其余 → empty / no_directory此外若 ROADMAP.md 中对应相位的复选框被勾选roadmapComplete即使磁盘文件不完整也强制视为complete。is_active则通过「目录内最新文件 mtime 距今小于 5 分钟」判定(now - newestMtime) 300000毫秒这是后台 Agent 正在写盘的信号。4.4 名称截断与依赖列Phase 列必须使用display_name而非name源码 init-complex.ts 将其预截断为 20 字符超出部分以…结尾MAX_NAME_WIDTH 20渲染时所有相位名称需按相同宽度补齐保证表格对齐。Deps 列使用deps_display展示该相位依赖哪些相位如1,3无依赖则为—。该值由depends_on字段中的数字提取而来见源码 init-complex.ts。4.5 完整示例输出━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► DASHBOARD ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ████████████░░░░░░░░ 60% (3/5 phases) ◆ Background: Planning Phase 4 | # | Phase | Deps | D | P | E | Status | |---|----------------------|------|---|---|---|---------------------| | 1 | Foundation | — | ✓ | ✓ | ✓ | ✓ Complete | | 2 | API Layer | 1 | ✓ | ✓ | ◆ | ◆ Executing (active)| | 3 | Auth System | 1 | ✓ | ✓ | ○ | ○ Ready to execute | | 4 | Dashboard UI Set… | 1,2 | ✓ | ◆ | · | ◆ Planning (active) | | 5 | Notifications | — | ○ | · | · | ○ Ready to discuss | | 6 | Polish Final Mail… | 1-5 | · | · | · | · Up next |五、下一里程碑预览Queued Section当queued_phases存在且非空时在主表格下方渲染下一里程碑的紧凑预览即当前里程碑为路线图中最后一个时不渲染。─────────────────────────────────────────────────────────────── ◆ Queued — {queued_milestone_version} {queued_milestone_name} ({queued_phases.length} phases) ─────────────────────────────────────────────────────────────── | # | Phase | Deps | Status | |---|----------------------|------|--------------| | 31| Email Logs | — | · Queued | | 32| Todays Sheets | 31 | · Queued | | 33| Resend Backfill | 31 | · Queued | | 34| Business Day Audit | 31 | · Queued |设计要点排队相位不参与 D/P/E 三列渲染尚未讨论只展示序号、截断后的display_name、deps_display与固定的· Queued状态名称列的宽度需与主表对齐保持视觉一致排队相位绝不可进入 Continue 动作菜单——它们属于未来里程碑必须等当前里程碑发布ship后才能处理。预览仅为情境感知situational awareness而存在。源码中该能力位于 init-complex.ts通过extractNextMilestoneSection从 ROADMAP 中取出活跃里程碑之后的那一段再解析其相位失败时静默跳过queued_phases is a non-critical enhancement。六、推荐动作与复合选项逻辑6.1 全部完成all_complete当all_complete为 true源码判定completedCount phases.length phases.length 0见 init-complex.ts渲染里程碑完成横幅╔══════════════════════════════════════════════════════════════╗ ║ MILESTONE COMPLETE ║ ╚══════════════════════════════════════════════════════════════╝ All {phase_count} phases done. Ready for final steps: → /gsd:verify-work — run acceptance testing → /gsd:complete-milestone — archive and wrap up随后通过AskUserQuestion提问「All phases complete. What next?」选项为Verify work→ 调用Skill(skillgsd-verify-work)完成后回到仪表盘Complete milestone→ 调用Skill(skillgsd-complete-milestone)然后退出Exit manager→ 进入退出步骤。对应工作流文档位于 verify-work.md 与 complete-milestone.md。6.2 未完成时的复合选项构建如果all_complete为 false则根据recommended_actions构建选项。复合选项Compound Option的核心理念是尽可能减少选项数量——一个选项可以同时派发多个后台 Agent外加一个内联动作。构建步骤收集所有后台动作execute 与 plan 推荐——两者都可能有多个收集内联动作discuss 推荐——至多一个因为讨论是串行的只要存在任意推荐动作就创建唯一的主选项「Continue」其下方逐条列出全部动作不做任何截断Continue: → Execute Phase 32 (background) → Plan Phase 34 (background) → Discuss Phase 35 (inline)关键约束Continue 选项必须包含recommended_actions中的每一个动作——有 3 个就列 3 个有 5 个就列 5 个绝不允许只展示前 2 个。派发顺序为「先并行启动全部后台 Agent再执行内联 discuss若有」若无内联动作则派发后台后直接刷新仪表盘。始终追加两个固定选项Refresh dashboard与Exit manager。推荐动作的紧凑展示─────────────────────────────────────────────────────────────── ▶ Next Steps ─────────────────────────────────────────────────────────────── Continue: → Execute Phase 32 (background) → Plan Phase 34 (background) → Discuss Phase 35 (inline)6.3 推荐动作的生成规则源码级在 init-complex.ts 中推荐动作按「execute plan discuss」的优先级生成且遵循依赖可达性reaches约束避免同一条依赖链上并行推进两个相关相位planned且依赖已满足deps_satisfied→ 推荐execute条件无其他活跃执行或与活跃执行之间不存在依赖链上的可达关系discussed/researched→ 推荐plan条件类似empty/no_directory且is_next_to_discuss→ 推荐discuss理由为「Unblocked, ready to gather context」。is_next_to_discuss的判定来自 bug #2268 修复所有未讨论相位都被标记为可讨论init-complex.ts注释说明此前「滑动窗口」模式只推荐一个 discuss 动作即使调用方有余量并行讨论多个也只有一个推荐现在每个无依赖阻塞的未讨论相位都会进入推荐。6.4 自动刷新与文本模式自动刷新只要存在is_active的相位后台 Agent 运行中仪表盘进入 60 秒自动刷新周期。若 60 秒内无用户输入自动刷新仪表盘。该间隔由配置manager_refresh_interval控制默认 60 秒设为 0 可禁用。文本模式Text Mode当$ARGUMENTS含--text或 init JSON 中text_mode为 true 时启用TEXT_MODEtrue。此时所有AskUserQuestion调用替换为纯文本编号列表让用户输入选项编号。这是非 Claude 运行时OpenAI Codex、Gemini CLI 等的必选模式因为那些平台没有AskUserQuestion工具。text_mode的配置源头是workflow.text_mode见 sdk/src/query/init.ts。6.5 Other 自由输入解析AskUserQuestion会自动附加 Other 选项。用户选择 Other 后输入自由文本时工作流解析其意图若提到相位编号与动作如「plan 4」则据此派发若意图不明则展示可用动作并回到动作菜单循环。七、动作分发内联讨论 后台规划/执行7.1 Refresh Dashboard / Exit ManagerRefresh Dashboard直接回到仪表盘步骤重新读盘。Exit Manager进入退出步骤。7.2 复合动作后台 内联选择复合选项时先并行派发全部后台 AgentPlan/Execute再运行内联 discussSkill(skillgsd-discuss-phase, args{PHASE_NUM} {manager_flags.discuss})discuss 完成后回到仪表盘后台 Agent 继续运行。7.3 Discuss Phase N内联讨论需要用户输入因此内联执行并携带配置标志Skill(skillgsd-discuss-phase, args{PHASE_NUM} {manager_flags.discuss})完成后回到仪表盘。7.4 Plan Phase N后台 Agent规划可自主运行派发后台 Agent 并委托给 Skill 管线Agent( descriptionPlan phase {N}: {phase_name}, run_in_backgroundtrue, promptYou are running the GSD plan-phase workflow for phase {N} of the project. Working directory: {cwd} Phase: {N} — {phase_name} Goal: {goal} Manager flags: {manager_flags.plan} Run the plan-phase Skill with any configured manager flags: Skill(skill\gsd-plan-phase\, args\{N} --auto {manager_flags.plan}\) This delegates to the full plan-phase pipeline including local patches, research, plan-checker, and all quality gates. Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions based on project context. If you hit a blocker, write it to STATE.md as a blocker and stop. Do NOT silently work around permission or file access errors — let them fail so the manager can surface them with resolution hints. Do NOT use --no-verify on git commits. )派发后显示◆ Spawning planner for Phase {N}: {phase_name}...并回到仪表盘。ORCHESTRATOR RULE — CODEX RUNTIME在run_in_backgroundtrue调用Agent()之后编排器不得再独立为该相位做任何规划工作应立即返回仪表盘等待子代理回报只有拿到子代理结果后才能恢复规划相关工作。7.5 Execute Phase N后台 Agent执行同样自主运行委托给gsd-execute-phaseAgent( descriptionExecute phase {N}: {phase_name}, run_in_backgroundtrue, promptYou are running the GSD execute-phase workflow for phase {N} of the project. Working directory: {cwd} Phase: {N} — {phase_name} Goal: {goal} Manager flags: {manager_flags.execute} Run the execute-phase Skill with any configured manager flags: Skill(skill\gsd-execute-phase\, args\{N} {manager_flags.execute}\) This delegates to the full execute-phase pipeline including local patches, branching, wave-based execution, verification, and all quality gates. Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions. Do NOT use --no-verify on git commits — let pre-commit hooks run normally. If you hit a permission error, file lock, or any access issue, do NOT work around it — let it fail and write the error to STATE.md as a blocker so the manager can surface it with resolution guidance. )同样遵循 CODEX Runtime 编排规则显示◆ Spawning executor for Phase {N}: {phase_name}...后立即回到仪表盘。两个后台 prompt 的共性约束值得注意禁止使用AskUserQuestion——后台运行没有交互通道必须基于项目上下文自主决策禁止使用--no-verify提交 git——让 pre-commit 钩子正常执行遇到权限/文件锁/访问问题时不得自行绕过——应让失败自然发生并把错误写入 STATE.md 作为 blocker由 manager 统一呈现并给出解决建议。八、后台 Agent 完成与错误恢复8.1 成功完成收到后台 Agent 完成通知后读取 Agent 的结果消息显示简短通知✓ {description} {brief summary from agent result}回到仪表盘步骤。8.2 错误分类与恢复选项若 Agent 报告错误或 blocker需先分类再处理A. 权限 / 工具访问错误工具未授权、permission denied、沙箱限制解析错误定位被阻止的工具或命令清晰展示错误后询问Phase {N} failed — permission denied for {tool_or_command}. Want me to add it to settings.local.json so its allowed?三个选项Add permission and retry用Skill(skillupdate-config)将权限写入settings.local.json然后重新派发后台 AgentRun this phase inline instead改为内联派发——失败动作是规划则Skill(skillgsd-plan-phase, args{N})是执行则Skill(skillgsd-execute-phase, args{N})Skip and continue回到仪表盘相位保持当前状态。B. 其他错误git 锁、文件冲突、逻辑错误等展示错误并询问Background agent for Phase {N} encountered an issue: {error}. What next?四个选项Retry重新派发同一后台 AgentRun inline instead改为内联派发对应 SkillSkip and continue回到仪表盘View details读取 STATE.md 的 blockers 区块展示然后重新呈现选项。九、退出与会话恢复退出时渲染最终状态━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► SESSION END ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ {milestone_version} — {milestone_name} {PROGRESS_BAR} {progress_pct}% ({completed_count}/{phase_count} phases) Resume anytime: /gsd:manager ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━重要说明退出时仍在运行的后台 Agent 会继续执行到完成其结果会在下次调用/gsd:manager或/gsd:progress参见 progress.md时可见。这意味着退出 manager 并不中断进行中的相位工作并行推进的成果会持久化到磁盘。十、配置项汇总配置键默认值作用manager.flags.discuss追加到/gsd:discuss-phase的参数manager.flags.plan追加到后台规划 Agent 的 init 命令manager.flags.execute追加到后台执行 Agent 的 init 命令manager_refresh_interval60秒后台活跃时的仪表盘自动刷新间隔0禁用workflow.text_modefalse启用纯文本菜单非 Claude 运行时其中manager.flags.*经sanitizeFlags白名单过滤只接受--xxx长选项与xxx普通 tokentext_mode也可通过--text参数临时开启。设置示例gsd-sdk query config-set manager.flags.discuss --auto --analyze gsd-sdk query config-set workflow.text_mode true十一、成功标准验收清单manager 工作流自带成功标准可作为自测与审查清单仪表盘展示全部相位状态指示D/P/E 列正确进度条显示准确的完成百分比依赖解析正确被阻塞的相位显示缺失的依赖推荐动作按 execute plan discuss 排序discuss 通过Skill()内联运行交互式提问可用plan 派发后台 Task Agent立即回到仪表盘execute 派发后台 Task Agent立即回到仪表盘仪表盘刷新能通过磁盘状态拾取后台 Agent 变更后台 Agent 完成触发通知并刷新仪表盘后台 Agent 错误呈现 retry/skip 选项全部完成时提供 verify-work 与 complete-milestone退出显示最终状态与恢复指引Other 自由输入被解析出相位编号与动作Manager 循环持续运行直到用户退出或里程碑完成queued_phases非空时渲染 Queued 区缺失/为空时跳过十二、测试与实现验证manager 的数据层在 sdk/src/query/init-complex.test.ts 中有系统性的测试覆盖可直接对照验证实现行为describe(initManager, ...)约第 364 行起覆盖里程碑解析、状态计算、推荐动作生成等基础路径describe(initManager workstream (#2731), ...)约第 585 行起验证在 workstream 场景下initManager能正确定位.planning结构避免忽略 workstream 时误报错误describe(initProgress initManager precedence (#2674), ...)约第 684 行起验证initProgress与initManager之间的优先级语义确保两套查询对同一磁盘状态的理解一致。这些测试连同工作流文档、命令定义commands/gsd/manager.md共同构成了 manager 功能的完整证据链上层是交互式编排仪表盘 复合选项 后台派发底层是init.manager查询对 ROADMAP/STATE/相位目录的纯读解析。理解这两层的关系就掌握了在单终端中并行推进整个里程碑的全部原理与操作手法。【免费下载链接】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），仅供参考 
长河君 · 2026/9/10 10:04:09 · 阅读 1.2k GSD Manager 工作流实战：get-shit-done 单终端里程碑调度中心与交互式仪表盘
GSD Manager 工作流实战get-shit-done 单终端里程碑调度中心与交互式仪表盘【免费下载链接】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/workflows/manager.md 为骨架结合 sdk/src/query/init-complex.ts 等源码实现系统讲解 GSD 的manager工作流如何在一个终端里以仪表盘视角纵览整个里程碑的所有相位Phase如何用「讨论内联、规划/执行后台」的并行模式推进多相位工作以及后台 Agent 失败时的错误分类与恢复策略。读完本文你将能理解 manager 的完整运行机制、gsd-sdk query init.manager的 JSON 契约、仪表盘状态映射规则并掌握manager.flags、刷新间隔等关键配置的实际用法。一、Manager 是什么单终端的里程碑指挥中枢在 GSDget-shit-done体系中一个里程碑Milestone被切分为多个相位Phase每个相位要依次经历「讨论discuss→ 规划plan→ 执行execute」的生命周期。常规做法是逐个相位串行调用 discuss-phase、plan-phase、execute-phase 等工作流但这样无法充分利用并行能力。manager工作流正是为解决这一痛点而设计的它是一个交互式命令中心Interactive command center让用户从一个终端管理整个里程碑以**仪表盘Dashboard**展示全部相位的可视化状态完成/进行中/待办/排队将讨论discuss内联执行因为它需要用户交互而把规划plan与执行execute分派给后台 Agent它们可以自主运行每次动作完成后自动回到仪表盘刷新实现「一个终端并行推进多个相位」。工作流的purpose原文定义如下get-shit-done/workflows/manager.mdInteractive command center for managing a milestone from a single terminal. Shows a dashboard of all phases with visual status, dispatches discuss inline and plan/execute as background agents, and loops back to the dashboard after each action. Enables parallel phase work from one terminal.对应的命令入口是gsd:managercommands/gsd/manager.md它的定位是Single-terminal command center for managing a milestone. Shows a dashboard of all phases with visual status indicators, recommends optimal next actions, and dispatches work — discuss runs inline, plan/execute run as background agents.该命令不直接创建任何文件而是通过Skill()分派现有 GSD 命令、通过后台 Task Agent 驱动相位推进它只读取.planning/STATE.md、.planning/ROADMAP.md及各相位目录来获取状态。二、启动条件与命令形态2.1 前置条件gsd:manager的 frontmatter 声明了requires: [phase]即必须存在一个活跃里程碑包含ROADMAP.md与STATE.md才能运行。若项目尚未初始化规划结构应先运行gsd:new-project或gsd:new-milestone创建里程碑。命令的allowed-tools明确限定了工作流可用的工具面Read, Write, Bash, Glob, Grep, AskUserQuestion, Skill, Agent其中AskUserQuestion用于交互式菜单Skill用于内联分派 discuss 等技能Agent用于派发后台规划/执行子代理。2.2 可选参数命令支持一个可选参数--analyze-depsargument-hint 为[--analyze-deps]。当$ARGUMENTS中包含该参数时manager 会先端到端执行 analyze-dependencies.md 工作流做依赖分析再进入常规管理循环。注意manager 本身「No arguments required」项目上下文、相位列表、依赖与推荐动作都在工作流内部通过gsd-sdk query init.manager解析无需启动时预先加载大量上下文——这是它保持轻量的关键设计。三、初始化gsd-sdk query init.manager的 JSON 契约工作流的第一步是引导Bootstrap初始化数据。无论首次启动还是每次刷新仪表盘都用同一段 Shell 调用 SDK 查询接口INIT$(gsd-sdk query init.manager) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi这段代码处理了两种返回形态SDK 可能直接返回 JSON 字符串也可能因数据量较大而返回file:路径形式的引用此时需要cat读取文件内容再解析。从 sdk/src/query/command-manifest.init.ts 可以看到该查询的注册信息{ family: init, canonical: init.manager, aliases: [init manager], mutation: false, outputMode: json }它属于init查询族、别名为init manager、只读mutation: false、输出 JSON——与工作流「每次刷新都重新读盘」的机制完全吻合。3.1 返回字段清单解析 JSON 后需提取以下核心字段字段说明milestone_version当前里程碑版本号milestone_name当前里程碑名称phase_count相位总数completed_count已完成相位数in_progress_count进行中相位数phases相位数组含状态、依赖、名称等详情recommended_actions推荐动作列表execute/plan/discussall_complete是否全部完成布尔waiting_signal.planning/WAITING.json中的等待信号可为空manager_flags配置透传的标志位见下文queued_milestone_version下一个里程碑版本可选queued_milestone_name下一个里程碑名称可选queued_phases下一个里程碑的相位预览可选其中queued_milestone_version/queued_milestone_name/queued_phases三件套是 SDK 修复2495-2496-2497中引入的对应 issue #2497「manager 仪表盘预览下一里程碑」。旧版 SDK 可能缺失这三个字段工作流要求将其视为空处理不能因缺失而报错。3.2manager_flags每类动作的透传标志manager_flags包含三个子键分别对应三类动作的透传参数manager_flags.discuss— 追加到/gsd:discuss-phase的参数例如--auto --analyzemanager_flags.plan— 追加到后台规划 Agent 的初始化命令manager_flags.execute— 追加到后台执行 Agent 的初始化命令。默认值均为空字符串。配置方式通过 SDK 写入gsd-sdk query config-set manager.flags.discuss --auto --analyze在源码 sdk/src/query/init-complex.ts 中这三个标志从config.manager.flags读取并经过sanitizeFlags白名单校验只有形如--xxx的长选项或xxx形式的普通 token字母数字及-_.才被放行其他非法字符会导致整个标志被置空——这是对命令注入的防御性设计。3.3 初始化失败的处理如果查询返回error字段例如 ROADMAP 缺失源码中对应No ROADMAP.md found. Run /gsd-new-milestone first.工作流要求展示错误信息并退出而不是继续渲染空仪表盘。四、仪表盘Dashboard状态的可视化核心Dashboard 是 manager 的「刷新点」每次到达该步骤都必须重新从磁盘读取状态重新执行gsd-sdk query init.manager以拾取后台 Agent 的进展。这是整个并行模型的基石——后台任务写入磁盘前台仪表盘通过读盘感知变化。4.1 启动横幅首次启动时渲染横幅标识当前里程碑与并行模式━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► MANAGER ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ {milestone_version} — {milestone_name} {phase_count} phases · {completed_count} complete ✓ Discuss → inline ◆ Plan/Execute → background Dashboard auto-refreshes when background work is active. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━4.2 状态符号与进度条状态符号✓表示完成done、◆表示进行中active、○表示待办pending、·表示排队queued。进度条20 字符宽的█░组合按完成百分比填充。列结构每个相位一行包含#序号、Phase名称、Deps依赖、D讨论、P规划、E执行三列状态及合并的Status列。4.3 状态映射规则disk_status → 三列显示这是仪表盘渲染最核心的映射表DDiscussPPlanEExecutedisk_statusDPEStatus 文本complete✓✓✓✓ Completepartial✓✓◆◆ Executing...planned✓✓○○ Ready to executediscussed✓○·○ Ready to planresearched◆··○ Ready to planempty/no_directoryis_next_to_discuss○··○ Ready to discussempty/no_directory其他情况···· Up next附加规则若某相位is_active其状态图标替换为◆并追加(active)后缀只要有任一相位is_active就在表格上方显示一行◆ Background: {action} Phase {N}, ...提示后台活动。从源码 sdk/src/query/init-complex.ts 可以印证disk_status的推导逻辑——它直接扫描各相位目录内的文件计数summaryCount planCount planCount 0 → complete summaryCount 0 → partial planCount 0 → planned hasResearch → researched hasContext存在 *-CONTEXT.md 或 CONTEXT.md→ discussed 其余 → empty / no_directory此外若 ROADMAP.md 中对应相位的复选框被勾选roadmapComplete即使磁盘文件不完整也强制视为complete。is_active则通过「目录内最新文件 mtime 距今小于 5 分钟」判定(now - newestMtime) 300000毫秒这是后台 Agent 正在写盘的信号。4.4 名称截断与依赖列Phase 列必须使用display_name而非name源码 init-complex.ts 将其预截断为 20 字符超出部分以…结尾MAX_NAME_WIDTH 20渲染时所有相位名称需按相同宽度补齐保证表格对齐。Deps 列使用deps_display展示该相位依赖哪些相位如1,3无依赖则为—。该值由depends_on字段中的数字提取而来见源码 init-complex.ts。4.5 完整示例输出━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► DASHBOARD ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ████████████░░░░░░░░ 60% (3/5 phases) ◆ Background: Planning Phase 4 | # | Phase | Deps | D | P | E | Status | |---|----------------------|------|---|---|---|---------------------| | 1 | Foundation | — | ✓ | ✓ | ✓ | ✓ Complete | | 2 | API Layer | 1 | ✓ | ✓ | ◆ | ◆ Executing (active)| | 3 | Auth System | 1 | ✓ | ✓ | ○ | ○ Ready to execute | | 4 | Dashboard UI Set… | 1,2 | ✓ | ◆ | · | ◆ Planning (active) | | 5 | Notifications | — | ○ | · | · | ○ Ready to discuss | | 6 | Polish Final Mail… | 1-5 | · | · | · | · Up next |五、下一里程碑预览Queued Section当queued_phases存在且非空时在主表格下方渲染下一里程碑的紧凑预览即当前里程碑为路线图中最后一个时不渲染。─────────────────────────────────────────────────────────────── ◆ Queued — {queued_milestone_version} {queued_milestone_name} ({queued_phases.length} phases) ─────────────────────────────────────────────────────────────── | # | Phase | Deps | Status | |---|----------------------|------|--------------| | 31| Email Logs | — | · Queued | | 32| Todays Sheets | 31 | · Queued | | 33| Resend Backfill | 31 | · Queued | | 34| Business Day Audit | 31 | · Queued |设计要点排队相位不参与 D/P/E 三列渲染尚未讨论只展示序号、截断后的display_name、deps_display与固定的· Queued状态名称列的宽度需与主表对齐保持视觉一致排队相位绝不可进入 Continue 动作菜单——它们属于未来里程碑必须等当前里程碑发布ship后才能处理。预览仅为情境感知situational awareness而存在。源码中该能力位于 init-complex.ts通过extractNextMilestoneSection从 ROADMAP 中取出活跃里程碑之后的那一段再解析其相位失败时静默跳过queued_phases is a non-critical enhancement。六、推荐动作与复合选项逻辑6.1 全部完成all_complete当all_complete为 true源码判定completedCount phases.length phases.length 0见 init-complex.ts渲染里程碑完成横幅╔══════════════════════════════════════════════════════════════╗ ║ MILESTONE COMPLETE ║ ╚══════════════════════════════════════════════════════════════╝ All {phase_count} phases done. Ready for final steps: → /gsd:verify-work — run acceptance testing → /gsd:complete-milestone — archive and wrap up随后通过AskUserQuestion提问「All phases complete. What next?」选项为Verify work→ 调用Skill(skillgsd-verify-work)完成后回到仪表盘Complete milestone→ 调用Skill(skillgsd-complete-milestone)然后退出Exit manager→ 进入退出步骤。对应工作流文档位于 verify-work.md 与 complete-milestone.md。6.2 未完成时的复合选项构建如果all_complete为 false则根据recommended_actions构建选项。复合选项Compound Option的核心理念是尽可能减少选项数量——一个选项可以同时派发多个后台 Agent外加一个内联动作。构建步骤收集所有后台动作execute 与 plan 推荐——两者都可能有多个收集内联动作discuss 推荐——至多一个因为讨论是串行的只要存在任意推荐动作就创建唯一的主选项「Continue」其下方逐条列出全部动作不做任何截断Continue: → Execute Phase 32 (background) → Plan Phase 34 (background) → Discuss Phase 35 (inline)关键约束Continue 选项必须包含recommended_actions中的每一个动作——有 3 个就列 3 个有 5 个就列 5 个绝不允许只展示前 2 个。派发顺序为「先并行启动全部后台 Agent再执行内联 discuss若有」若无内联动作则派发后台后直接刷新仪表盘。始终追加两个固定选项Refresh dashboard与Exit manager。推荐动作的紧凑展示─────────────────────────────────────────────────────────────── ▶ Next Steps ─────────────────────────────────────────────────────────────── Continue: → Execute Phase 32 (background) → Plan Phase 34 (background) → Discuss Phase 35 (inline)6.3 推荐动作的生成规则源码级在 init-complex.ts 中推荐动作按「execute plan discuss」的优先级生成且遵循依赖可达性reaches约束避免同一条依赖链上并行推进两个相关相位planned且依赖已满足deps_satisfied→ 推荐execute条件无其他活跃执行或与活跃执行之间不存在依赖链上的可达关系discussed/researched→ 推荐plan条件类似empty/no_directory且is_next_to_discuss→ 推荐discuss理由为「Unblocked, ready to gather context」。is_next_to_discuss的判定来自 bug #2268 修复所有未讨论相位都被标记为可讨论init-complex.ts注释说明此前「滑动窗口」模式只推荐一个 discuss 动作即使调用方有余量并行讨论多个也只有一个推荐现在每个无依赖阻塞的未讨论相位都会进入推荐。6.4 自动刷新与文本模式自动刷新只要存在is_active的相位后台 Agent 运行中仪表盘进入 60 秒自动刷新周期。若 60 秒内无用户输入自动刷新仪表盘。该间隔由配置manager_refresh_interval控制默认 60 秒设为 0 可禁用。文本模式Text Mode当$ARGUMENTS含--text或 init JSON 中text_mode为 true 时启用TEXT_MODEtrue。此时所有AskUserQuestion调用替换为纯文本编号列表让用户输入选项编号。这是非 Claude 运行时OpenAI Codex、Gemini CLI 等的必选模式因为那些平台没有AskUserQuestion工具。text_mode的配置源头是workflow.text_mode见 sdk/src/query/init.ts。6.5 Other 自由输入解析AskUserQuestion会自动附加 Other 选项。用户选择 Other 后输入自由文本时工作流解析其意图若提到相位编号与动作如「plan 4」则据此派发若意图不明则展示可用动作并回到动作菜单循环。七、动作分发内联讨论 后台规划/执行7.1 Refresh Dashboard / Exit ManagerRefresh Dashboard直接回到仪表盘步骤重新读盘。Exit Manager进入退出步骤。7.2 复合动作后台 内联选择复合选项时先并行派发全部后台 AgentPlan/Execute再运行内联 discussSkill(skillgsd-discuss-phase, args{PHASE_NUM} {manager_flags.discuss})discuss 完成后回到仪表盘后台 Agent 继续运行。7.3 Discuss Phase N内联讨论需要用户输入因此内联执行并携带配置标志Skill(skillgsd-discuss-phase, args{PHASE_NUM} {manager_flags.discuss})完成后回到仪表盘。7.4 Plan Phase N后台 Agent规划可自主运行派发后台 Agent 并委托给 Skill 管线Agent( descriptionPlan phase {N}: {phase_name}, run_in_backgroundtrue, promptYou are running the GSD plan-phase workflow for phase {N} of the project. Working directory: {cwd} Phase: {N} — {phase_name} Goal: {goal} Manager flags: {manager_flags.plan} Run the plan-phase Skill with any configured manager flags: Skill(skill\gsd-plan-phase\, args\{N} --auto {manager_flags.plan}\) This delegates to the full plan-phase pipeline including local patches, research, plan-checker, and all quality gates. Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions based on project context. If you hit a blocker, write it to STATE.md as a blocker and stop. Do NOT silently work around permission or file access errors — let them fail so the manager can surface them with resolution hints. Do NOT use --no-verify on git commits. )派发后显示◆ Spawning planner for Phase {N}: {phase_name}...并回到仪表盘。ORCHESTRATOR RULE — CODEX RUNTIME在run_in_backgroundtrue调用Agent()之后编排器不得再独立为该相位做任何规划工作应立即返回仪表盘等待子代理回报只有拿到子代理结果后才能恢复规划相关工作。7.5 Execute Phase N后台 Agent执行同样自主运行委托给gsd-execute-phaseAgent( descriptionExecute phase {N}: {phase_name}, run_in_backgroundtrue, promptYou are running the GSD execute-phase workflow for phase {N} of the project. Working directory: {cwd} Phase: {N} — {phase_name} Goal: {goal} Manager flags: {manager_flags.execute} Run the execute-phase Skill with any configured manager flags: Skill(skill\gsd-execute-phase\, args\{N} {manager_flags.execute}\) This delegates to the full execute-phase pipeline including local patches, branching, wave-based execution, verification, and all quality gates. Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions. Do NOT use --no-verify on git commits — let pre-commit hooks run normally. If you hit a permission error, file lock, or any access issue, do NOT work around it — let it fail and write the error to STATE.md as a blocker so the manager can surface it with resolution guidance. )同样遵循 CODEX Runtime 编排规则显示◆ Spawning executor for Phase {N}: {phase_name}...后立即回到仪表盘。两个后台 prompt 的共性约束值得注意禁止使用AskUserQuestion——后台运行没有交互通道必须基于项目上下文自主决策禁止使用--no-verify提交 git——让 pre-commit 钩子正常执行遇到权限/文件锁/访问问题时不得自行绕过——应让失败自然发生并把错误写入 STATE.md 作为 blocker由 manager 统一呈现并给出解决建议。八、后台 Agent 完成与错误恢复8.1 成功完成收到后台 Agent 完成通知后读取 Agent 的结果消息显示简短通知✓ {description} {brief summary from agent result}回到仪表盘步骤。8.2 错误分类与恢复选项若 Agent 报告错误或 blocker需先分类再处理A. 权限 / 工具访问错误工具未授权、permission denied、沙箱限制解析错误定位被阻止的工具或命令清晰展示错误后询问Phase {N} failed — permission denied for {tool_or_command}. Want me to add it to settings.local.json so its allowed?三个选项Add permission and retry用Skill(skillupdate-config)将权限写入settings.local.json然后重新派发后台 AgentRun this phase inline instead改为内联派发——失败动作是规划则Skill(skillgsd-plan-phase, args{N})是执行则Skill(skillgsd-execute-phase, args{N})Skip and continue回到仪表盘相位保持当前状态。B. 其他错误git 锁、文件冲突、逻辑错误等展示错误并询问Background agent for Phase {N} encountered an issue: {error}. What next?四个选项Retry重新派发同一后台 AgentRun inline instead改为内联派发对应 SkillSkip and continue回到仪表盘View details读取 STATE.md 的 blockers 区块展示然后重新呈现选项。九、退出与会话恢复退出时渲染最终状态━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► SESSION END ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ {milestone_version} — {milestone_name} {PROGRESS_BAR} {progress_pct}% ({completed_count}/{phase_count} phases) Resume anytime: /gsd:manager ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━重要说明退出时仍在运行的后台 Agent 会继续执行到完成其结果会在下次调用/gsd:manager或/gsd:progress参见 progress.md时可见。这意味着退出 manager 并不中断进行中的相位工作并行推进的成果会持久化到磁盘。十、配置项汇总配置键默认值作用manager.flags.discuss追加到/gsd:discuss-phase的参数manager.flags.plan追加到后台规划 Agent 的 init 命令manager.flags.execute追加到后台执行 Agent 的 init 命令manager_refresh_interval60秒后台活跃时的仪表盘自动刷新间隔0禁用workflow.text_modefalse启用纯文本菜单非 Claude 运行时其中manager.flags.*经sanitizeFlags白名单过滤只接受--xxx长选项与xxx普通 tokentext_mode也可通过--text参数临时开启。设置示例gsd-sdk query config-set manager.flags.discuss --auto --analyze gsd-sdk query config-set workflow.text_mode true十一、成功标准验收清单manager 工作流自带成功标准可作为自测与审查清单仪表盘展示全部相位状态指示D/P/E 列正确进度条显示准确的完成百分比依赖解析正确被阻塞的相位显示缺失的依赖推荐动作按 execute plan discuss 排序discuss 通过Skill()内联运行交互式提问可用plan 派发后台 Task Agent立即回到仪表盘execute 派发后台 Task Agent立即回到仪表盘仪表盘刷新能通过磁盘状态拾取后台 Agent 变更后台 Agent 完成触发通知并刷新仪表盘后台 Agent 错误呈现 retry/skip 选项全部完成时提供 verify-work 与 complete-milestone退出显示最终状态与恢复指引Other 自由输入被解析出相位编号与动作Manager 循环持续运行直到用户退出或里程碑完成queued_phases非空时渲染 Queued 区缺失/为空时跳过十二、测试与实现验证manager 的数据层在 sdk/src/query/init-complex.test.ts 中有系统性的测试覆盖可直接对照验证实现行为describe(initManager, ...)约第 364 行起覆盖里程碑解析、状态计算、推荐动作生成等基础路径describe(initManager workstream (#2731), ...)约第 585 行起验证在 workstream 场景下initManager能正确定位.planning结构避免忽略 workstream 时误报错误describe(initProgress initManager precedence (#2674), ...)约第 684 行起验证initProgress与initManager之间的优先级语义确保两套查询对同一磁盘状态的理解一致。这些测试连同工作流文档、命令定义commands/gsd/manager.md共同构成了 manager 功能的完整证据链上层是交互式编排仪表盘 复合选项 后台派发底层是init.manager查询对 ROADMAP/STATE/相位目录的纯读解析。理解这两层的关系就掌握了在单终端中并行推进整个里程碑的全部原理与操作手法。【免费下载链接】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），仅供参考