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来分开说一下我是怎么用的。
此时项目是空的，那么需要先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，然后并行执行。
我更习惯的是，new完项目之后直接next：
/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，之类拼的其实不是垂类的专业性，而是多分支的管理能力，假如说已经是一个现成的项目了，可以这样初始化：
/gsd-map-codebase 在 new-project 前分析现有代码库对于代码的优化，通常一个项目需要多个人配合，所以gsd可以设置多个工作区，它最牛逼的地方下面会解释的：
创建了隔离工作区之后，新建一个project，project内可以并发多条执行流：
他们的关系是这样的：
┌─────────────────────────────────────────────┐
│ 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 #11project就是这个 Issue 的规划（roadmap、phases）.
如果issues分割的足够细致，就不需要workstreams 了，直接workspace足够了，除非是一个issues比较大，有多个功能，那么可以用workstream create进行功能的分割测试，最后再合在一起workstreams complete进行大测试，通常来说一个workspace足够了。
pr可以/gsd-ship 自动生成。
假如说就是一个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假如说有多个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 是什么
下一步最合理的动作是什么