get-shit-done（GSD）命令全参考：从阶段工作流到诊断与配置的完整命令手册

2026-09-08 14:56:32作者：晏闻田Solitary

get-shit-done（简称 GSD，本仓库即其开源实现）是一套面向 Claude Code 等 AI 编程代理的轻量级元提示与规格驱动开发（Spec-Driven Development）系统。本文以日文官方文档 docs/ja-JP/COMMANDS.md 为主体骨架，逐条讲解 GSD 全部稳定命令的语法、参数、标志位与使用示例——从 /gsd-new-project 到 /gsd-workstreams、从代码质量审查到故障诊断，并对照仓库中的命令定义文件（commands/gsd/）、工作流实现（get-shit-done/workflows/）与专用代理（agents/），补足每条命令的落地细节与源码依据。读完本文，你将能够像一位熟练的 GSD 用户一样，在 .planning/ 规格驱动开发体系中精准选用命令，完成项目初始化、阶段讨论、规划、执行、验证、里程碑收尾、调试与配置全流程。

注：命令体系的完整特性说明见功能参考（日文），分步上手教程见用户指南（日文）。英文权威命令参考见 docs/COMMANDS.md，本仓库另有中文 README 可了解项目概览。

一、命令语法：不同 AI 运行时的同一套命令

GSD 的命令针对不同 AI 编程运行时以不同拼写形式注入，但本质是同一个命令：

运行时	命令形式
Claude Code / Gemini / Copilot	`/gsd-command-name [args]`
OpenCode / Kilo	`/gsd-command-name [args]`
Codex	`$gsd-command-name [args]`

在英文权威参考 docs/COMMANDS.md 中还进一步说明：Gemini CLI 使用冒号形式 /gsd:command-name，将命令挂载在 gsd: 命名空间下。安装器会根据你当前所处的运行时，自动把正确的拼写写入对应运行时的命令目录，因此连字符形式与冒号形式只是同一命令在不同运行时下的外壳差异，你无需记忆两套语法。

每个斜杠命令都有一个对应的命令定义源文件，位于 commands/gsd/，例如 /gsd-new-project 对应 commands/gsd/new-project.md；命令的完整执行流程则由 get-shit-done/workflows/ 下的工作流文件驱动，.planning/ 内产生的各类工件则遵循 get-shit-done/templates/ 中的模板（如 PLAN、UAT、VALIDATION、UI-SPEC 等模板）。命令描述信息会被注入每个会话的系统提示词，为保证开销可控，描述字段有严格字符预算（≤100 字符）并通过 npm run lint:descriptions 门禁校验（见 docs/COMMANDS.md 结尾与 tests/enh-2789-description-budget.test.cjs）。

二、核心工作流命令：从立项到里程碑的完整流水线

GSD 的规格驱动流程可以概括为「项目初始化 → 阶段讨论 → 规划 → 执行 → 验证 → 交付（ship）→ 里程碑审计与收尾」。核心命令如下。

`/gsd-new-project`：深度上下文驱动的项目初始化

初始化新项目，并进行深度上下文收集。

标志	说明
`--auto @file.md`	从文档自动抽取信息，跳过交互式提问

前置条件：不存在既有的 .planning/PROJECT.md
生成物：PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、config.json、research/、CLAUDE.md

/gsd-new-project                    # 交互模式
/gsd-new-project --auto @prd.md     # 从 PRD 自动抽取

--auto @prd.md 让已有产品需求文档（PRD）的团队直接把文档交给 GSD 抽取成项目骨架，无需逐题回答引导问题。该命令的实现源文件为 commands/gsd/new-project.md，其生成的 config.json 结构与默认值可参照模板 get-shit-done/templates/config.json。

`/gsd-workspace`：多仓库 / 功能隔离的分离工作区

/gsd-workspace 可创建、列出或删除拥有仓库副本与独立 .planning/ 目录的隔离工作区环境。

--new 创建，可用标志如下：

标志	说明
`--name <name>`	工作区名（必须）
`--repos repo1,repo2`	逗号分隔的仓库路径或名称
`--path /target`	目标目录（默认 `~/gsd-workspaces/<name>`）
`--strategy worktree\|clone`	复制策略（默认 `worktree`）
`--branch <name>`	检出的分支（默认 `workspace/<name>`）
`--auto`	跳过交互式提问

典型使用场景：

多仓库：只选取若干仓库子集，在彼此隔离的 GSD 状态下并行推进；
功能隔离：--repos . 为当前仓库创建 worktree。

生成物：WORKSPACE.md、.planning/、仓库副本（worktree 或 clone）。

/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI
/gsd-workspace --new --name feature-b --repos . --strategy worktree  # 同一仓库内隔离
/gsd-workspace --new --name spike --repos api,web --strategy clone   # 完整克隆

--list 列出：扫描 ~/gsd-workspaces/ 内的 WORKSPACE.md 清单，展示工作区名称、仓库数量、策略与 GSD 项目状态。

/gsd-workspace --list

--remove <name> 删除：

参数	是否必须	说明
`<name>`	是	要删除的工作区名称

删除同时会清理对应 git worktree，并带安全保护——存在未提交更改的仓库会拒绝删除，且需要名称二次确认。

/gsd-workspace --remove feature-b

`/gsd-discuss-phase`：规划前的自适应讨论

在规划之前，通过自适应提问收集阶段上下文，把关键决策先记录下来。参数 N（可选）指定阶段编号，缺省为当前阶段。

标志	说明
`--auto`	对所有提问自动选择推荐默认值
`--batch`	将问题分组为批量摄入，而非逐条提问
`--analyze`	讨论过程中附加权衡（trade-off）分析
`--chain`	discuss → plan → execute 单流程自动串联（v1.31）
`--power`	从预先准备好的答案文件批量作答（v1.32）

前置条件：.planning/ROADMAP.md 存在
生成物：{phase}-CONTEXT.md、{phase}-DISCUSSION-LOG.md（审计轨迹）

/gsd-discuss-phase 1                # 阶段 1 的交互式讨论
/gsd-discuss-phase 3 --auto         # 阶段 3 自动选择默认值
/gsd-discuss-phase --batch          # 当前阶段的批量模式
/gsd-discuss-phase 2 --analyze      # 带权衡分析的讨论

英文权威版还补充了 --all（跳过领域选择、直接讨论所有灰区）以及子命令式变体 --assumptions、--power（见下文「阶段管理」）。--power 的文件批量作答模式由工作流 get-shit-done/workflows/discuss-phase-power.md 驱动，适合需要跨多个阶段统一答复口径的团队。

`/gsd-ui-phase`：前端阶段的 UI 设计契约

为含前端/UI 工作的阶段生成 UI 设计契约文档。参数 N（可选）为阶段号。

前置条件：.planning/ROADMAP.md 存在，且该阶段包含前端/UI 工作
生成物：{phase}-UI-SPEC.md（模板可参考 get-shit-done/templates/UI-SPEC.md）

/gsd-ui-phase 2                     # 生成阶段 2 的设计契约

`/gsd-plan-phase`：阶段的调研、规划与验证

对单个阶段执行「调研 + 规划 + 验证」三步。参数 N（可选）缺省为下一个未规划阶段。

标志	说明
`--auto`	跳过交互确认
`--research`	即使 `RESEARCH.md` 已存在也强制重新调研
`--skip-research`	跳过领域调研步骤
`--gaps`	缺口闭合模式（读取 `VERIFICATION.md` 并跳过调研）
`--skip-verify`	跳过计划检查器的验证循环
`--prd <file>`	使用 PRD 文件而非 discuss-phase 作为上下文
`--reviews`	根据 `REVIEWS.md` 的跨 AI 评审反馈重新规划

前置条件：.planning/ROADMAP.md 存在
生成物：{phase}-RESEARCH.md、{phase}-{N}-PLAN.md、{phase}-VALIDATION.md

/gsd-plan-phase 1                   # 阶段 1：调研＋规划＋验证
/gsd-plan-phase 3 --skip-research   # 不调研直接规划（熟悉领域）
/gsd-plan-phase --auto              # 非交互式规划

从英文参考可知 /gsd-plan-phase 还有面向高级用法的标志：--ingest <path-or-glob> 用 ADR 文件替代 discuss-phase 合成上下文、--ingest-format auto|nygard|madr|narrative 指定 ADR 解析格式、--validate 在规划前校验状态、--bounce/--skip-bounce 控制外部计划弹回验证；--research-phase <N> 则将独立调研命令 gsd-research-phase 收编为仅调研模式（配合 --view 可直接打印既有 RESEARCH.md）。生成的计划文档需要符合 get-shit-done/templates/phase-prompt.md 之类模板约定的结构，供后续执行阶段消费。

`/gsd-execute-phase`：基于 Wave 并行的阶段执行

执行阶段内的全部计划（以 Wave 为单位的并行化），或仅执行指定 Wave。参数 N（必须）指定阶段号。

参数/标志	是否必须	说明
`N`	是	要执行的阶段号
`--wave N`	否	只执行阶段内的 Wave `N`

前置条件：阶段中存在 PLAN.md 文件
生成物：每个计划对应 {phase}-{N}-SUMMARY.md、git 提交；阶段全部完成后生成 {phase}-VERIFICATION.md

/gsd-execute-phase 1                # 执行阶段 1
/gsd-execute-phase 1 --wave 2       # 仅执行 Wave 2

「Wave 并行化」意味着同一阶段内相互独立的计划会被分批并行调度（背景代理执行），其并发安全与 checkpoint 心跳行为在仓库测试中有覆盖，例如 tests/autonomous-decomposition.test.cjs 与 tests/concurrency-safety.test.cjs。

`/gsd-verify-work`：带自动诊断的 UAT

对已完成阶段执行用户验收测试。参数 N（可选）缺省为最近执行过的阶段。

前置条件：阶段已执行
生成物：{phase}-UAT.md；若发现问题还会产出修复计划

/gsd-verify-work 1                  # 阶段 1 的 UAT

UAT 工件模板为 get-shit-done/templates/UAT.md。

`/gsd-progress --next`：自动推进到下一步

/gsd-progress 负责回答「我现在在哪？下一步做什么？」。加 --next 后会自动读取项目状态并执行合适的命令：

无项目 → 建议 /gsd-new-project
阶段需要讨论 → 运行 /gsd-discuss-phase
阶段需要规划 → 运行 /gsd-plan-phase
阶段需要执行 → 运行 /gsd-execute-phase
阶段需要验证 → 运行 /gsd-verify-work
全部阶段完成 → 建议 /gsd-complete-milestone

/gsd-progress --next                           # 自动检测并执行下一步

`/gsd-pause-work --report`：中断时保存上下文交接

在阶段中途中断时保存上下文交接；--report 生成包含工作总结、产出与估算资源消耗的会话报告。

前置条件：存在近期工作过的活动项目
生成物：.planning/reports/SESSION_REPORT.md（外加 continue-here.md 交接点）

/gsd-pause-work --report                 # 会话后生成总结

报告内容包括：已做工作（提交、已执行计划、已推进的阶段）、成果与产出物、阻塞项与决策、估算 token/成本用量、下一步建议。

`/gsd-ship`：从阶段工件自动生成 PR

用已完成阶段的工作自动生成 PR 正文。参数 N（可选）为阶段号或里程碑版本（如 4 或 v1.0），--draft 以草稿 PR 创建。

前置条件：阶段已通过验证（/gsd-verify-work 通过）；gh CLI 已安装并完成认证
生成物：基于规划工件生成富正文的 GitHub PR，并更新 STATE.md

/gsd-ship 4                         # 交付阶段 4
/gsd-ship 4 --draft                 # 以草稿 PR 交付

PR 正文包含：来自 ROADMAP.md 的阶段目标、来自 SUMMARY.md 的变更摘要、已覆盖需求（REQ-ID）、验证状态、关键决策。

`/gsd-ui-review`：对已实现前端的六轴视觉审计

对已实现的前端做追溯式六轴视觉审计。参数 N（可选）缺省为最近执行阶段。前置条件为项目包含前端代码（可独立运行，不要求完整 GSD 项目）。

/gsd-ui-review                      # 审计当前阶段
/gsd-ui-review 3                    # 审计阶段 3

生成 {phase}-UI-REVIEW.md 及 .planning/ui-reviews/ 下的截图，评审维度由 gsd-ui-auditor、gsd-ui-checker、gsd-ui-researcher 等代理配合支撑（见 agents/，例如 agents/gsd-ui-auditor.md）。

`/gsd-audit-uat` / `/gsd-audit-milestone`：跨阶段审计

/gsd-audit-uat：跨全部阶段审计未处理的 UAT 与验证项。前置条件为至少有一个阶段已带 UAT/验证执行过；生成分类审计报告与人工测试计划。
/gsd-audit-milestone：验证里程碑是否达成其完成定义（Definition of Done）。前置条件为全部阶段已执行；生成带差距分析的审计报告。

/gsd-audit-uat
/gsd-audit-milestone

`/gsd-complete-milestone`：归档里程碑并打标签

前置条件：里程碑审计已完成（推荐）
生成物：MILESTONES.md 条目、git 标签

/gsd-complete-milestone

`/gsd-milestone-summary`：从里程碑工件生成综合摘要

面向团队入职与评审，从里程碑工件生成综合项目摘要。参数 version（可选）指定里程碑版本（缺省为当前/最新里程碑）。

摘要内容包括：概述、架构决策、逐阶段分析、关键决策与权衡、需求覆盖率、技术债与延后项、新成员上手指南；生成后还会提供交互式 Q&A。

/gsd-milestone-summary                # 汇总当前里程碑
/gsd-milestone-summary v1.0           # 汇总指定里程碑

生成物：.planning/reports/MILESTONE_SUMMARY-v{version}.md。

`/gsd-new-milestone`：开启下一个版本周期

参数/标志	是否必须	说明
`name`	否	里程碑名称
`--reset-phase-numbers`	否	新里程碑从阶段 1 重新编号，并在创建路线图前归档旧阶段目录

前置条件：上一里程碑已完成
生成物：更新后的 PROJECT.md、新的 REQUIREMENTS.md 与新的 ROADMAP.md

/gsd-new-milestone                  # 交互模式
/gsd-new-milestone "v2.0 Mobile"    # 指定名称的里程碑
/gsd-new-milestone --reset-phase-numbers "v2.0 Mobile"  # 里程碑阶段号从 1 重启

里程碑归档模板见 get-shit-done/templates/milestone-archive.md。

三、阶段管理命令：路线图的增删改与追溯补验

`/gsd-phase` 及其子命令

/gsd-phase（追加新阶段）：以交互方式在路线图末尾追加一个整数编号的新阶段，输入阶段描述。

/gsd-phase                      # 交互式 —— 输入阶段描述

/gsd-phase --insert N（插入紧急工作）：使用小数编号在阶段之间插入紧急性工作。参数 N（可选）指定在该阶段号之后插入。

/gsd-phase --insert 3                 # 在阶段 3 与 4 之间插入 → 生成 3.1

/gsd-phase --remove N（删除阶段并重编号）：删除未来阶段并对其后阶段重新编号。参数 N（可选）为要删除的阶段号。

/gsd-phase --remove 7                 # 删除阶段 7，并将 8→7、9→8……依次重编号

英文权威版中 /gsd-phase 已演化为一个统一的阶段 CRUD 命令，还支持 --edit <N> 原地修改阶段任意字段、--force 强制编辑进行中/已完成阶段。

`/gsd-discuss-phase --assumptions`：预览实现前提

在规划前展示 Claude 对本阶段拟采用的实现前提。参数 N（可选）为阶段号。

/gsd-discuss-phase --assumptions 2       # 确认阶段 2 的假设

`/gsd-plan-phase --research-phase N`：仅做生态调研

只执行深入的生态调研（独立功能；常规流程仍请使用 /gsd-plan-phase）。参数 N（可选）为阶段号。

/gsd-plan-phase --research-phase 4               # 调研阶段 4 的领域

`/gsd-validate-phase N`：追溯补验测试覆盖缺口

追溯审计并补填 Nyquist 验证缺口。参数 N（可选）为阶段号。

/gsd-validate-phase 2               # 审计阶段 2 的测试覆盖

四、导航与状态命令

命令	用途
`/gsd-progress`	显示状态与下一步（“我在哪？下一步是什么？”）
`/gsd-resume-work`	从上次会话恢复完整上下文，适合上下文重置或开启新会话后使用
`/gsd-pause-work`	阶段中途中断时保存上下文交接（创建 `continue-here.md`）

/gsd-progress                       # “我在哪？下一步做什么？”
/gsd-resume-work                    # 上下文重置或新会话后使用
/gsd-pause-work                     # 创建 continue-here.md

`/gsd-manager`：单终端多阶段命令中心

交互式命令中心，可在单个终端管理多个阶段。前置条件：.planning/ROADMAP.md 存在。

能力要点：

全部阶段的可视化状态指示器仪表盘；
基于依赖与进度推荐最优下一步动作；
工作派发：discuss 以内联方式运行，plan/execute 以后台代理方式运行；
面向在单终端内跨阶段并行工作的进阶用户。

/gsd-manager                        # 打开命令中心仪表盘

/gsd-manager --analyze-deps（v1.32）：检测阶段依赖关系并在 ROADMAP.md 中建议 Depends on 条目。检测手段包括文件重叠、语义依赖（API/模式的生产者与消费者）、数据流依赖。执行后会显示依赖建议表，用户确认后写入 ROADMAP.md。

/gsd-manager --analyze-deps            # 分析并建议依赖关系

`/gsd-help`：分层帮助

展示命令与使用指南。/gsd-help 给出单屏快速参考。

/gsd-help                           # 快速参考

英文参考中还支持 --brief（约 10 行速览）、--full（完整参考）、<topic>（直达某节，如 /gsd-help debug）等层级；分主题别名表见 get-shit-done/workflows/help/。

五、工具命令

`/gsd-quick`：带 GSD 保证的临时任务

以 GSD 的质量保证执行临时（ad-hoc）任务。

标志	说明
`--full`	启用计划检查（2 次迭代）＋执行后验证
`--discuss`	轻量级规划前讨论
`--research`	规划前启动聚焦型研究者

标志可组合使用。

/gsd-quick                          # 基础快速任务
/gsd-quick --discuss --research     # 讨论＋调研＋规划
/gsd-quick --full                   # 带计划检查与验证
/gsd-quick --discuss --research --full  # 全部可选阶段

`/gsd-autonomous`：全自动执行剩余阶段

标志	说明
`--from N`	从指定阶段号开始
`--to N`	在阶段 N 完成后停止自主执行（v1.32）
`--only N`	仅自主执行指定单个阶段（v1.31）
`--interactive`	在每阶段的 discuss 步骤要求用户确认

/gsd-autonomous                     # 执行全部剩余阶段
/gsd-autonomous --from 3            # 从阶段 3 开始
/gsd-autonomous --to 5              # 执行到阶段 5
/gsd-autonomous --from 3 --to 5     # 执行阶段 3～5
/gsd-autonomous --only 4            # 仅自主执行阶段 4

注意 --interactive 用于在自动化的 discuss 环节插入人工确认点，避免全自动流程一路绿灯（相关策略可参 commands/gsd/autonomous.md）。

`/gsd-fast`：自由文本路由 / 内联零开销任务

/gsd-fast 承担两个角色：

路由：把自由文本路由到合适的 GSD 命令：

/gsd-fast                             # 随后描述你想做的事

内联执行（英文权威版进一步细分）：对拼写修正、配置调整、小重构、遗漏提交等简单任务以内联方式直接执行，不启动子代理、无规划开销：

/gsd-fast "fix typo in README"
/gsd-fast "add .env to gitignore"

注意 /gsd-fast 不能替代 /gsd-quick——需要调研、多步规划或验证的任务应使用 /gsd-quick。

`/gsd-capture`：零摩擦的想法捕获与待办管理

随手捕获想法——追加备忘、列出，或把备忘升级为结构化 Todo。

参数	是否必须	说明
`text`	否	要捕获的备忘文本（缺省为追加模式）
`list`	否	从项目与全局作用域列出全部备忘
`promote N`	否	将备忘 N 转换为结构化 Todo

标志	说明
`--global`	备忘操作使用全局作用域

/gsd-capture "Consider caching strategy for API responses"
/gsd-capture list
/gsd-capture promote 3

日文版文档在该节后另有一段 description 参数的等价捕获说明，以及待办列表操作：

/gsd-capture "Consider adding dark mode support"
/gsd-capture --list                # 列出待办并挑选一项开工

`/gsd-debug`：带持久状态的系统化调试

参数	是否必须	说明
`description`	否	缺陷描述

标志	说明
`--diagnose`	仅诊断模式：只做调研、不尝试修复（v1.32）

/gsd-debug "Login button not responding on mobile Safari"
/gsd-debug --diagnose "API returning 500 on /users endpoint"

英文权威版为 /gsd-debug 增加了会话管理子命令：list（列出全部活动调试会话）、status <slug>（无需启动代理即可查看证据数/排除数/结论）、continue <slug>（按 slug 恢复会话）；当 .planning/config.json 设置 tdd_mode: true 时，调试会话要求先写并通过失败测试（red → green → done）才允许修复。调试会话管理机制可参考 agents/gsd-debug-session-manager.md 与 agents/gsd-debugger.md。

`/gsd-add-tests N`：为已完成阶段补测试

参数 N（可选）为阶段号。

/gsd-add-tests 2                    # 为阶段 2 生成测试

`/gsd-stats`：项目统计

/gsd-stats                          # 项目指标仪表盘

`/gsd-profile-user`：开发者行为画像

从 Claude Code 会话分析中，跨 8 个维度（沟通风格、决策模式、调试方法、UX 偏好、厂商选择、挫败感触发点、学习风格、解释深度）生成开发者行为画像，并产出用于个性化 Claude 回复的工件。

标志	说明
`--questionnaire`	以交互式问卷替代会话分析
`--refresh`	重新分析会话以重新生成画像

生成工件：

USER-PROFILE.md —— 完整行为画像
CLAUDE.md 画像章节 —— 由 Claude Code 自动发现

/gsd-profile-user                   # 分析会话并构建画像
/gsd-profile-user --questionnaire   # 交互式问卷兜底
/gsd-profile-user --refresh         # 基于全新分析重新生成

`/gsd-health`：目录完整性校验

校验 .planning/ 目录完整性。

标志	说明
`--repair`	自动修复可恢复问题

/gsd-health                         # 完整性检查
/gsd-health --repair                # 检查并修复

英文权威版补充了 --context：探测上下文窗口利用率，60% 告警、70% 临界。

`/gsd-cleanup`：归档已完成里程碑的阶段目录

/gsd-cleanup

六、诊断命令：`/gsd-forensics`

对失败或卡住的 GSD 工作流做事后调查。参数 description（可选）为问题描述，省略时交互式提示输入。

前置条件：.planning/ 目录存在
生成物：.planning/forensics/report-{timestamp}.md

调查覆盖：

Git 历史分析（最近提交、卡住模式、时间空隙）；
工件完整性（已完成阶段应存在的文件）；
STATE.md 异常与会话历史；
未提交工作、冲突、被弃更改；
至少检查 4 类异常（卡死循环、缺失工件、弃置工作、崩溃/中断）；
若发现可操作结论，会建议创建 GitHub issue。

/gsd-forensics                              # 交互式 —— 提示输入问题
/gsd-forensics "Phase 3 execution stalled"  # 直接携带问题描述

七、工作流与配置命令

`/gsd-workstreams`：跨领域并行工作流管理

子命令	说明
`list`	带状态列出全部工作流（未指定子命令时的默认动作）
`create <name>`	创建新工作流
`status <name>`	查看单个工作流详细状态
`switch <name>`	设置活动工作流
`progress`	全部工作流的进度摘要
`complete <name>`	归档已完成的工作流
`resume <name>`	恢复某工作流中的作业

前置条件：存在活动 GSD 项目
生成物：.planning/ 下的工作流目录、按工作流的状态追踪

/gsd-workstreams                    # 列出全部工作流
/gsd-workstreams create backend-api # 创建新工作流
/gsd-workstreams switch backend-api # 设为活动工作流
/gsd-workstreams status backend-api # 详细状态
/gsd-workstreams progress           # 跨工作流进度概览
/gsd-workstreams complete backend-api  # 归档已完成工作流
/gsd-workstreams resume backend-api    # 恢复工作流中的作业

工作流相关测试见 tests/workstream.test.cjs 等。

`/gsd-settings`：交互式配置

工作流开关与模型画像的交互式设置。

/gsd-settings                       # 交互式设置

`/gsd-config --profile`：快速画像切换

参数	是否必须	说明
`profile`	是	取值 `quality`、`balanced`、`budget` 或 `inherit`

/gsd-config --profile budget             # 切换到 budget 画像
/gsd-config --profile quality            # 切换到 quality 画像

配置文件按分层策略落盘（默认写入 .planning/config.json），校验规则与默认值可参考 docs/CONFIGURATION.md 及模板 get-shit-done/templates/config.json。

八、棕地（Brownfield）与更新命令

`/gsd-map-codebase`：并行映射既有代码库

使用并行 mapper 代理分析既有代码库。参数 area（可选）将映射限定到指定领域。

/gsd-map-codebase                   # 分析整个代码库
/gsd-map-codebase auth              # 聚焦 auth 领域

英文权威版补充 --fast（单代理快速评估）与 --query <term>（检索 .planning/intel/ 下可查询的代码库情报）等用法；代码库映射的结构化输出由 agents/gsd-codebase-mapper.md 等代理配合完成。

`/gsd-update`：带变更预览的更新

/gsd-update                         # 检查更新并安装

/gsd-update --reapply：GSD 更新后恢复本地补丁。

/gsd-update --reapply               # 合并恢复本地修改

九、代码质量命令

`/gsd-review`：跨 AI 阶段计划评审

由外部 AI CLI 对阶段计划进行跨 AI 同行评审。

参数	是否必须	说明
`--phase N`	是	要评审的阶段号

标志	说明
`--gemini`	纳入 Gemini CLI 评审
`--claude`	纳入 Claude CLI 评审（独立会话）
`--codex`	纳入 Codex CLI 评审
`--coderabbit`	纳入 CodeRabbit 评审
`--opencode`	纳入 OpenCode 评审（经 GitHub Copilot）
`--qwen`	纳入 Qwen Code 评审（阿里 Qwen 模型）
`--cursor`	纳入 Cursor 代理评审
`--all`	纳入全部可用 CLI

/gsd-review --phase 3 --all
/gsd-review --phase 2 --gemini

生成 {phase}-REVIEWS.md，可被 /gsd-plan-phase --reviews 消费以依据外部评审反馈重新规划。仓库还支持通过 review.default_reviewers 配置「无标志运行」的默认评审器集合。

`/gsd-pr-branch`：过滤出干净的 PR 分支

过滤 .planning/ 的提交，创建干净的 PR 分支。参数 target branch（可选）为基分支（默认 main）。目的是让评审者只看到代码变更，而不看到 GSD 规划工件。

/gsd-pr-branch                     # 相对 main 过滤
/gsd-pr-branch develop             # 相对 develop 过滤

`/gsd-audit-uat`（代码质量节重复条目）

英文权威版在代码质量节还提供了 /gsd-code-review（对阶段变更的源码文件做 bug/安全/质量评审，--fix 自动修复，--depth=quick|standard|deep 控制深度）与 /gsd-audit-fix（审计到修复的自主流水线，--source/--severity/--max/--dry-run 控制范围）；日文版文档在「代码质量」节重复列出了 /gsd-audit-uat（其完整说明见本文第二节）。

十、待办、种子与线程管理（Backlog & Threads）

`/gsd-capture --backlog <description>`：加入停车区

使用 999.x 编号把想法放进待办停车区（backlog parking lot）。参数 description（必须）为待办项描述。

/gsd-capture --backlog "GraphQL API layer"
/gsd-capture --backlog "Mobile responsive redesign"

999.x 编号使待办项保持在活动阶段序列之外；同时会立即创建阶段目录，因此 /gsd-discuss-phase、/gsd-plan-phase 可以直接对其工作。

`/gsd-review-backlog`：评审并提升待办项

逐项操作：Promote（提升，移入活动序列）、Keep（保留在待办区）、Remove（删除）。

/gsd-review-backlog

`/gsd-capture --seed`：带触发条件的未来想法

捕获带触发条件的未来想法，在合适里程碑自动浮现。参数 idea summary（可选）为种子描述。种子机制解决「上下文劣化」问题——不同于无人阅读的 Deferred 一行备忘，种子保存完整的 WHY、应在何时浮现、通往细节的线索。

/gsd-capture --seed "Add real-time collaboration when WebSocket infra is in place"

生成 .planning/seeds/SEED-NNN-slug.md；由 /gsd-new-milestone 扫描并提示匹配的种子。

`/gsd-thread`：跨会话持久上下文线程

参数	说明
（无）	列出全部线程
`name`	按名称恢复既有线程
`description`	创建新线程

线程是跨多个会话但不属于任何特定阶段的工作的轻量级跨会话知识库，比 /gsd-pause-work 更轻。

/gsd-thread                         # 列出全部线程
/gsd-thread fix-deploy-key-auth     # 恢复线程
/gsd-thread "Investigate TCP timeout in pasta service"  # 创建新线程

十一、命令体系与仓库源码的对应关系

命令定义：每个斜杠命令的说明、参数提示与描述字段集中在 commands/gsd/（如 commands/gsd/new-project.md、commands/gsd/discuss-phase.md）；这些描述会被注入会话系统提示词，因此仓库设有描述预算门禁（npm run lint:descriptions）及对应测试 tests/enh-2789-description-budget.test.cjs。
工作流编排：命令背后往往对应 get-shit-done/workflows/ 下的多步工作流文档，负责把命令翻译为具体代理编排与产物写入序列。
专用代理：执行阶段所需的领域人才（如文档撰写、代码评审、安全审计、UI 审计等）分别由 agents/ 下的代理定义（如 agents/gsd-code-reviewer.md、agents/gsd-executor.md）。
产物模板：.planning/ 内的工件结构（计划、验证、UAT、UI-SPEC、里程碑归档等）统一遵循 get-shit-done/templates/，保证跨项目、跨团队的一致性与可机读性。
回归保障：仓库拥有庞大的命令级测试集，可针对性地查看单条命令的行为契约，例如 tests/workspace.test.cjs、tests/discuss-phase-power.test.cjs、tests/audit-milestone.test.cjs 等；运行全部命令契约测试可执行 npm test。

小结：按使用场景速查

开启新项目：/gsd-new-project → /gsd-workspace --new（多仓库隔离）
推进一个阶段：/gsd-discuss-phase → /gsd-ui-phase（含 UI 时）→ /gsd-plan-phase → /gsd-execute-phase → /gsd-verify-work
不想手动逐步驱动：/gsd-progress --next 自动路由，或 /gsd-autonomous 全自动执行
临时小任务：区分 /gsd-fast（内联零开销）与 /gsd-quick（带 GSD 质量保证）
收尾交付：/gsd-ship → /gsd-audit-uat//gsd-audit-milestone → /gsd-complete-milestone → /gsd-milestone-summary
跨会话/并行：/gsd-pause-work、/gsd-resume-work、/gsd-thread、/gsd-manager、/gsd-workstreams
质量与安全：/gsd-code-review（英文参考）、/gsd-review、/gsd-ui-review、/gsd-validate-phase、/gsd-debug、/gsd-forensics
配置与升级：/gsd-settings、/gsd-config --profile、/gsd-health --repair、/gsd-update --reapply