首页
/ GSD（get-shit-done）深度指南：为 Claude Code 打造的轻量规范驱动开发与上下文工程系统

GSD（get-shit-done）深度指南：为 Claude Code 打造的轻量规范驱动开发与上下文工程系统

2026-09-07 23:53:10作者：戚魁泉Nursing
get-shit-done
A 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（GSD） 是一套面向 Claude Code 等多款 AI 编程 CLI 的元提示词（meta-prompting）、上下文工程（context engineering）与规范驱动开发（spec-driven development）系统。本指南以仓库中的 README.ko-KR.md 为骨架，结合本仓库的命令定义、配置模板与安全模块源码展开，帮助你掌握从安装、六阶段工作流、命令体系、配置模型到安全加固的完整实操方案，把"描述想法"变成"可信赖地交付可运行代码"。

一、GSD 是什么：为"一个人 + AI"设计的开发系统

GSD 由作者 TÂCHES 创建。作者自述是一名"代码由 Claude Code 书写"的独立开发者——市场上并不缺少规范驱动开发工具（如 BMAD、Speckit），但它们往往内建了冲刺仪式、故事点、利益相关者同步、复盘、Jira 工作流等为 50 人团队设计的"企业流程"。GSD 的定位与之相反：复杂度内置于系统内部，而非用户的日常操作流程中。

系统的核心价值主张包括三方面：

  1. 解决上下文腐化（context rot）——Claude Code 的上下文窗口填得越满，输出质量下降越明显。GSD 通过把"重型上下文"转移给子代理（subagent），让主上下文窗口始终保持在 30%～40% 占用，从而维持全流程质量。
  2. 把"规范驱动"做成开箱即用——系统在后台完成上下文工程、XML 提示词格式化、子代理编排与状态管理，用户在外层看到的只是若干条简洁命令（/gsd-*）。
  3. 面向真实个人开发者——适用人群被明确描述为"希望描述想法就能得到正确产出、又不必假装自己是 50 人软件公司"的开发者。

一句话概括（来自文档原文）：Claude Code 本身很强大，GSD 让它变得可信赖。

二、为谁而做：内置质量门禁的实际价值

除了面向独立开发者外，文档特别强调内置质量门禁能在真实场景中拦截问题：

  • Schema 漂移检测：标记遗漏迁移的 ORM 变更；
  • 安全强制（security enforcement）：把验证固定到威胁模型上；
  • 范围收缩检测：防止规划器（planner）静默遗漏需求。

这些能力共同构成"把 AI 输出的不可控风险限制在系统可验证范围内"的工程防线，在仓库源码中也能看到对应实现（详见本文"安全"一节）。

三、快速开始：一条命令完成多运行时安装

GSD 通过 npm 包 get-shit-done-cc 分发，支持 macOS、Windows、Linux。安装命令极简：

npx get-shit-done-cc@latest

交互式安装的两个决策点

安装过程中需要选择：

  1. 运行时（Runtime）——Claude Code、OpenCode、Gemini、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Cline，或"全部"（交互式多选，可一次选择多个运行时）；
  2. 安装位置——全局（所有项目可用）或本地（仅当前项目）。

安装校验方式（按运行时区分）

运行时 校验方式
Claude Code / Gemini / Copilot / Antigravity 输入 /gsd-help
OpenCode / Kilo / Augment / Trae 输入 /gsd-help
Codex 输入 $gsd-help
Cline GSD 通过 .clinerules 安装——检查 .clinerules 是否存在

注意：Claude Code 2.1.88+ 与 Codex 以"技能（skills）"形式安装（skills/gsd-*/SKILL.md），Cline 使用 .clinerules，安装程序会自动处理各运行时格式。若无法使用 npm 或需要源码方式安装，参考 docs/manual-update.md。

保持更新

GSD 迭代非常快，文档建议周期性执行同一安装命令即可升级到最新版：

npx get-shit-done-cc@latest

非交互安装（Docker / CI / 脚本场景）

通过 --<runtime> 与 --global（别名 -g）/ --local（别名 -l）组合即可跳过交互提示。文档给出的完整映射如下（注释为安装目录）：

# Claude Code
npx get-shit-done-cc --claude --global   # 安装到 ~/.claude/
npx get-shit-done-cc --claude --local    # 安装到 ./.claude/

# OpenCode
npx get-shit-done-cc --opencode --global # 安装到 ~/.config/opencode/

# Gemini CLI
npx get-shit-done-cc --gemini --global   # 安装到 ~/.gemini/

# Kilo
npx get-shit-done-cc --kilo --global     # 安装到 ~/.config/kilo/
npx get-shit-done-cc --kilo --local      # 安装到 ./.kilo/

# Codex
npx get-shit-done-cc --codex --global    # 安装到 ~/.codex/
npx get-shit-done-cc --codex --local     # 安装到 ./.codex/

# Copilot
npx get-shit-done-cc --copilot --global  # 安装到 ~/.github/
npx get-shit-done-cc --copilot --local   # 安装到 ./.github/

# Cursor CLI
npx get-shit-done-cc --cursor --global      # 安装到 ~/.cursor/
npx get-shit-done-cc --cursor --local       # 安装到 ./.cursor/

# Antigravity
npx get-shit-done-cc --antigravity --global # 安装到 ~/.gemini/antigravity/
npx get-shit-done-cc --antigravity --local  # 安装到 ./.agent/

# Augment
npx get-shit-done-cc --augment --global     # 安装到 ~/.augment/
npx get-shit-done-cc --augment --local      # 安装到 ./.augment/

# Trae
npx get-shit-done-cc --trae --global        # 安装到 ~/.trae/
npx get-shit-done-cc --trae --local         # 安装到 ./.trae/

# Cline
npx get-shit-done-cc --cline --global       # 安装到 ~/.cline/
npx get-shit-done-cc --cline --local        # 安装到 ./.clinerules

# 全部运行时
npx get-shit-done-cc --all --global      # 安装到所有对应目录

跳过位置提示用 --global（-g）或 --local（-l）；跳过运行时提示用 --claude、--opencode、--gemini、--kilo、--codex、--copilot、--cursor、--windsurf、--antigravity、--augment、--trae、--cline 或 --all。

开发者安装（源码方式）

git clone <本仓库地址>
cd get-shit-done
node bin/install.js --claude --local

该方式会把改动安装到本仓库的 ./.claude/ 下，便于贡献前验证。本仓库 package.json 的 bin 字段即声明了 get-shit-done-cc 指向 bin/install.js，安装器与后续命令分发均以此为入口。

推荐：跳过权限确认模式

GSD 面向无摩擦自动化设计，文档推荐直接以如下方式启动 Claude Code：

claude --dangerously-skip-permissions

为什么？ 若每执行一次 date、git commit 都要停下来批准（一次会话可能数十次），整套自动化就失去了意义。

替代方案：细粒度权限白名单。如果不想用跳过权限的大旗，可在项目的 .claude/settings.json 中加入如下白名单：

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(wc:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(sort:*)",
      "Bash(grep:*)",
      "Bash(tr:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git tag:*)"
    ]
  }
}

v1.39.0 引入的关键能力（文档快照）

文档以 v1.39.0 为例展示了近期核心特性（仓库另存有对应的 RELEASE-v1.39.0-rc.*.md 系列发布说明）：

  • --minimal 安装档案（别名 --core-only）：仅安装主循环的 6 个技能（new-project、discuss-phase、plan-phase、execute-phase、help、update），不安装 gsd-* 子代理。可将冷启动系统提示词开销从约 12k token 压缩到约 700 token（下降 ≥94%），尤其适合 32K–128K 上下文窗口的本地 LLM 或按 token 计费的 API；
  • /gsd-phase --edit：就地修改 ROADMAP.md 中既有阶段的任意字段（不改变编号与位置）。--force 可跳过确认 diff，并会校验 depends_on 引用、在写入时同步更新 STATE.md；
  • 合并后构建与测试门禁：execute-phase 第 5.6 步优先自动检测 workflow.build_command 配置，未配置时按 Xcode（.xcodeproj）→ Makefile → Justfile → Cargo → Go → Python → npm 的顺序回退；Xcode/iOS 工程自动执行 xcodebuild build 与 xcodebuild test，并行与串行模式均支持；
  • 按运行时选择评审模型：review.models.<cli> 允许 codex、gemini 等外部评审 CLI 独立于规划/执行档案选择模型；
  • 工作流（workstream）配置继承：设置 GSD_WORKSTREAM 后先加载根级 .planning/config.json，再对工作流配置做深合并（冲突时工作流优先），工作流配置中的显式 null 会覆盖根级值；
  • 手动 Canary 发布工作流：.github/workflows/canary.yml 通过 workflow_dispatch 从 dev 分支发布 {base}-canary.{N} 构建到 @canary dist-tag；
  • 技能整合 86 → 59：4 个新的分组技能（capture、phase、config、workspace）吸收 31 个微技能；原 6 个父技能则以 flag 形式吸收包装/子行为，如 update --sync/--reapply、sketch --wrap-up、spike --wrap-up、map-codebase --fast/--query、code-review --fix、progress --do/--next，功能无损。

四、核心工作流：六步把想法变成可验证的代码

已有代码？先执行 /gsd-map-codebase。系统会派生并行代理分析技术栈、架构、约定与注意事项，随后 /gsd-new-project 将在"已经了解代码库"的前提下启动——提问聚焦于新增内容，规划阶段自动沿用既有模式。

GSD 完整生命周期为：新项目初始化 → 逐阶段（讨论 → 规划 → 执行 → 验证）→ 发布/里程碑，完整流程可对照 docs/ko-KR/USER-GUIDE.md 中的流程图。

1. 项目初始化：/gsd-new-project

单命令、单流程。系统会依次：

  1. 提问——不断追问直到完全理解你的想法（目标、约束、技术偏好、边缘用例）；
  2. 研究——并行派生代理做领域调研（可选但推荐）；
  3. 需求——抽取 v1、v2 与"范围外"；
  4. 路线图——生成映射到需求的阶段。

审批路线图后即可开工。产出文件： PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、.planning/research/。

2. 阶段讨论：/gsd-discuss-phase <N> ——"在这里亲手做设计"

路线图每阶段只有一两句话，远不足以支撑"按你想象的方式"交付。讨论阶段在研究与规划启动前锁定期望方向：系统分析该阶段并识别"灰度地带"，按产出类型分类提问：

  • 视觉功能 → 布局、密度、交互、空状态；
  • API/CLI → 响应格式、flag、错误处理、详细程度；
  • 内容系统 → 结构、语气、深度、流转；
  • 组织类任务 → 分组依据、命名、重复项、异常。

对每个选定区域追问直到你满意，产出 CONTEXT.md，直接供后两阶段消费：研究员据此确定调研哪些模式（"想要卡片布局" → 调研卡片组件库）；规划器据此确定哪些决策已敲定（"已决定无限滚动" → 计划中纳入滚动处理）。

讨论越深入，交付越接近真实需求；跳过则得到合理默认值，使用则得到"你的"愿景。产出文件： {phase_num}-CONTEXT.md

偏好"代码库分析优先"？ 在 /gsd-settings 中把 workflow.discuss_mode 设为 assumptions，系统将先读代码、提出"打算做什么及为什么"，只在你认为不对的地方请求修正。详见 docs/ko-KR/workflow-discuss-mode.md。

3. 阶段规划：/gsd-plan-phase <N>

系统执行三步：

  1. 研究——基于 CONTEXT.md 决策调研实现路径；
  2. 规划——生成 2~3 个原子任务计划（XML 结构）；
  3. 验证——对照需求校验计划，循环迭代直至通过。

每个计划都小到可以在全新上下文窗口中执行——无质量衰减，也不会出现"接下来我会更简洁"这类退化信号。产出文件： {phase_num}-RESEARCH.md、{phase_num}-{N}-PLAN.md。

4. 阶段执行：/gsd-execute-phase <N>

  1. 按波次（wave）执行计划——可能时并行、有依赖则串行；
  2. 每个计划一个全新上下文——20 万 token 全部用于纯实现，无历史垃圾堆积；
  3. 每任务一次提交——每个任务都拥有独立的原子提交；
  4. 对照目标验证——确认代码库兑现了该阶段承诺。

去泡杯咖啡，回来就是干净的 git 历史与完成的工作。

波次执行示意（计划按依赖关系分组为"波次"，波内并行、波间串行）：

┌────────────────────────────────────────────────────────────────────┐
│  阶段执行                                                          │
├────────────────────────────────────────────────────────────────────┤
│  波次 1（并行）           波次 2（并行）            波次 3           │
│  ┌─────────┐ ┌─────────┐  ┌─────────┐ ┌─────────┐   ┌─────────┐   │
│  │ 计划 01  │ │ 计划 02  │ →│ 计划 03  │ │ 计划 04  │ → │ 计划 05  │   │
│  │          │ │          │  │          │ │          │   │          │   │
│  │  用户    │ │  产品    │  │  订单    │ │  购物车  │   │  支付    │   │
│  │  模型    │ │  模型    │  │  API     │ │  API     │   │  UI      │   │
│  └─────────┘ └─────────┘  └─────────┘ └─────────┘   └─────────┘   │
│       │           │             ↑           ↑            ↑         │
│       └───────────┴─────────────┴───────────┘            │         │
│        依赖：计划03依赖计划01，计划04依赖计划02，                      │
│              计划05依赖计划03+04                                     │
└────────────────────────────────────────────────────────────────────┘

为什么波次重要： 独立计划 → 同波并行；依赖计划 → 后置波等待；文件冲突 → 串行或合并为同一计划。因此"垂直切片"（如计划 01 端到端打通用户功能）比"水平分层"（计划 01 所有模型、计划 02 所有 API）更容易并行化。产出文件： {phase_num}-{N}-SUMMARY.md、{phase_num}-VERIFICATION.md。

5. 人工验收：/gsd-verify-work <N> ——"在这里确认真的能用"

自动化验证只能证明"代码存在、测试通过"，无法证明功能按你期望的方式工作。系统会：

  1. 抽取可测试成果——"现在应该能做什么"；
  2. 逐条引导你验证——"能用邮箱登录吗？"选是/否，或说明哪里坏了；
  3. 失败自动诊断——派生调试代理定位根因；
  4. 生成已验证的修复计划——可直接重跑。

全部通过则进入下一阶段；若某处损坏，无需亲自调试——用生成的修复计划重跑 /gsd-execute-phase 即可。产出文件： {phase_num}-UAT.md，发现问题时还会生成修复计划。

6. 迭代 → 发布 → 完成 → 下一个里程碑

/gsd-discuss-phase 2
/gsd-plan-phase 2
/gsd-execute-phase 2
/gsd-verify-work 2
/gsd-ship 2                  # 用已验证的成果创建 PR
...
/gsd-complete-milestone
/gsd-new-milestone

也可以让 GSD 自动判断下一步：

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

里程碑完成前持续循环 讨论 → 规划 → 执行 → 验证 → 发布。加快节奏的方式：/gsd-discuss-phase <n> --batch（分组批量回答而非逐题）、--chain（从讨论一路自动链到规划+执行，中途不停顿）。每个阶段都经过用户输入（讨论）、合理调研（规划）、干净执行（执行）、人工验证（验证），上下文全程保鲜。

里程碑全部结束后，/gsd-complete-milestone 归档里程碑并为发布打标签；随后 /gsd-new-milestone 开启下一版本——与 new-project 同款流程但面向既有代码库。

快速模式：/gsd-quick（不需要完整规划的临时任务）

快速模式用更短路径兑现 GSD 承诺（原子提交、状态跟踪）：

  • 同一代理——规划器与执行器合一，质量相同；
  • 可选跳过阶段——默认不启用研究、规划校验器与验证器；
  • 独立跟踪——存放于 .planning/quick/，与阶段体系隔离。

四个 flag 与组合行为：

Flag 作用
--discuss 规划前的轻量讨论，用于识别灰度地带
--research 规划前派生专职研究员，调研实现路径、库选型与注意事项
--full 启用全部阶段：讨论 + 研究 + 计划校验 + 验证
--validate 仅启用计划校验 + 执行后验证

Flag 可组合：--discuss --research --validate 即同时获得讨论、研究、计划校验与验证。使用示例：

/gsd-quick
> 想做什么？"在设置页加一个深色模式开关"

产出文件： .planning/quick/001-add-dark-mode-toggle/PLAN.md、SUMMARY.md

五、为什么有效：四个底层机制

1. 上下文工程（Context Engineering）

Claude Code 在上下文充足时表现卓越，但多数人没有做好上下文管理，GSD 替你完成。系统按"Claude 质量开始衰减"的阈值精心设计各文件尺寸与职责：

文件 职责
PROJECT.md 项目愿景，始终加载
research/ 生态知识（技术栈、功能、架构、注意事项）
REQUIREMENTS.md 带阶段可追溯性的 v1/v2 需求范围
ROADMAP.md 方向与已完成项
STATE.md 决策、阻塞项、当前位置——会话间记忆
PLAN.md 带 XML 结构与验证步骤的原子任务
SUMMARY.md 发生了什么、改了什么，随历史提交
todos/ 为后续工作捕获的想法与任务
threads/ 跨会话任务的持久上下文线程
seeds/ 未来想法仓库，时机成熟自然浮现

所有产物模板均可在 get-shit-done/templates 中查看原始定义。

2. XML 提示词格式化

每个计划都是面向 Claude 优化的结构化 XML，内置精确指令、零猜测、强验证：

<task type="auto">
  <name>创建登录端点</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    用 jose 处理 JWT（不用 jsonwebtoken - 有 CommonJS 问题）。
    对照 users 表校验凭据。
    成功后返回 httpOnly cookie。
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login 返回 200 + Set-Cookie</verify>
  <done>有效凭据返回 cookie，无效凭据返回 401</done>
</task>

3. 多代理编排（Multi-Agent Orchestration）

每个阶段都遵循同一模式：薄编排器派生专职代理并汇总结果传递给下一阶段，编排器自身不执行重活：

阶段 编排器做什么 代理做什么
研究 协调、汇总呈现 4 个研究员并行调研技术栈、功能、架构、注意事项
规划 校验、迭代管理 规划器生成计划，校验器验证，循环至通过
执行 波次分组、进度跟踪 执行器并行实现，各自占用新的 20 万上下文
验证 汇总呈现、路由下一步 验证器对照目标检查代码库，调试器诊断失败

结果： 即便完整跑完一个阶段（深度研究、计划生成与校验、并行执行器写出数千行代码、自动化验证），主上下文窗口仍只占约 30%～40%——真实工作在全新子代理上下文中进行，这是会话全程保持快速与响应灵敏的原因。

4. 原子 Git 提交

每个任务一完成就获得独立提交：

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

收益： git bisect 可精确锁定是哪个任务破坏了什么；可按任务独立 revert；为下一个会话留下清晰的、Claude 可读的历史记录；整个 AI 自动化工作流一目了然。

模块化设计：永不被锁死

  • 在当前里程碑内追加阶段；
  • 在阶段之间插入紧急任务；
  • 完成里程碑后开启全新一轮；
  • 无需整体重建即可调整计划。

六、完整命令参考

核心工作流

命令 作用
/gsd-new-project [--auto] 全量初始化：提问 → 研究 → 需求 → 路线图
/gsd-discuss-phase [N] [--auto] [--analyze] [--chain] 规划前捕获实现决策（--analyze 追加权衡分析，--chain 自动链到规划+执行）
/gsd-plan-phase [N] [--auto] [--reviews] 阶段研究 + 规划 + 验证（--reviews 加载代码库评审结果）
/gsd-execute-phase <N> 按并行波次执行全部计划，完成时验证
/gsd-verify-work [N] 人工用户验收测试
/gsd-ship [N] [--draft] 基于已验证的阶段成果、以自动生成正文创建 PR
/gsd-progress --next 自动推进到下一个逻辑工作流步骤
/gsd-fast <text> 内联琐碎任务——完全跳过规划直接执行
/gsd-audit-milestone 验证里程碑是否达到"完成定义"
/gsd-complete-milestone 归档里程碑、打发布标签
/gsd-new-milestone [name] 开启下一版本：提问 → 研究 → 需求 → 路线图
/gsd-forensics [desc] 对失败的工作流执行事后调查（诊断卡死循环、缺失产物、git 异常）
/gsd-milestone-summary [version] 生成供团队入职与评审使用的综合项目摘要

工作流（Workstream）

命令 作用
/gsd-workstreams list 列出所有工作流及状态
/gsd-workstreams create <name> 创建用于并行里程碑开发的命名空间工作流
/gsd-workstreams switch <name> 切换活动工作流
/gsd-workstreams complete <name> 完成并合并工作流

多项目工作区（Workspace）

命令 作用
/gsd-workspace --new 以仓库副本（worktree 或 clone）创建隔离工作区
/gsd-workspace --list 列出全部 GSD 工作区与状态
/gsd-workspace --remove 移除工作区并清理 worktree

UI 设计

命令 作用
/gsd-ui-phase [N] 为前端阶段创建 UI 设计契约（UI-SPEC.md）
/gsd-ui-review [N] 对已实现前端代码做追溯性六项标准视觉审计

导航

命令 作用
/gsd-progress 现在在哪？下一步是什么？
/gsd-progress --next 自动检测状态并执行下一步
/gsd-help 展示全部命令与使用指南
/gsd-update 预览变更日志并更新 GSD
/gsd-manager 管理多阶段的交互式命令中心

棕地（Brownfield）

命令 作用
/gsd-map-codebase [area] 在 new-project 前分析既有代码库

阶段管理

命令 作用
/gsd-phase 向路线图追加阶段
/gsd-phase --insert [N] 在阶段之间插入紧急任务
/gsd-phase --edit [N] [--force] 就地修改既有阶段任意字段——编号与位置不变
/gsd-phase --remove [N] 移除未来阶段并重排编号
/gsd-discuss-phase --assumptions [N] 规划前确认 Claude 的预期实现方式
/gsd-audit-milestone --fix 为弥合审计发现缺口而创建阶段

会话

命令 作用
/gsd-pause-work 阶段中途停止时生成交接文件（写入 HANDOFF.json）
/gsd-resume-work 从上个会话恢复
/gsd-pause-work --report 生成含已完成工作与结果的会话摘要

代码质量

命令 作用
/gsd-review 当前阶段或分支的跨 AI 同级评审
/gsd-pr-branch 过滤掉 .planning/ 提交、创建干净的 PR 分支
/gsd-audit-uat 审计验证欠账——找出缺失 UAT 的阶段

积压与线程

命令 作用
/gsd-capture --seed <idea> 带触发条件存储想法——时机成熟自动浮现
/gsd-capture --backlog <desc> 把想法加入积压停车场（编号 999.x，置于活动序列之外）
/gsd-review-backlog 评审积压项并提升到活动里程碑或清除过期项
/gsd-thread [name] 持久上下文线程——跨会话任务的轻量知识库

实用工具

命令 作用
/gsd-settings 配置模型档案与工作流代理
/gsd-config --profile <profile> 切换模型档案（quality/balanced/budget/inherit）
/gsd-capture [desc] 捕获想法以备后用
/gsd-capture --list 列出待办想法
/gsd-debug [desc] 利用持久状态做系统性调试
/gsd-do <text> 把自由文本自动路由到恰当的 GSD 命令
/gsd-note <text> 无摩擦想法捕获——追加、列表或提升为待办
/gsd-quick [--full] [--discuss] [--research] 带 GSD 保障的临时任务执行
/gsd-health [--repair] 校验 .planning/ 目录完整性，--repair 自动修复
/gsd-stats 展示项目统计——阶段、计划、需求、git 指标
/gsd-profile-user [--questionnaire] [--refresh] 通过会话分析生成开发者行为档案，用于个性化应答

本仓库的每个 /gsd-* 命令均有对应命令定义文件，详见 commands/gsd 目录；验证/路由逻辑可在 get-shit-done/bin/lib（如 commands.cjs、command-routing-hub.cjs、phase-command-router.cjs、roadmap-command-router.cjs 等）中追踪。

七、配置体系：.planning/config.json

GSD 将项目配置存放于 .planning/config.json：可在 /gsd-new-project 期间设置，也可随时用 /gsd-settings 更新。完整 schema、工作流开关、git 分支选项与各代理模型分析见 docs/ko-KR/USER-GUIDE.md。仓库内置默认模板为 get-shit-done/templates/config.json，schema 定义见 get-shit-done/bin/lib/config-schema.cjs。

核心设置

设置项 取值 默认值 作用
mode yolo、interactive interactive 各阶段自动批准 vs 逐项确认
granularity coarse、standard、fine standard 阶段细粒度——把范围切到多细（阶段 × 计划）

模型档案（Model Profiles）

控制每个代理使用的 Claude 模型，在质量与 token 消耗之间取得平衡：

档案 规划 执行 验证
quality Opus Opus Sonnet
balanced（默认） Opus Sonnet Sonnet
budget Sonnet Sonnet Haiku
inherit 继承 继承 继承

切换档案：

/gsd-config --profile budget

使用非 Anthropic 供应商（OpenRouter、本地模型）或希望沿用当前运行时模型选择（如 OpenCode 的 /model）时，请选 inherit。也可通过 /gsd-settings 配置。

工作流代理（Workflow Agents）

规划/执行期间生成额外代理会提升质量，但消耗更多 token 与时间：

设置项 默认值 作用
workflow.research true 每阶段规划前做领域研究
workflow.plan_check true 执行前校验计划是否达成阶段目标
workflow.verifier true 执行后校验必备项是否交付
workflow.auto_advance false 讨论 → 规划 → 执行自动衔接、不停顿
workflow.research_before_questions false 先做研究再讨论提问
workflow.discuss_mode 'discuss' 讨论模式：discuss（访谈）/assumptions（代码库优先）
workflow.skip_discuss false 自主模式下跳过 discuss-phase
workflow.text_mode false 远程会话专用纯文本模式（无 TUI 菜单）

可用 /gsd-settings 切换，也可按次调用覆盖：/gsd-plan-phase --skip-research、/gsd-plan-phase --skip-verify。

执行相关

设置项 默认值 作用
parallelization.enabled true 独立计划并发执行
planning.commit_docs true 在 git 中跟踪 .planning/
hooks.context_warnings true 显示上下文窗口用量告警

模板文件还展示了更多真实可配置字段，例如 parallelization.max_concurrent_agents（默认 3）、parallelization.min_plans_for_parallel（默认 2）、gates.confirm_* 系列的逐项确认闸门、safety.always_confirm_destructive 等，值得展开自行探索。

Git 分支策略

控制执行时 GSD 处理分支的方式：

设置项 取值 默认值 作用
git.branching_strategy none、phase、milestone none 分支创建策略
git.phase_branch_template string gsd/phase-{phase}-{slug} 阶段分支模板
git.milestone_branch_template string gsd/{milestone}-{slug} 里程碑分支模板

三种策略：

  • none——直接提交到当前分支（GSD 默认行为）；
  • phase——每阶段一个分支，阶段完成时合并；
  • milestone——整个里程碑一个分支，完成时合并。

里程碑完成时，GSD 会建议 squash 合并（推荐）或保留历史合并。

八、安全设计：纵深防御

内建安全强化（自 v1.27 起）

  • 路径遍历防护——所有用户提供的文件路径（--text-file、--prd）都会校验在项目目录内解析；
  • 提示词注入检测——集中式 get-shit-done/bin/lib/security.cjs 模块在用户文本进入规划产物前扫描注入模式；该模块从源码结构看提供了 validatePath、scanForInjection、sanitizeForPrompt、validateShellArg、safeJsonParse 等一整套加固原语；
  • PreToolUse 提示词守卫钩子——gsd-prompt-guard 在写入 .planning/ 前扫描内嵌注入向量（劝阻性，不阻断）；对应实现见 hooks/gsd-prompt-guard.js；
  • 安全 JSON 解析——格式错误的 --fields 参数在损坏状态前即被拦截；
  • Shell 参数校验——用户文本在 shell 插值前被净化；
  • CI 就绪注入扫描器——tests/prompt-injection-scan.test.cjs 扫描全部代理/工作流/命令文件的内嵌注入向量。

为什么需要这些？ GSD 生成的 Markdown 会成为 LLM 系统提示词，因此进入规划产物的用户可控文本即潜在间接提示词注入向量。上述防护从多个层面捕获此类向量。

敏感文件保护

GSD 的代码库映射与分析命令会读文件理解项目。含密钥的文件应加入 Claude Code 的拒绝列表：

  1. 打开 Claude Code 设置（.claude/settings.json 或全局）；
  2. 把敏感文件模式加入拒绝列表：
{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/*)",
      "Read(**/*credential*)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

这样无论运行什么命令，Claude 都无法读取这些文件。

重要：GSD 内建了防密钥提交保护，但纵深防御才是最佳实践——把拒绝读取敏感文件作为第一道防线。

九、故障排查与卸载

安装后找不到命令？

  • 重启运行时以重新加载命令/技能；
  • 检查 ~/.claude/commands/gsd/（全局）或 ./.claude/commands/gsd/（本地）是否有文件；
  • Codex 检查 ~/.codex/skills/gsd-*/SKILL.md（全局）或 ./.codex/skills/gsd-*/SKILL.md（本地）。

命令不按预期工作？

  • 运行 /gsd-help 确认安装；
  • 重新执行 npx get-shit-done-cc 重装。

如何升级？

npx get-shit-done-cc@latest

使用 Docker / 容器环境？ 若读文件因波浪号路径（~/.claude/...）失败，安装前设置 CLAUDE_CONFIG_DIR：

CLAUDE_CONFIG_DIR=/home/youruser/.claude npx get-shit-done-cc --global

容器中使用绝对路径而非可能无法正确展开的 ~。

卸载

# 全局安装
npx get-shit-done-cc --claude --global --uninstall
npx get-shit-done-cc --opencode --global --uninstall
npx get-shit-done-cc --gemini --global --uninstall
npx get-shit-done-cc --kilo --global --uninstall
npx get-shit-done-cc --codex --global --uninstall
npx get-shit-done-cc --copilot --global --uninstall
npx get-shit-done-cc --cursor --global --uninstall
npx get-shit-done-cc --antigravity --global --uninstall
npx get-shit-done-cc --trae --global --uninstall

# 本地安装（当前项目）
npx get-shit-done-cc --claude --local --uninstall
npx get-shit-done-cc --opencode --local --uninstall
npx get-shit-done-cc --gemini --local --uninstall
npx get-shit-done-cc --kilo --local --uninstall
npx get-shit-done-cc --codex --local --uninstall
npx get-shit-done-cc --copilot --local --uninstall
npx get-shit-done-cc --cursor --local --uninstall
npx get-shit-done-cc --antigravity --local --uninstall
npx get-shit-done-cc --trae --local --uninstall

在保留其他设置不变的前提下，移除 GSD 的全部命令、代理、钩子与配置。

十、多运行时与生态

OpenCode、Gemini CLI、Kilo、Codex 现均通过 npx get-shit-done-cc 获得一等支持。这些社区移植是最早的多运行时支持探路者——例如最早一批 OpenCode 适配与 Gemini 适配项目（后者已归档），如今相关能力已被官方安装器统一收纳，Cline 则继续通过 .clinerules 接入。

延伸阅读

总结： GSD 的本质，是把"规范驱动开发 + 上下文工程 + 多代理编排"系统化地封装成几条命令，让个人开发者无需伪装成企业组织，也能获得可规划、可执行、可验证、可追溯的 AI 软件开发闭环。按文档中的说法——复杂度被藏进系统内部，留在用户工作流之外的只有简洁的命令与可信的结果。

get-shit-done
A 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
登录后查看全文

相关内容推荐

1 GSD 入门实战指南：用 get-shit-done-cc 构建可靠的 AI 规格驱动开发工作流2 get-shit-done（GSD）实战指南：为 Claude Code 等 AI 编码代理打造的元提示、上下文工程与规格驱动开发系统3 GET SHIT DONE（GSD）完全指南：为 Claude Code 打造的轻量级上下文工程与规格驱动开发系统4 GSD Issue 驱动编排实战：用现有原语把单个 Issue 推进成可合并 PR5 get-shit-done 模型解析单一事实源改造：Model Catalog 模块如何终结 resolve-model 的 SDK/CLI 模型漂移（3229）6 get-shit-done（GSD）系统架构解析：多 Agent 元提示编排、文件式状态机与多运行时抽象7 把 Plan 阶段搬到云端：get-shit-done 的 gsd:ultraplan-phase 命令解析8 GSD（get-shit-done）全功能参考指南：85 项特性详解与规格驱动研发工作流9 get-shit-done（GSD）命令全参考：从阶段工作流到诊断与配置的完整命令手册10 get-shit-done（GSD）命令参考全解析：语法、核心工作流与运行时派发指南
热门项目推荐
相关项目推荐

热门内容推荐

1 编程实践项目探索指南：从零构建技术能力体系2 技术解构式学习：从0到1构建你的编程知识体系3 构建自己的技术世界：build-your-own-x项目的实践探索指南4 解锁编程技能的实践之旅：从零构建你的技术世界5 技术实践探索：从零开始构建核心系统的实践指南6 亲手锻造技术引擎：从0到1构建核心系统的实践指南

最新内容推荐

聚合模型与生物标志物评估：基于 scientific-agent-skills 中 clinical-decision-support 技能的无个体级验证方法学与配套脚本全解析CodeWhale 持久化架构实录：从碎片化 JSON 存储走向统一 SQLite 的迁移蓝图（RFC 2189 解读）LocalAI 的 AI 辅助开发协作指南：Agent 指令入口、署名政策与仓库工程公约全解析使用 prettier-plugin-slidev 为 Slidev 幻灯片 Markdown 接入代码格式化codebase-memory-mcp 上手指南与深度剖析：把代码库变成毫秒级持久化知识图谱的 MCP 服务器Ruff 仓库中的 ty 规则 invalid-frozen-dataclass-subclass：冻结 dataclass 非法继承的判定、诊断与修复LibreChat Langfuse Fanout 网关：多租户与中心化 Langfuse 追踪/媒体并行导出的部署实践DoorDash 前端面试真题全解析：fetch/渲染电面、图片轮播 onsite 与消息类系统设计备考指南（front-end-interview-handbook）kitty notify kitten 使用指南：在 shell 与 SSH 会话中弹出系统桌面通知DeepSpeed ZeRO 通信优化深度解析：用 reduce-scatter 分区感知规约替代 all-reduce

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.14 K
2.75 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
857
1.35 K
docsdocs
暂无描述
Markdown
897
5.81 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
531
596
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
920
1.84 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.79 K
1.02 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.36 K
1.46 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓，支持在线互动运行、边学边练，提供教程、示例与优化方案，一站式助力昇腾开发者快速上手。
Jupyter Notebook
1.02 K
519
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR（Multi-Level Intermediate Representation）构建的，面向昇腾亲和算子编译时使用的中间表示，提供昇腾完备表达能力，通过编译优化提升昇腾AI处理器计算效率，支持通过生态框架使能昇腾AI处理器与深度调优
C++
548
390