Gstack：一个人的虚拟团队

gstack 把一个创业团队拆成一组斜杠命令。前一个角色的产出，就是后一个角色的输入。

一个功能真正上线，通常要过好几个人的手：产品经理问这东西到底解决谁的问题，CEO 问是不是想小了，技术负责人画架构、定测试，设计师挑问题，QA 点一遍，最后有人负责发布。

一个人做产品时，这些角色全落在你身上，结果往往哪个都没做好。

gstack 的做法是每个角色做成一个 Skill，需要的时候叫它出来。

作者是 Y Combinator 的 CEO，这套配置是他自己在用的。要注意他本职是投资人，不是程序员。项目使用 MIT 许可。

它和上一节的 Superpowers 有几处不同：

我自己觉得这更像在经营一家虚拟公司：角色驱动，不是流程驱动。

一、安装

需要 Claude Code、Git 和 Bun。

在终端里运行：

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

它装在你的用户级 Skill 目录里，所有项目都能用。

想让队友克隆仓库后自动用上 gstack，在你的项目里运行：

(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required

然后提交它生成的文件。required 表示队友没装 gstack 就提示他装，换成 optional 只是建议。以前那种把 gstack 整个复制进项目仓库的做法已经不推荐了。

第一次怎么用

README 给的建议是：装好之后，先只用这四个，然后停下来体会一下：

/office-hours   描述你要做的东西
/plan-ceo-review   对任何一个功能想法用一下
/review   对任何一个有改动的分支用一下
/qa   对你的测试环境用一下

装好之后，~/.claude/skills/gstack/ 下每个带 SKILL.md 的目录对应一条斜杠命令。写作时一共有 57 个：

二、七个阶段

gstack 把一次开发叫作 sprint（冲刺），分七个阶段：想 → 计划 → 写 → 审查 → 测试 → 发布 → 复盘。

每一段对应一个或几个角色：

README 用一句话说明了它的设计：每个 Skill 的产出会喂给下一个 Skill。

• /office-hours 写的设计文档，/plan-ceo-review 会去读
• /plan-eng-review 写的测试计划，/qa 会接着用
• /review 发现的问题，/ship 会检查是否已经修了

顺序因此有意义：能跳过某一步，但跳过之后，后面的角色就少一份输入。

gstack 的大部分产出放在你的用户目录 ~/.gstack/projects/<项目名>/ 下，不在仓库里：设计文档、CEO 评审计划、评审记录、决策日志都在那儿。

好处是不会弄脏仓库；代价是队友看不到，换台电脑也带不过去。本章另外几个框架的交接物都在仓库里，这一点不一样。

三、精读 /office-hours：写代码之前的那场谈话

这是 gstack 的入口：它先问你这个东西做出来是为了什么。

1. 先问你：这是为了什么

它开口第一个问题就是：你做这个是为了什么。Skill 里写得很硬，哪怕你的请求已经暗示了模式，也要问，并给出推荐。

根据回答，切换成两种完全不同的模式：