github link：https://github.com/gsd-build/get-shit-done/blob/main/README.zh-CN.md
安装命令：npx get-shit-done-cc@latest
更新包：npx get-shit-done-cc@latest

某种原因上来说GET SHIT DONE已经不是单纯的skills合计，它官方的说明是一个轻量但强大的元提示、上下文工程与规格驱动开发系统。

在安装的时候，是以skills的形式安装到code agent上的，也就是claude code、codex、cursor等等，都可以用。

安装后可这样验证：

Claude Code / Gemini / Copilot / Antigravity：/gsd-help
OpenCode / Kilo / Augment / Trae / CodeBuddy：/gsd-help
Codex：$gsd-help
Cline：GSD 通过 .clinerules 安装 — 检查 .clinerules 是否存在

这边推荐claude code和codex用，因为别的code agent已经用很重的提示词了，还用gsd的话，token止不住的同时，重点token也会被稀释。用这俩的时候，直接开codex --yolo 和claude --allow-dangerously-skip-permissions ，能省去很多麻烦。

整个代码库都遵循SGD原则，目的就是对齐需求——更新文档——plan——dev。下面我们分别从0到1和1到100来分开说一下我是怎么用的。

从0到1开发

此时项目是空的，那么需要先new一下：

/gsd-new-project

注意，codex是$ 的，不是/ ，后面默认说是/ 了。

new的时候就会开始向你提问来梳理需求，构建路线图和文档。

然后就是三部曲，非常常用：

/gsd-discuss-phase 1 /gsd-plan-phase 1 /gsd-execute-phase 1 /gsd-verify-work 1

/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 [name] # 开始下一个

可以看出，其实就是对phase进行讨论——plan——execute——验证，如果有多个plan，它会根据依赖关系来分wave，然后并行执行。

<text-diagram data-type=“mermaid” data-content=“flowchart LR T["PHASE EXECUTION"]

subgraph W1[&quot;Wave 1&quot;]
  P1[&quot;Plan 01&lt;br/&gt;User Model&quot;]
  P2[&quot;Plan 02&lt;br/&gt;Product Model&quot;]
end

subgraph W2[&quot;Wave 2&quot;]
  P3[&quot;Plan 03&lt;br/&gt;Orders API&quot;]
  P4[&quot;Plan 04&lt;br/&gt;Cart API&quot;]
end

subgraph W3[&quot;Wave 3&quot;]
  P5[&quot;Plan 05&lt;br/&gt;Checkout UI&quot;]
end

T --&gt; P1
T --&gt; P2
P1 --&gt; P3
P2 --&gt; P4
P3 --&gt; P5
P4 --&gt; P5">flowchart LR
T["PHASE EXECUTION"]

subgraph W1["Wave 1"]
  P1["Plan 01&lt;br/&gt;User Model"]
  P2["Plan 02&lt;br/&gt;Product Model"]
end

subgraph W2["Wave 2"]
  P3["Plan 03&lt;br/&gt;Orders API"]
  P4["Plan 04&lt;br/&gt;Cart API"]
end

subgraph W3["Wave 3"]
  P5["Plan 05&lt;br/&gt;Checkout UI"]
end

T --&gt; P1
T --&gt; P2
P1 --&gt; P3
P2 --&gt; P4
P3 --&gt; P5
P4 --&gt; P5</text-diagram><p style="">我更习惯的是，new完项目之后直接next：</p><pre><code>/gsd-new-project

/gsd-next # 自动检测并执行下一步，但是这样会少了询问的部分，建议细看输出

一路next即可，非常方便。

当我们完成了第一个版本的代码的时候，通常我们会新建一个repo，然后把代码git到main上，这其实是不对的，应该是先git到develop分支，main分支可以先空着，只有当一个版本出现了，才会移到main分支。

那么我们会对每个修改先新建一个issues，声明背景，问题，todo和目标。这一步主要的目的就在于分割问题，使其成为meta的子问题，如果问题分割不好，那么pr会非常的混乱。

常见的issues：

feat: 新功能
fix: 修复 bug
refactor: 重构，但不新增功能也不修具体 bug
test: 测试相关

话又说回来，当switch过去对应的分支了之后，就可以通过gsd进行进一步的开发，详细就是1到100的开发了。

1到100开发

从1到100，之类拼的其实不是垂类的专业性，而是多分支的管理能力，假如说已经是一个现成的项目了，可以这样初始化：

/gsd-map-codebase	在 new-project 前分析现有代码库

对于代码的优化，通常一个项目需要多个人配合，所以gsd可以设置多个工作区，它最牛逼的地方下面会解释的：

命令	作用
`/gsd-new-workspace`	创建隔离工作区，包含仓库副本（worktree 或 clone）
`/gsd-list-workspaces`	显示所有 GSD 工作区及其状态
`/gsd-remove-workspace`	移除工作区并清理 worktree

创建了隔离工作区之后，新建一个project，project内可以并发多条执行流：

命令	作用
`/gsd-workstreams list`	显示所有工作流及其状态
`/gsd-workstreams create <name>`	创建命名空间工作流，用于并行里程碑工作
`/gsd-workstreams switch <name>`	切换当前活跃工作流
`/gsd-workstreams complete <name>`	完成并合并工作流

他们的关系是这样的：


┌─────────────────────────────────────────────┐
│  Workspace (gsd-new-workspace)              │  ← 物理隔离
│  独立目录 + 独立 worktree + 独立 .planning/ │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │  Project (gsd-new-project)            │  │  ← 项目规划
│  │  一个 repo 的 roadmap / phases / plans│  │
│  │                                       │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │  Workstream (gsd-workstreams)   │  │  │  ← 并行执行
│  │  │  项目内的并行工作流             │  │  │
│  │  │  Stream A: Phase 1-3            │  │  │
│  │  │  Stream B: Phase 4-6            │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

这就非常明确我们的workflow了，这里需要注意一点，就是claude code的上下文管理需要跟issues对齐，而一个issues是和一个git的branch对齐的，一个branch需要一个独立的空间，而workspace的本质是开物理隔离环境（worktree + 独立分支），在~/gsd-workspaces/<name>/里，所以这里应该是：1 Issue = 1 Workspace = 1 窗口 = 1 PR。

  ┌─────────────────────────────────────────────────┐
│  GitHub 上有 3 个 Open Issues                    │
└────────────────────┬────────────────────────────┘
│
▼
终端 1: /gsd-new-workspace –name feat-seedance2
终端 2: /gsd-new-workspace –name fix-timeout
终端 3: /gsd-new-workspace –name feat-subtitle
│
▼
每个窗口各自 cd 进自己的 workspace:
│
┌────────────┼────────────┐
▼            ▼            ▼
/gsd-new-project  /gsd-new-project  /gsd-new-project
│            │            │
roadmap 里       roadmap 里       roadmap 里
只管这一个       只管这一个       只管这一个
Issue 的需求     Issue 的需求     Issue 的需求
│            │            │
/gsd-execute  /gsd-execute  /gsd-execute
│            │            │
/gsd-ship      /gsd-ship     /gsd-ship
│            │            │
PR #9         PR #10           PR #11

project就是这个 Issue 的规划（roadmap、phases）.
如果issues分割的足够细致，就不需要workstreams 了，直接workspace足够了，除非是一个issues比较大，有多个功能，那么可以用workstream create进行功能的分割测试，最后再合在一起workstreams complete进行大测试，通常来说一个workspace足够了。
pr可以/gsd-ship 自动生成。

简单 Issue

假如说就是一个issues

# 终端 1 /gsd-new-workspace –name <branch> –branch fix/<branch> –repos . –path ./gsd-workspaces/<branch> –strategy worktree → 默认在./workspace/<branch>，不然window默认会飞到C盘去，非常危险# –strategy worktree 是完整的工作目录，只是 .git 对象库共享，所以更轻量# 注意，fix是前缀，可以换成feat、test等，详情请看github si all you need# cd ./gsd-workspaces/<branch> # workflow 的 next steps 也是明确写 cd “$TARGET_PATH” /gsd-new-project → ROADMAP: Phase 1 一个就够了# cd <repo-name> 再 cd 到 repo 目录是为了对齐git命令# /gsd-execute-phase 1 → 每个 task 自动 commit 到 workspace/<branch># /gsd-pr-branch develop 拿当前分支相对 develop 的变更,重建出一个干净的 PR 分支# workspace/<branch># └─ workspace/<branch>-pr#

git push origin <branch>-pr

复杂 Issue

假如说有多个issues同时推进，那就可以在一个终端里多建几个workspace，然后再多开code agent去各自的文件夹内进行project：

 # 终端 1
/gsd-new-workspace –name <branch1> –branch fix/<branch1> –repos . –auto –path ./gsd-workspaces/<branch1> –strategy worktree
终端 2#
/gsd-new-workspace –name <branch2> –branch fix/<branch2> –repos . –auto –path ./gsd-workspaces/<branch2> –strategy worktree
终端 3#
/gsd-new-workspace –name <branch3> –branch fix/<branch3> –repos . –auto –path ./gsd-workspaces/<branch3> –strategy worktree
然后分别进入各自 repo 目录工作：
终端 1#
cd ./gsd-workspaces/<branch1>
/gsd-new-project
cd ./<branch1>
当前分支: workspace/<branch1>#
终端 2#
cd ./gsd-workspaces/<branch2>
/gsd-new-project
cd ./<branch2>
当前分支: workspace/<branch2>#
终端 3#
cd ./gsd-workspaces/<branch3>
/gsd-new-project
cd ./<branch3>
当前分支: workspace/<branch3>

需要注意的是，这里处理一个issues需要一个独立的文件夹放置一份完整代码，不可能在同一份代码上来做并行的开发，这样很容易出现问题，多份代码彼此独立，这样出现错误也不会干扰别的项目进行。

而构建gsd-workspaces文件夹在branch的上面也是因为

这里要插一嘴，有个区别是如果你新加一个track参数，那么新分支的起点就不是origin，而是develop

git switch -c <你的新分支名> –track origin/develop

这是不对的，因为名字通常就代表了顺序：

feature/xxx -> origin/feature/xxx#
develop     -> origin/develop
main        -> origin/main

这时候聪明的你要问了，哎要是换了个电脑dev，别人想一起github dev等等，我怎么办呢，其实有如下的命令：

/gsd-stats	显示项目统计——阶段、计划、需求、git 指标
/gsd-pause-work  停止work，保存状态
/gsd-resume-work	从上一次会话恢复
/gsd-session-report	生成会话摘要，包含已完成工作和结果
/gsd-progress	我现在在哪？下一步是什么？

所以推荐的过程是：

  1. A 创建自己的 branch / workstream / workspace
2. A 在这个 branch 上做 GSD 流程
3. A 中途停下前执行 /gsd-pause-work
4. A push branch 到 GitHub
5. B checkout 同一个 branch
6. B 执行 /gsd-resume-work
7. B 接着 plan / execute / verify

故此只需要A停止work：/gsd-pause-work ，然后就会有.planning/HANDOFF.json和.continue-here.md 的交接文件的存储，它会记录：

当前 phase / plan / task
已完成什么
剩余什么
决策是什么
blocker 是什么
哪些需要人工动作
下一个具体动作是什么

B 拉下 A 的 branch 后，在那个分支上运行 /gsd-resume-work。命令会优先检查：

.planning/HANDOFF.json
.continue-here.md
有没有 PLAN.md 没对应 SUMMARY.md
有没有中断的 agent
STATE.md / PROJECT.md 当前状态

然后gsd直接告诉B：

当前在第几 phase
第几个 plan
哪个 task 做到一半
blocker 是什么
下一步最合理的动作是什么

vibe coding系列：（二）GET SHIT DONE

从0到1开发

1到100开发

简单 Issue

→ 默认在./workspace/<branch>，不然window默认会飞到C盘去，非常危险

–strategy worktree 是完整的工作目录，只是 .git 对象库共享，所以更轻量

注意，fix是前缀，可以换成feat、test等，详情请看github si all you need

→ ROADMAP: Phase 1 一个就够了

再 cd 到 repo 目录是为了对齐git命令

→ 每个 task 自动 commit 到 workspace/<branch>

拿当前分支相对 develop 的变更,重建出一个干净的 PR 分支

workspace/<branch>

└─ workspace/<branch>-pr

复杂 Issue

终端 2

终端 3

终端 1

当前分支: workspace/<branch1>

终端 2

当前分支: workspace/<branch2>

终端 3

`当前分支: workspace/<branch3>`