GET SHIT DONE  搞定它！

一款轻量又强大的元提示、上下文工程和规范驱动开发系统，专为 Claude Code、OpenCode、Gemini CLI 和 Codex 打造。

专治 Claude 的“上下文腐化”问题——就是那种随着对话越堆越长，回答质量直线下滑的糟心事儿。

npx get-shit-done-cc@latest

支持 Mac、Windows 和 Linux。

“只要你清楚自己想要什么，这玩意儿绝对能给你整出来，不跟你玩虚的。”

“SpecKit、OpenSpec 和 Taskmaster 我都试过——这个给我的效果最顶。”

“这绝对是我 Claude Code 里最给力的插件，没有之一。一点不花里胡哨，就是实打实地帮你把活儿干完。”

深受 Amazon、Google、Shopify 和 Webflow 工程师的信赖。

Why I Built This · How It Works · Commands · Why It Works · User Guide
我为什么打造它 · 它是如何工作的 · 命令详解 · 为什么它有效 · 用户指南

---

Why I Built This

我是个独立开发者。代码不是我写的——是 Claude Code 在写。

市面上确实有其他基于规格的开发工具，比如 BMAD、Speckit… 但它们似乎都把简单的事情搞得太复杂了（什么冲刺仪式、故事点、干系人同步会、复盘会、Jira 工作流），要么就是对你正在构建的东西缺乏真正的宏观理解。我又不是一家 50 人的软件公司。我不想玩那些“企业过家家”的把戏。我只是个想做出能用的好东西的创作者。

所以，我打造了 GSD。复杂性都在系统内部，而不是在你的工作流里。幕后是：上下文工程、XML 提示词格式化、子智能体编排、状态管理。而你看到的只是：几个拿来就能用的命令。

这个系统为 Claude 提供了完成工作并验证所需的一切。我信赖这个工作流。它就是能把活儿干得漂亮。

这就是 GSD。没有那些企业角色扮演的虚头巴脑。它就是一个极其高效的系统，能让你持续地用 Claude Code 构建出很酷的东西。

— TÂCHES  — 任务清单

---

Vibecoding 这玩意儿名声可不咋地。你描述需求，AI 生成代码，结果拿到手一堆乱七八糟的垃圾代码，规模一上来就散架。

GSD 就是来解决这个问题的。它是一层上下文工程，能让 Claude Code 变得靠谱。你只管描述想法，系统会自动提取所需信息，然后让 Claude Code 开工干活。

---

Who This Is For  适合谁用

适合那些只想说清楚自己要什么、然后就能得到正确构建结果的人——不用非得装得像在运营一个 50 人的工程团队。

---

Getting Started  快速上手

npx get-shit-done-cc@latest

安装程序会提示你选择：

1. 运行环境 — Claude Code、OpenCode、Gemini、Codex，或者全都要
2. 安装位置 —— 全局（所有项目）还是仅限本地（当前项目）

Verify with:  用这个来验证：

• Claude Code / Gemini: /gsd:help
• OpenCode: `/gsd-help
• Codex: $gsd-help

 

Note  注意

Codex 安装用的是技能（ skills/gsd-*/SKILL.md ），而不是自定义提示词。

Staying Updated  保持更新

GSD 更新迭代超快，记得定期更新哦：

npx get-shit-done-cc@latest

非交互式安装（Docker、CI、脚本）

# Claude Code
npx get-shit-done-cc --claude --global   # Install to ~/.claude/
npx get-shit-done-cc --claude --local    # Install to ./.claude/

# OpenCode (open source, free models)
npx get-shit-done-cc --opencode --global # Install to ~/.config/opencode/

# Gemini CLI
npx get-shit-done-cc --gemini --global   # Install to ~/.gemini/

# Codex (skills-first)
npx get-shit-done-cc --codex --global    # Install to ~/.codex/
npx get-shit-done-cc --codex --local     # Install to ./.codex/

# All runtimes
npx get-shit-done-cc --all --global      # Install to all directories

Use --global (-g) or --local (-l) to skip the location prompt.

Use --claude, --opencode, --gemini, --codex, or --all to skip the runtime prompt.

Development Installation 开发环境安装

Clone the repository and run the installer locally:

git clone https://github.com/glittercowboy/get-shit-done.git
cd get-shit-done
node bin/install.js --claude --local

Installs to ./.claude/ for testing modifications before contributing.

推荐：直接跳过权限确认模式

GSD 的设计初衷就是实现丝滑的自动化。运行 Claude Code 时建议用这个模式：

claude --dangerously-skip-permissions

Tip

这才是 GSD 的正确打开方式——如果中途要停下来点五十次确认 date 和 git commit ，那可就本末倒置了。

备选方案：精细化权限设置

If you prefer not to use that flag, add this to your project’s .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:*)"
    ]
  }
}

---

How It Works

已经有现成的代码了？那就先运行一下 /gsd:map-codebase 吧。它会派出一堆并行代理，把你的技术栈、架构、代码规范和潜在问题都分析个遍。这样一来， /gsd:new-project 就能彻底摸透你的代码库了——之后它提的问题都会聚焦在你**要新增什么功能**上，而且做规划时也会自动套用你已有的代码模式。

1. 初始化项目

/gsd:new-project

一个命令，一套流程。这个系统会：

1. 刨根问底式提问 —— 不把你的想法彻底摸透绝不罢休（目标、限制条件、技术偏好、边界情况通通问清楚）
2. 调研阶段 — 会派出一堆并行智能体去摸清领域情况（可选但强烈推荐）
3. 需求梳理 — 帮你理清哪些是 v1 版要做的、哪些留给 v2 版、还有哪些直接先放一边
4. 路线图规划 — 根据需求制定出分阶段实施计划

等你点头确认路线图后，就可以撸起袖子开干了！

创建了： PROJECT.md 、 REQUIREMENTS.md 、 ROADMAP.md 、 STATE.md 、 .planning/research/

---

2. 讨论阶段

/gsd:discuss-phase 1

这里就是你大展身手、打磨实现的地方。

你的路线图每个阶段就一两句话，这哪够啊，根本没法按你想象的样子去构建。这一步就是在开始调研或规划之前，先摸清你的偏好。

系统会分析当前阶段，并根据要构建的内容，揪出那些模糊不清的地方：

• 视觉特性 → 界面布局、信息密度、交互方式、空状态处理
• API/CLI 这块儿 → 响应格式怎么定、命令行参数怎么配、错误处理要到位、日志输出详略得宜
• 内容系统 → 结构、语气、深度、流畅度
• 组织任务 → 分组标准、命名规范、重复项处理、例外情况

你每选一个方向，它都会一直追问，直到你满意为止。然后，它生成的输出——也就是 CONTEXT.md ——会直接作为接下来两步的输入。

1. 研究员一看就懂——知道该琢磨啥模式（比如“用户想要卡片布局”，那就去研究卡片组件库）
2. 规划师一看就懂——知道哪些决策已经板上钉钉（比如“无限滚动方案已定”，那计划里就得把滚动处理安排上）

你越深入挖掘，系统就越能帮你实现你真正想要的东西。偷个懒，也能得到不错的默认效果；但只要你肯花心思，它就能把你的构想变成现实。

创建于： {phase_num}-CONTEXT.md

---

3. 规划阶段

/gsd:plan-phase 1

这套系统：

1. 调研阶段 — 根据你的 CONTEXT.md 决策，研究如何实现这个阶段
2. 规划阶段 — 用 XML 结构创建 2-3 个原子任务计划
3. 验证阶段 — 对照需求检查计划，循环直到全部通过

每个计划都足够精简，能在全新的上下文窗口中执行。没有性能衰减，也不会出现“我现在要更简洁了”这种状况。

创建了： {phase_num}-RESEARCH.md 和 {phase_num}-{N}-PLAN.md

---

4. 执行阶段

/gsd:execute-phase 1

这套系统：

1. 任务执行分波次推进——能并行就并行，有依赖就按顺序来
2. 每个计划都有全新上下文——整整 20 万 tokens 专供实现，绝不积攒垃圾。
3. 每个任务独立提交——每项任务都有自己原子级的 commit
4. 对照目标进行验证 —— 确保代码库能兑现当前阶段承诺的功能

走开一会儿，回来活儿就干完了，git 历史还清清爽爽的。

How Wave Execution Works:
Wave Execution 是怎么运作的：

任务计划会根据依赖关系分成不同的“波次”。同一波次里的任务可以同时进行，而波次之间则按顺序执行。

┌─────────────────────────────────────────────────────────────────────┐
│  PHASE EXECUTION                                                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  WAVE 1 (parallel)          WAVE 2 (parallel)          WAVE 3       │
│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐ │
│  │ Plan 01 │ │ Plan 02 │ →  │ Plan 03 │ │ Plan 04 │ →  │ Plan 05 │ │
│  │         │ │         │    │         │ │         │    │         │ │
│  │ User    │ │ Product │    │ Orders  │ │ Cart    │    │ Checkout│ │
│  │ Model   │ │ Model   │    │ API     │ │ API     │    │ UI      │ │
│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘ │
│       │           │              ↑           ↑              ↑       │
│       └───────────┴──────────────┴───────────┘              │       │
│              Dependencies: Plan 03 needs Plan 01            │       │
│                          Plan 04 needs Plan 02              │       │
│                          Plan 05 needs Plans 03 + 04        │       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Why waves matter:

• 独立任务 → 同一批次 → 并行开搞
• 依赖任务 → 后续批次 → 等前置条件
• 文件冲突了？那就按顺序来规划，或者干脆用同一个方案搞定！

这就是为什么“垂直切片”（方案一：端到端用户功能）比“水平分层”（方案一：所有模型，方案二：所有 API）更能并行推进。

创建了： {phase_num}-{N}-SUMMARY.md 和 {phase_num}-VERIFICATION.md

---

5. 验收成果

/gsd:verify-work 1

这一步就是来确认功能真的跑通了。

自动化验证能确保代码存在且测试通过。但功能的效果符合你的预期吗？现在正是你亲自上手体验的好机会。

这套系统：

1. 提炼出可测试的交付成果——你现在应该能做什么
2. 一步步带你过流程——“能用邮箱登录吗？” 是/否，或者描述哪里出了问题
3. 自动诊断故障——派发调试代理找出根本原因
4. 生成经过验证的修复方案——随时可以立即重新执行

如果一切顺利通过，你就继续往下走。要是哪里出问题了，你根本不用自己动手调试——直接再跑一遍 /gsd:execute-phase 就行，它会带着自己生成的修复方案搞定。

生成： {phase_num}-UAT.md ，如果发现问题还会附带修复方案

---

6. Repeat → Complete → Next Milestone

6. 循环往复 → 搞定收工 → 奔赴下一个里程碑

/gsd:discuss-phase 2
/gsd:plan-phase 2
/gsd:execute-phase 2
/gsd:verify-work 2
...
/gsd:complete-milestone
/gsd:new-milestone

循环进行讨论 → 规划 → 执行 → 验证，直到里程碑完成为止。

每个阶段都少不了你的参与（讨论）、充分的调研（规划）、利落的执行（实施），还有人工把关（验证）。这样一来，上下文永远保持鲜活，产出质量也始终在线。

所有阶段搞定后， /gsd:complete-milestone 就会归档这个里程碑，并打上发布标签。

接着 /gsd:new-milestone 就马不停蹄地开启下一个版本——流程跟 new-project 一模一样，只不过这次是针对你现有的代码库。你只管描述接下来想开发什么，系统就会去研究相关领域，你来敲定需求范围，它立马生成一份全新的路线图。每个里程碑都是一个清爽利落的循环：定义 → 构建 → 交付。

---

Quick Mode

/gsd:quick

处理那些不需要完整规划的临时任务。

快速模式让你用更快的路子，照样能享受到 GSD 的保障（原子提交、状态追踪）：

• 还是那套黄金搭档——Planner 加 executor，品质一如既往地稳。
• 省掉那些可有可无的步骤——不用调研，不用计划检查，也不用验证。
• 独立追踪 —— 它归在 .planning/quick/ 管，不跟阶段走。

适用场景：修 bug、加小功能、改配置、处理一次性任务。

/gsd:quick
> What do you want to do? "Add dark mode toggle to settings"

创建了： .planning/quick/001-add-dark-mode-toggle/PLAN.md 和 SUMMARY.md

---

Why It Works

Context Engineering  上下文工程

Claude Code 这玩意儿，只要给足它上下文，那能力简直逆天。可惜啊，大多数人根本做不到。

但 GSD 帮你全搞定了：

File  文件	What it does  它的本事
PROJECT.md	Project vision, always loaded 项目愿景，随时在线
research/	Ecosystem knowledge (stack, features, architecture, pitfalls) 生态知识（技术栈、功能特性、架构设计、踩坑经验）
REQUIREMENTS.md	Scoped v1/v2 requirements with phase traceability 带阶段追溯的 v1/v2 需求范围
ROADMAP.md	Where you’re going, what’s done 目标在哪，进度如何
STATE.md	Decisions, blockers, position — memory across sessions 决策、卡点、当前状态 —— 跨会话记忆
PLAN.md	Atomic task with XML structure, verification steps 带 XML 结构和验证步骤的原子任务
SUMMARY.md	What happened, what changed, committed to history 发生了什么，改了哪些，统统记入历史存档
todos/	Captured ideas and tasks for later work 灵感和任务先记下来，回头再干

根据 Claude 表现下滑的临界点来设定篇幅上限。别超限，就能一直稳拿高质量输出。

XML Prompt Formatting  XML 提示词格式化

每个计划都是为 Claude 精心优化的结构化 XML

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

指令精准，无需猜测，验证机制已内置。

Multi-Agent Orchestration 多智能体协同编排

每个阶段都遵循同一套模式：一个轻量级的编排器会启动专门的智能体，收集结果，然后流转到下一步。

Stage  阶段	Orchestrator does  Orchestrator 负责统筹调度，	Agents do  Agents 负责具体执行，
Research  深入研究，	Coordinates, presents findings 并协调各方，最终呈现研究成果	4 parallel researchers investigate stack, features, architecture, pitfalls 四个研究员齐头并进，分别摸清技术栈、功能特性、架构设计和潜在坑点。
Planning  规划环节	Validates, manages iteration 边验证边管理迭代过程	Planner creates plans, checker verifies, loop until pass 由 Planner 来制定计划，Checker 负责审核，反复循环直到通过为止。
Execution  执行阶段	Groups into waves, tracks progress 把任务分组分批推进，全程跟踪进度	Executors implement in parallel, each with fresh 200k context 多个执行器并行处理，每个都拥有全新的 200k 上下文
Verification  验证	Presents results, routes next 呈现结果，规划下一步。	Verifier checks codebase against goals, debuggers diagnose failures 验证器负责对照目标检查代码库，调试器则专门诊断故障

这个调度器从不干重活。它负责派活儿（生成子代理），然后等着，最后把结果整合起来。

效果就是：哪怕你跑完一整个阶段——深度调研、制定并验证多个方案、通过并行执行器写出成千上万行代码、自动对照目标进行验证——你的主上下文窗口占用率也才 30-40%。所有繁重工作都在全新的子代理上下文中完成。你的整个会话始终保持快速响应，一点儿不卡顿。

Atomic Git Commits  原子级 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 能精准定位出问题的任务，每个任务都能单独回滚。这样 Claude 在后续会话里就有清晰的历史记录可查，AI 自动化工作流的可观测性也大大提升了。

每次提交都像外科手术一样精准，有迹可循，而且意义非凡。

Modular by Design  模块化设计，灵活随心

• 给当前里程碑添加阶段
• 紧急任务？随时插队安排
• 搞定一个里程碑，清清爽爽开新篇
• 随时调整计划，无需推倒重来

你永远不会被框死。系统会灵活适应。

---

Commands

Core Workflow

Command  命令	What it does  它的本事
/gsd:new-project [--auto]	Full initialization: questions → research → requirements → roadmap 完整初始化流程：先提问，再调研，然后明确需求，最后制定路线图。
/gsd:discuss-phase [N] [--auto]	在动手规划之前，先把实现决策敲定下来。
/gsd:plan-phase [N] [--auto]	每个阶段都遵循：调研、规划、验证三步走
/gsd:execute-phase <N>	所有计划并行推进，完成后统一验收
/gsd:verify-work [N]	手动验收测试¹
/gsd:audit-milestone	确认里程碑是否达到“完成”标准
/gsd:complete-milestone	把里程碑归档，打个发布标签。
/gsd:new-milestone [name]	启动下一版本：提问 → 调研 → 需求 → 路线图

Navigation  导航

Command  命令	What it does  它的本事
/gsd:progress	我现在在哪儿？接下来该干嘛？
/gsd:help	显示所有命令和使用指南
/gsd:update	用更新日志预览来升级你的 GSD 体验
/gsd:join-discord	快来加入 GSD 的 Discord 社区一起玩吧

Brownfield  搞定遗留项目（Brownfield）

Command  命令	What it does  它的本事
/gsd:map-codebase	开新项目前，先好好分析一下现有的代码库

Phase Management  阶段管理

Command  命令	What it does  它的本事
/gsd:add-phase	往路线图里追加新阶段
/gsd:insert-phase [N]	紧急任务？随时插队安排
/gsd:remove-phase [N]	砍掉未来阶段，重新排号
/gsd:list-phase-assumptions [N]	动手前先看看 Claude 的规划思路
/gsd:plan-milestone-gaps	分阶段搞定审计发现的问题

Session  会话

Command  命令	What it does  它的本事
/gsd:pause-work	中途暂停时做好交接准备
/gsd:resume-work	恢复上次会话

Utilities  实用工具

Command  命令	What it does  它的本事
/gsd:settings	配置模型配置和工作流代理
/gsd:set-profile <profile>	切换模型配置（质量优先/均衡模式/经济实惠）
/gsd:add-todo [desc]	随时记录灵感点子
/gsd:check-todos	列出待办事项清单
/gsd:debug [desc]	用持久化状态进行系统化调试
/gsd:quick [--full]	执行临时任务，GSD 给你兜底（ --full 会加入计划检查和验证）
/gsd:health [--repair]	验证 .planning/ 目录的完整性，用 --repair 自动修复

^{¹ Contributed by reddit user OracleGreyBeard}

---

Configuration  配置

GSD 把项目设置存在 .planning/config.json 里。可以在 /gsd:new-project 时配置，或者之后用 /gsd:settings 更新。想了解完整的配置结构、工作流开关、git 分支选项，以及每个代理模型的详细说明，就去看看用户指南吧。

Core Settings

Setting  配置项	Options  选项	Default  默认值	What it controls  它管啥用
mode	yolo, interactive	interactive	自动批准 vs 每步都要确认
depth	quick, standard, comprehensive	standard	规划周全性（分阶段 × 多方案）

Model Profiles

为每个智能体指定所用的 Claude 模型。在输出质量和令牌消耗之间取得最佳平衡。

Profile  个人资料	Planning  规划环节	Execution  执行阶段	Verification  验证
quality	Opus  Opus 真香！	Opus  Opus 太给力了！	Sonnet  Sonnet 也不错！
balanced (default)   balanced (默认)	Opus  Opus 永远的神！	Sonnet	Sonnet
budget	Sonnet	Sonnet	Haiku  俳句

切换配置：

/gsd:set-profile budget

或者通过 /gsd:settings 来配置。

Workflow Agents  工作流代理

这玩意儿在规划/执行阶段会额外生成几个代理。好处是活儿干得更漂亮，但代价就是得多花点“算力”和“时间”。

Setting  配置项	Default  默认值	What it does  它的本事
workflow.research	true	在规划每个阶段前，都会先深入研究相关领域
workflow.plan_check	true	执行前先确认计划能达成阶段目标
workflow.verifier	true	执行后确认核心需求都已搞定
workflow.auto_advance	false	自动串联讨论 → 规划 → 执行，一气呵成不中断

用 /gsd:settings 来切换这些功能，或者每次调用时单独设置：

• /gsd:plan-phase --skip-research
• /gsd:plan-phase --skip-verify

Execution  执行

Setting  配置项	Default  默认值	What it controls  它管啥用
parallelization.enabled	true	同时运行多个独立计划
planning.commit_docs	true	追踪 git 里的 .planning/

Git Branching  Git 分支管理

掌控 GSD 在执行过程中如何处理分支。

Setting  配置项	Options  选项	Default  默认值	What it does  它的本事
git.branching_strategy	none, phase, milestone	none	分支创建策略
git.phase_branch_template	string	gsd/phase-{phase}-{slug}	阶段分支的模板
git.milestone_branch_template	string	gsd/{milestone}-{slug}	里程碑分支的模板

Strategies:  策略锦囊

• none — 提交到当前分支（GSD 的默认行为）
• phase — 每个阶段都开个新分支，阶段一完成就合并
• milestone — 整个里程碑就开一个分支，搞定再合并。

里程碑完成时，GSD 提供压缩合并（推荐）或保留历史记录的合并方式。

---

Security  安全防护

Protecting Sensitive Files 保护敏感文件

GSD 的代码库映射和分析命令会读取文件来理解你的项目。把包含密钥的文件加到 Claude Code 的拒绝列表里，就能妥妥保护起来：

1. 打开 Claude Code 设置（ .claude/settings.json 或全局设置）
2. 把敏感文件模式加到 deny list 里：

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/*)",
      "Read(**/*credential*)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

这样一来，不管运行什么命令，Claude 都完全没法读取这些文件啦！

Important  重要提示

GSD 本身内置了防止提交敏感信息的保护机制，但咱们还是得讲究“纵深防御”才最稳妥。第一道防线，就是直接掐断对敏感文件的读取权限。

---

Troubleshooting  故障排除

安装完找不到命令？

• 重启一下你的 runtime，让命令/技能重新加载。
• 检查一下文件是不是在 ~/.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

这样就能确保使用绝对路径，而不是那个在容器里可能没法正常展开的 ~ 。

Uninstalling  卸载指南

想彻底移除 GSD 的话：

# Global installs
npx get-shit-done-cc --claude --global --uninstall
npx get-shit-done-cc --opencode --global --uninstall
npx get-shit-done-cc --codex --global --uninstall

# Local installs (current project)
npx get-shit-done-cc --claude --local --uninstall
npx get-shit-done-cc --opencode --local --uninstall
npx get-shit-done-cc --codex --local --uninstall

它会一键清掉所有 GSD 的命令、代理、钩子和设置，但你的其他配置都原封不动保留着。

---

Community Ports  社区移植版本

现在通过 npx get-shit-done-cc ，OpenCode、Gemini CLI 和 Codex 都能原生支持啦！

这些社区移植版可是最早搞出多运行时支持的：

Project  项目	Platform  支持平台	Description  功能简介
gsd-opencode	OpenCode	原版 OpenCode 适配
gsd-gemini (archived)  gsd-gemini (已归档)	Gemini CLI  Gemini CLI 使用指南	原版 Gemini 适配，由 uberfuzzy 贡献

---

从零到交付的完整实战案例：

🎯 场景：用 GSD 构建一个「团队待办事项 API 服务」

假设你是一个独立开发者，想用 Next.js + Prisma + PostgreSQL 构建一个 REST API。

---

0️⃣ 安装 GSD

# 全局安装（推荐）
npx get-shit-done-cc@latest
# 选择 Claude Code → Global

# 验证
# 进入 Claude Code 后输入：
/gsd:help

---

1️⃣ 初始化项目 — /gsd:new-project

/gsd:new-project

GSD 会启动 交互式问答，像产品经理一样追问你：

🤖 你要构建什么？
> 一个团队协作的待办事项 REST API

🤖 目标用户是谁？
> 5-20 人的小团队

🤖 核心功能有哪些？
> 用户注册登录、创建/分配任务、任务状态流转、评论

🤖 技术栈偏好？
> Next.js API Routes + Prisma + PostgreSQL

🤖 v1 必须有什么？可以延后的？
> v1: 用户、任务 CRUD、分配。延后: 通知、文件附件

🤖 有哪些约束？
> 需要 JWT 认证，RESTful 风格，部署到 Vercel

问够之后，GSD 自动触发 4 个并行研究 Agent：

• Agent 1 → 调研技术栈（Next.js API Routes 最佳实践）
• Agent 2 → 调研同类功能（任务管理 API 设计模式）
• Agent 3 → 调研架构（Prisma schema 设计）
• Agent 4 → 调研常见坑（JWT + Vercel 的兼容问题）

产出文件：

.planning/
├── PROJECT.md          ← 项目愿景与约束
├── config.json         ← 工作流配置
├── REQUIREMENTS.md     ← v1/v2 需求清单
├── ROADMAP.md          ← 分阶段路线图
├── STATE.md            ← 状态跟踪
└── research/
    ├── stack.md        ← 技术栈研究
    ├── features.md     ← 功能研究
    ├── architecture.md ← 架构研究
    └── pitfalls.md     ← 风险研究

ROADMAP.md 示例内容：

## Phase 1: 数据库与用户系统
- Prisma schema 设计
- 用户注册/登录 API
- JWT 认证中间件

## Phase 2: 任务核心
- 任务 CRUD API
- 任务分配与状态流转

## Phase 3: 协作功能
- 任务评论系统
- 列表筛选与搜索

## Phase 4: 收尾与部署
- 错误处理标准化
- Vercel 部署配置

GSD 会要求你确认路线图，你可以调整后再继续。

---

2️⃣ 讨论阶段 — /gsd:discuss-phase 1

/gsd:discuss-phase 1

GSD 分析 Phase 1 的内容，识别出 灰色地带（实现细节中未决定的部分）：

🤖 Phase 1 涉及「用户系统 + 认证」，我识别到以下需要决策的领域：

1. 🔐 认证策略 — token 刷新机制、过期时间、存储方式
2. 👤 用户模型 — 需要哪些字段、角色权限是否 v1 就需要
3. 📧 注册流程 — 邮箱验证？邀请制？密码强度要求？

请选择你想讨论的领域（可多选）：

你选择 1 和 3，GSD 会对每个领域 深入追问 4 轮：

🤖 [认证策略] Access token 过期时间你倾向多久？
> 15 分钟

🤖 需要 refresh token 机制吗？
> 需要，7 天过期

🤖 token 存在哪里？httpOnly cookie 还是 Authorization header？
> httpOnly cookie

🤖 多设备同时登录要支持吗？
> v1 不用，单设备就行

🤖 认证策略讨论完毕。继续追问还是进入下一个领域？
> 下一个

产出文件： .planning/phases/01-CONTEXT.md

## 认证策略
- Access token: 15 分钟过期, httpOnly cookie
- Refresh token: 7 天过期
- v1 单设备登录，不做多端互踢

## 注册流程
- 邮箱 + 密码注册，无邀请制
- v1 不做邮箱验证（延后）
- 密码最低 8 位

关键点：这些决策会 直接注入 后续的研究和规划 Agent，避免它们凭空猜测。

---

3️⃣ 规划阶段 — /gsd:plan-phase 1

/gsd:plan-phase 1

GSD 执行三步流水线：研究 → 规划 → 校验循环

研究 Agent 根据 CONTEXT.md 的决策做针对性调研（jose vs jsonwebtoken、Prisma schema 最佳实践等），产出 01-RESEARCH.md。

规划 Agent 生成 2-3 个原子计划，每个计划用 XML 结构化：

**.planning/phases/01-01-PLAN.md**（Prisma Schema + 数据库）

<task type="auto">
  <name>设计 Prisma Schema 并初始化数据库</name>
  <files>
    prisma/schema.prisma
    src/lib/db.ts
  </files>
  <action>
    创建 User 模型: id, email(unique), passwordHash, name, createdAt
    创建全局 Prisma client 单例
    运行 prisma db push 初始化
  </action>
  <verify>
    npx prisma studio 能看到 User 表
  </verify>
  <done>Schema 建好，数据库可连接</done>
</task>

**.planning/phases/01-02-PLAN.md**（注册 + 登录 API）

<task type="auto">
  <name>实现用户注册端点</name>
  <files>src/app/api/auth/register/route.ts</files>
  <action>
    POST /api/auth/register
    验证 email 格式、密码 >= 8 位
    bcrypt hash 密码，存入数据库
    返回 201 + 用户信息（不含密码）
  </action>
  <verify>
    curl -X POST localhost:3000/api/auth/register
    -d '{"email":"test@test.com","password":"12345678"}'
    返回 201
  </verify>
  <done>注册成功返回用户，重复邮箱返回 409</done>
</task>

<task type="auto">
  <name>实现登录端点 + JWT</name>
  <files>src/app/api/auth/login/route.ts, src/lib/jwt.ts</files>
  <action>
    使用 jose 库（非 jsonwebtoken，避免 CommonJS 问题）
    验证凭证，签发 access + refresh token
    通过 httpOnly cookie 返回
  </action>
  <verify>
    curl 登录后响应头包含 Set-Cookie
  </verify>
  <done>正确凭证返回 cookie，错误凭证返回 401</done>
</task>

校验 Agent 检查每个计划是否覆盖了 REQUIREMENTS 和 CONTEXT 中的决策，未通过则打回修改，循环直到通过。

---

4️⃣ 执行阶段 — /gsd:execute-phase 1

/gsd:execute-phase 1

这是 GSD 最强大的环节。编排器分析计划间的依赖关系，分组为波次：

WAVE 1                    WAVE 2
┌──────────────────┐     ┌──────────────────┐  ┌──────────────────┐
│  01-01-PLAN      │ →   │  01-02-PLAN      │  │  01-03-PLAN      │
│  Prisma Schema   │     │  注册/登录 API    │  │  认证中间件       │
│  (无依赖)        │     │  (依赖 Schema)    │  │  (依赖 JWT)      │
└──────────────────┘     └──────────────────┘  └──────────────────┘

• Wave 1 — Schema 独立，先执行
• Wave 2 — 注册和中间件可以并行（都依赖 Schema，但互不依赖）

每个任务在全新的子 Agent 中执行（200k token 上下文），主编排器只占 ~15% 预算。

执行完成后，每个任务自动产生 原子 git commit：

a1b2c3d feat(01-01): prisma schema 与数据库初始化
d4e5f6g feat(01-02): 用户注册与登录 API
h7i8j9k feat(01-03): JWT 认证中间件

产出文件：

• 01-01-SUMMARY.md, 01-02-SUMMARY.md — 各任务完成摘要
• 01-VERIFICATION.md — 自动化验证结果

---

5️⃣ 验收阶段 — /gsd:verify-work 1

/gsd:verify-work 1

GSD 提取 Phase 1 应该交付的能力，逐项引导你手动验收：

🤖 测试 1/4: 用户注册
   你现在应该可以 POST /api/auth/register 创建新用户
   结果如何？ [通过 / 失败 / 描述问题]
> 通过

🤖 测试 2/4: 重复邮箱注册
   用相同邮箱再注册一次，应返回 409
> 通过

🤖 测试 3/4: 用户登录
   POST /api/auth/login，响应应包含 Set-Cookie
> 失败，没有收到 cookie

🤖 正在诊断...
   [自动 spawn 调试 Agent 分析代码]
   
🤖 发现问题：login/route.ts 第 23 行缺少
   cookies().set() 的 httpOnly 选项
   
   已生成修复计划: 01-fix-01-PLAN.md
   运行 /gsd:execute-phase 1 --gaps-only 来修复

修复后再次验收直到全部通过。

产出文件： 01-UAT.md

---

6️⃣ 循环推进

# Phase 1 通过后，继续 Phase 2
/gsd:discuss-phase 2
/gsd:plan-phase 2
/gsd:execute-phase 2
/gsd:verify-work 2

# ... 重复直到所有 Phase 完成

# 里程碑完成
/gsd:audit-milestone       # 审计整体完成度
/gsd:complete-milestone    # 归档 + 打 tag

---

⚡ 快速模式 — 小任务不走全流程

/gsd:quick
> 给所有 API 端点添加请求速率限制

跳过研究和校验，直接 规划 → 执行 → 提交，适合 bug 修复、小功能、配置变更。

加 --full 可以启用校验环节：

/gsd:quick --full
> 把错误响应格式统一为 {error: string, code: number}

---

🔧 其他实用命令

场景	命令
查看当前进度	/gsd:progress
已有项目接入 GSD	/gsd:map-codebase → /gsd:new-project
临时插入紧急工作	/gsd:insert-phase 2（在 Phase 1 和 2 之间插入）
查看 Claude 的实现意图	/gsd:list-phase-assumptions 3
暂停/恢复工作	/gsd:pause-work / /gsd:resume-work

---

💡 核心使用心得

1. discuss-phase 不要跳过 — 这一步决定了后续 Agent 的决策质量，越具体越好
2. 让 GSD 问你，而不是你告诉它 — 它的问题设计是为了发现你没想到的边界情况
3. 每个 Phase 保持 2-4 个 Plan — 太大的 Phase 应该拆分，确保每个 Plan 在单次上下文内完成
4. verify-work 认真做 — 自动诊断 + 修复计划的闭环是 GSD 最省心的部分