$ npx gsd-opencode

或者

$ npx gsd-opencode@latest

我为何构建此项目

我是一名独立开发者。我不写代码——是 Claude Code 在帮我完成。

市面上已有其他规范驱动的开发工具，比如 BMAD、Speckit 等。但它们要么让流程变得过于复杂（如冲刺仪式、故事点、利益相关者同步会议、回顾会、Jira 工作流），要么缺乏对整体目标的清晰理解。而我并不是一家拥有五十人的软件公司。我不想搞那些企业式的繁文缛节。我只是一个富有创造力的人，只想打造出真正实用的好东西。

于是，我打造了 GSD。复杂性隐藏在系统内部，而非你的工作流程之中。后台涉及上下文工程、XML 提示格式化、子代理编排和状态管理。你看到的只是几个简单好用的命令而已。

该系统为 Claude Code 提供了完成并验证工作的所有必要条件。我对这套流程充满信心，因为它确实行之有效。

这就是它的本质：没有那些企业角色扮演式的废话，只有一套极其高效的系统，帮助你持续地利用 Claude Code 打造酷炫的产品。

—— TÂCHES

来自译者……

我非常喜欢 GSD 和 OpenCode。总觉得只让 GSD 服务于 Claude Code 有些不公平。

—— Roman

版本 1.33.2

新增了将 Agent() 后台任务调用转换为 OpenCode 兼容的 @gsd-<agent> 简写语法的功能。assets/configs/remove-task.json 中的新规则 21 会动态提取 skill="gsd-<agent>" 模式中的代理名称，并将其转换为 OpenCode 格式。此次更新修复了 autonomous.md 工作流中计划与执行阶段调度部分的两个 Agent() 调用，确保完全兼容 OpenCode。

版本 1.33.0

我们再次紧跟原始 GSDv1 的 v1.33.0（2026-04-04）版本。

而在本地，我们也做了许多改动。其中最重要的一点是移除了 task() 调用，因为 OpenCode 不支持这一语法，取而代之的是直接调用代理的方式。

版本 1.30.0

我们继续跟进原始 GSDv1 的 v1.30.0 版本（2026-03-30）。

为了支持 “skill(skill='command-name')” 语法，我采取了一个颇具争议的解决方案。除此之外，其他部分都应能正常运行。

版本 1.22.1

我决定为所有自定义代理添加 ‘mode: subagent’ 属性。这不应影响任何 GSD 功能，但应该能够从 Tab 键显示的代理列表中移除不必要的条目。如果我遗漏了什么，请随时提出意见。

版本 1.22.0 — 我们正在追赶原始 v1.22.4（2026-03-03）

一如既往，你可以在我们的 原始 CHANGELOG.md v1.20.5 -> v1.22.4 中找到 TACHES 所做的全部更改。

这些变更的核心在于，原始 GSD 使用正确的语法来执行代理任务。因此，不会再出现意外停止的情况，也不会导致规划完成后 Gsd-Planner 仍处于活动状态。

而在 gsd-opencode 方面，我们进行了一些修复，并对后端进行了大量调整。

版本 1.20.3 — 新的 gsd-opencode 模型配置文件系统

我不得不放弃对原始 GSD 模型配置文件系统的支持。Claude Code 使用三种不同的模型：Opus、Sonnet 和 Haiku。而在 OpenCode 中，我们则有数十家供应商和数百种模型可供选择。因此，GSD 的模型配置文件系统并不适用于我们。

所以我重新设计了这一系统，暂时命名为“简单|智能|天才”。希望这能解决意外停止的问题。

• /gsd-settings — 不再对模型与代理的分配进行任何更改。它会询问模型配置文件，但不会执行任何操作。你需要自行运行 /gsd-set-profile。
• /gsd-check-profile — 检查 gsd-opencode 的配置文件，并报告可能存在的问题（如有）。
• /gsd-set-profile — 这是你控制每个阶段使用哪种模型的主要界面。试试看吧！真的，试一试！

版本 1.20.0 — 我们正在追赶原始 v1.20.5

同样，你可以在 原始 CHANGELOG.md v1.9.4 -> v1.20.5 中找到 TACHES 所有的改动。

至于我们这边，虽然有许多小改动，但在配置文件管理方面有一个重要的调整。我们没有照搬 TACHES/Claude Code 的做法，而是采用了更符合 OpenCode 的方式。

GSD-OpenCode 支持三种配置文件：

• 简单（允许为所有类型的 gsd 自定义代理指定单一模型）
• 智能（允许为 gsd 自定义代理指定两种不同模型：一种用于……）
• 天才（好吧，其实称不上“天才”，但至少可以为自定义代理指定三种不同的模型）

版本 1.9.0 - 我们正在追赶原始的 v1.9.4

您可以在 原始 CHANGELOG.md v1.6.4 -> v1.9.4 中找到 TACHES 所做的所有更改。

模型配置文件管理

OpenCode 现在支持通过以下方式进行全面的模型配置文件管理：

• /gsd-settings — 配置文件、阶段覆盖和工作流切换的交互式设置菜单
• /gsd-set-profile <profile> — 在高质量/平衡/预算配置文件之间快速切换
• /gsd-set-model <profile> — 配置每个配置文件使用的模型

这些命令会管理 .planning/config.json 文件，并生成包含代理与模型映射关系的 opencode.json 文件。请注意：更改配置文件后，请退出并重新启动 OpenCode，以使更改生效。

版本 1.6.0 - 我们开始使用 Git 子模块

如果您克隆了这个仓库，请别忘了在克隆后执行以下命令：

$ git submodule update --init --recursive 

这将从 TÂCHES 仓库更新/填充 ./original/get-shit-done 文件夹。

这里有一篇关于 Git 子模块的简洁文章：使用子模块。感谢 @borisnaydis 指出这一点。

版本 1.5.0 - 破坏性变更：命令命名规范更新

⚠️ 重要提示：命令语法的破坏性变更

我们进行了更新，以使 GSD 的命令命名规范与 OpenCode 的标准 kebab-case 格式保持一致。不幸的是，这给用户一直习惯的可见命令语法带来了破坏性变更。

更改内容

命令命名： 所有 GSD 命令已从 /gsd: 前缀更新为 /gsd- 格式。

为什么进行此更改？

gsd-kebab-case 命名规范遵循 OpenCode 的标准命令格式。这种对齐确保了整个生态系统的统一性，并提高了兼容性。 注意： 我们理解这对可见命令语法来说是一个不幸的破坏性变更。如果将来有可能的话，我们可能会考虑恢复原来的 /gsd: 语法，同时保持向后兼容性。

迁移指南

对于升级到版本 1.5.0 的用户，只需将所有 GSD 命令中的冒号（:）替换为连字符（-）即可：

• 旧版：/gsd:plan-phase 1
• 新版：/gsd-plan-phase 1

所有功能保持不变——只有命令前缀发生了变化。

Vibecoding 的名声并不好。您描述自己的需求，AI 会生成代码，但结果往往不一致，甚至在规模扩大时就会崩溃。

GSD 解决了这个问题。它是让 OpenCode 变得可靠的上下文工程层。只需描述您的想法，让系统提取所需的所有信息，然后让 OpenCode 开始工作。

适合人群

那些希望描述自己的需求并让系统正确构建出来的人——而无需假装自己运营着一个拥有 50 名工程师的团队。

开始使用

npx gsd-opencode

# 或者

npm install gsd-opencode -g
gsd-opencode install

就这么简单。可以通过 /gsd-help 进行验证。

保持更新

GSD 发展迅速。请定期检查更新：

/gsd-whats-new

更新方法如下：

npx gsd-opencode@latest

# 或者

npm install gsd-opencode@latest -g
gsd-opencode install

npx gsd-opencode --global   # 安装到 ~/.config/opencode/
npx gsd-opencode --local    # 安装到 .opencode/

# 卸载（自动检测全局或本地安装）
gsd-opencode uninstall

# 全局卸载
gsd-opencode uninstall --global
gsd-opencode uninstall -g

# 本地卸载
gsd-opencode uninstall --local
gsd-opencode uninstall -l

# 预览将要移除的内容（干运行）
gsd-opencode uninstall --dry-run

git clone https://github.com/rokicool/gsd-opencode.git
cd gsd-opencode
git submodule update --init --recursive 
node bin/install.js --local

{
  $schema: https://opencode.ai/config.json,
  permission: {
    bash: allow,
    read: allow,
    edit: allow,
    grep: allow,
    glob: allow,
    list: allow
  }
}

分发管理器（仅限 gsd-opencode）

GSD-OpenCode 包含一个全面的软件包管理器，用于安装、维护和更新 GSD 系统。通过 npm 安装后，您可以使用完整的 CLI 来管理您的 GSD 安装。

快速参考

有关所有命令、选项、故障排除和高级用法的详细文档，请参阅 DISTRIBUTION-MANAGER.md。

工作原理

已经有代码了吗？ 请先运行 /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}-CONTEXT.md

3. 规划阶段

/gsd-plan-phase 1

系统会执行以下操作：

1. 调研 — 根据你在 CONTEXT.md 中做出的决策，研究如何实现当前阶段
2. 规划 — 创建2–3个具有XML结构的原子任务计划
3. 验证 — 对计划进行需求检查，循环直至通过

每个计划都足够小，可以在全新的上下文中执行，不会出现信息冗余或“现在我要更简洁一些”的情况。

生成文件： {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. 执行阶段

/gsd-execute-phase 1

系统会执行以下操作：

1. 分波运行计划 — 可并行的并行执行，有依赖关系的则按顺序执行
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 1

这是你确认功能确实正常运作的时候。

自动化验证会检查代码是否存在以及测试是否通过。但这个功能是否真的如你预期般工作呢？这正是你亲自体验的机会。

系统会执行以下操作：

1. 提取可测试的交付成果 — 你现在应该能够完成的操作
2. 逐一引导你进行测试 — “你能用邮箱登录吗？”是/否，或者描述问题所在
3. 自动诊断失败原因 — 启动调试代理来找出根本原因
4. 创建已验证的修复计划 — 准备好立即重新执行

如果一切顺利，就可以进入下一阶段。如果有问题，你无需手动调试——只需再次运行 /gsd-execute-phase，系统会自动带上它生成的修复计划。

生成文件： {phase}-UAT.md, 若发现问题则生成修复计划

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 将启动下一个版本——流程与新建项目相同，只是针对你现有的代码库。你需要描述接下来想开发的内容，系统会调研相关领域、明确需求范围，并生成一份新的路线图。每一个里程碑都是一个完整的闭环：定义 → 构建 → 发布。

快速模式

/gsd-quick

适用于不需要完整规划的临时性任务。

快速模式提供了GSD的核心保障（原子提交、状态跟踪），同时采用更快捷的路径：

• 相同的智能体 — 规划师与执行者，质量一致
• 跳过可选步骤 — 无需调研、无需计划检查、无需验证
• 独立的跟踪记录 — 存储在 .planning/quick/ 目录下，不计入各阶段

适合用于：修复Bug、小型功能、配置变更、一次性任务。

/gsd-quick
> 你想做什么？“在设置中添加暗黑模式切换”

生成文件： .planning/quick/001-add-dark-mode-toggle/PLAN.md, SUMMARY.md

为何有效

上下文工程

OpenCode 非常强大，前提是你为其提供所需的上下文。然而，大多数人并没有做到这一点。

GSD 会为你处理这一切：

根据 OpenCode 质量开始下降的界限设定文件大小限制。保持在限制内，即可获得持续的卓越表现。

XML 提示格式化

每个计划都以针对 OpenCode 优化的结构化 XML 格式呈现：

<task type="auto">
  <name>创建登录端点</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    使用 jose 库生成 JWT（而非 jsonwebtoken — 因 CommonJS 引发问题）。
    对用户表中的凭据进行验证。
    成功时返回 httpOnly Cookie。
  </action>
  <verify>使用 curl -X POST localhost:3000/api/auth/login 应返回 200 状态码及 Set-Cookie 头</verify>
  <done>有效凭据返回 Cookie，无效凭据返回 401 错误</done>
</task>

精确的指令，无需猜测，内置验证机制。

多智能体编排

每个阶段都采用相同的模式：一个轻量级的编排器会启动专门的智能体，收集结果并将其传递到下一步。

编排器本身并不承担繁重的工作。它负责启动智能体、等待结果并整合反馈。

结果： 你可以完成整个阶段——深入研究、创建并验证多个计划、由多个执行者并行编写数千行代码、自动验证是否符合目标——而你的主上下文窗口始终保持在 30%–40% 左右。实际工作是在全新的子智能体上下文中进行的。因此，你的会话始终保持快速响应。

原子级 Git 提交

每个任务完成后会立即生成独立的提交：

abc123f docs(08-02): 完成用户注册计划
def456g feat(08-02): 添加邮箱确认流程
hij789k feat(08-02): 实现密码哈希
lmn012o feat(08-02): 创建注册端点

[!NOTE] 好处： Git bisect 可以精准定位出错的任务。每个任务都可以独立回滚。为未来的 OpenCode 会话提供了清晰的历史记录。在 AI 自动化的工作流中，可观测性更强。

每一个提交都精准、可追溯且具有明确的意义。

模块化设计

• 可以向当前里程碑添加新阶段
• 在各阶段之间插入紧急任务
• 完成里程碑后重新开始
• 无需重建整体即可调整计划

你永远不会被锁定。系统会灵活适应。

命令

核心工作流

导航

老项目改造

阶段管理

会话管理

实用工具

^{¹ 由 Reddit 用户 OracleGreyBeard 贡献}

配置

GSD 将项目设置存储在 .planning/config.json 中。可以在 /gsd-new-project 期间配置，或稍后通过 /gsd-settings 进行更新。

核心设置

模型配置文件（gsd-opencode 特定）

工作原理

GSD 使用一种基于阶段的模型分配系统。您无需单独配置每个代理，而是将模型分配给三个阶段：

配置文件

有两个文件管理模型分配：

当您更改配置文件或模型时，GSD 会更新这两个文件。OpenCode 在启动时读取 opencode.json。

预设

预设定义了每个配置文件的基础模型：

{
  "profiles": {
    "presets": {
      "genius": {
        "planning": "bailian-coding-plan/qwen3.5-plus",
        "execution": "bailian-coding-plan/kimi-k2.5",
        "verification": "bailian-coding-plan/MiniMax-M2.5"
      }
    }
  },
  "current_oc_profile": "genius"
}

首次运行设置

首次使用时（或运行 /gsd-set-profile → 重置预设时），会运行预设设置向导：

1. 查询 opencode models 以发现可用模型
2. 提示您为每个配置文件/阶段选择模型（共9次选择）
3. 将配置保存到 .planning/oc-config.json
4. 生成包含代理映射的 opencode.json

这确保您的预设使用的是 OpenCode 安装中实际可用的模型。

命令

示例：

# 切换到简单配置文件
/gsd-set-profile simple

# 交互式配置平衡配置文件的模型
/gsd-set-profile balanced

# 打开完整设置菜单
/gsd-settings

配置文件理念

在配置预设时：

• 简单 — 在所有阶段都使用您最强大的模型。最适合关键的架构工作。
• 智能 — 强大的模型用于规划（决策很重要），中等水平的模型用于执行/验证（遵循指令）。
• 天才 — 强大的模型用于规划（决策很重要），中等水平的模型用于执行/验证（遵循指令），轻量级模型用于研究/验证。最适合高容量的工作。

重要提示：需要重启

OpenCode 在启动时加载 opencode.json，并且不会热加载模型分配。更改配置文件或模型后：

1. 完全退出 OpenCode
2. 重新启动 OpenCode

这样新的模型分配才会生效。

工作流代理

这些代理会在规划/执行过程中生成额外的代理。它们可以提高质量，但会增加 token 数量和时间。

您可以使用 /gsd-settings 来切换这些设置，或者在每次调用时进行覆盖：

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

执行

故障排除

安装后找不到命令？

• 请参阅分发系统故障排除部分以获取详细帮助
• 验证安装：gsd-opencode list
• 重启 OpenCode 以重新加载斜杠命令

安装过程中权限被拒绝？

• 请参阅安装问题故障排除部分以获取解决方案

如何更新到最新版本？

# 使用内置更新命令
gsd-opencode update

# 或通过 npm 重新安装
npx gsd-opencode@latest

使用 Docker 或容器化环境？

请参阅Docker/容器使用部分以获取详细说明。

如果使用波浪号路径 (~/.config/opencode/...) 读取文件失败，请在安装前设置 OPENCODE_CONFIG_DIR：

OPENCODE_CONFIG_DIR=/home/youruser/.config/opencode npx gsd-opencode --global

这可确保使用绝对路径，而不是可能在容器中无法正确展开的 ~。

星标历史

许可证

MIT 许可证。详情请参阅 LICENSE。

gsd-opencode 快速上手指南

gsd-opencode 是一个专为 OpenCode 设计的轻量级元提示（meta-prompting）和规格驱动开发系统。它基于 TÂCHES 的 "Get Shit Done" (GSD) 框架改编，旨在通过上下文工程和子代理编排，让开发者只需描述需求，AI 即可自动完成高质量的代码构建与验证，无需繁琐的企业级流程。

环境准备

在开始之前，请确保您的开发环境满足以下要求：

• 操作系统：macOS, Windows, 或 Linux。
• 核心依赖：已安装 Node.js (建议 LTS 版本) 和 npm。
• 目标平台：已安装并配置好 OpenCode 编辑器/环境。
• 网络环境：能够访问 npm registry 及 GitHub（若下载缓慢，可配置国内镜像源）。

💡 国内加速建议 若安装过程中遇到网络延迟，建议临时切换至国内 npm 镜像源：

npm config set registry https://registry.npmmirror.com

安装步骤

您可以通过 npx 直接运行，或通过 npm 全局安装以获得更完整的 CLI 管理功能。

方式一：直接使用 (推荐尝试)

无需预先安装，直接在终端运行最新版本的安装向导：

npx gsd-opencode@latest

方式二：全局安装 (推荐长期使用)

1. 安装包到全局环境：

   npm install gsd-opencode -g
   

2. 执行安装命令将 GSD 系统集成到 OpenCode：

   gsd-opencode install
   

3. 验证安装： 启动 OpenCode，在对话框中输入以下命令确认系统已就绪：

   /gsd-help
   

非交互式安装 (适用于 Docker/CI/脚本)

如果您需要跳过交互提示进行自动化部署：

# 全局安装到 ~/.config/opencode/
npx gsd-opencode --global

# 或局部安装到当前项目的 .opencode/
npx gsd-opencode --local

基本使用

安装完成后，gsd-opencode 将作为 OpenCode 的智能层运行。您不需要编写复杂的配置文件，只需通过自然语言描述需求。

1. 启动工作流

在 OpenCode 中，直接描述您想要构建的功能。系统会自动识别意图并调用相应的 GSD 代理（如规划、执行、测试等）。

示例指令：

"帮我创建一个带有用户登录功能的 React 前端项目，使用 Tailwind CSS 样式，后端使用 Node.js Express。"

2. 常用控制命令

在安装后，您可以使用以下斜杠命令（Slash Commands）来管理系统行为：

• 查看帮助：

  /gsd-help
  

• 检查更新：

  /gsd-whats-new
  

• 配置模型策略 (OpenCode 特有功能)： 由于 OpenCode 支持多种模型提供商，您可以手动设定不同阶段的模型策略（Simple/Smart/Genius）：

  /gsd-set-profile
  

  • Simple: 所有任务使用同一模型。
  • Smart: 区分普通任务和复杂任务使用不同模型。
  • Genius: 为规划、执行、审查分别指定不同模型。

  注意：更改模型配置后，建议重启 OpenCode 以使设置生效。

3. 更新系统

GSD 迭代迅速，定期运行以下命令以保持最新功能：

npx gsd-opencode@latest
# 或者如果已全局安装
npm install gsd-opencode@latest -g
gsd-opencode install

现在，您可以专注于创意描述，让 gsd-opencode 为您处理复杂的工程实现细节。