YC 总裁 Garry Tan 最近开源了自己的 Claude Code 工作流仓库 gstack。这个项目的核心，在于把产品讨论、工程评审、浏览器测试、发版和复盘整理成了一套可重复调用的 skill 流程。到 3 月 20 日，仓库在 GitHub 上已经来到约 27.4k stars、3.3k forks，采用 MIT 许可。

gstack 文档里给出的完整生命周期是：

office-hours → plan → implement → review → QA → ship → retro

从结构上看，它大致可以分成四层：

第一层，确定要做什么：/office-hours、/plan-ceo-review。 第二层，确定怎么做：/plan-eng-review、/plan-design-review、/design-consultation。 第三层，检查有没有问题：/review、/browse、/qa、/qa-only、/design-review、/investigate。 第四层，收尾和沉淀：/ship、/document-release、/retro。

1. /office-hours：项目起点

/office-hours 放在整个流程的最前面。skills 文档中提到，每个项目都应该从这里开始。它的作用是在进入编码前，先把项目方向、用户、需求、切入口讲清楚，并把讨论结果写成 design doc，保存到 ~/.gstack/projects/ 供后续命令继续使用。

这个命令有两种模式。 Startup mode 面向创业项目和商业化产品，更关注需求强度、替代方案、切口和趋势。 Builder mode 面向 side project、开源和实验项目，更关注什么版本最适合快速展示和验证。

它适合放在项目一开始，用来完成方向收敛。

2. /plan-ceo-review：从功能描述推进到产品任务

/plan-ceo-review 对应 founder / CEO 视角。它处理的问题，是“功能描述”和“真实产品任务”之间的差距。文档中列出了四种 review 模式：Scope Expansion、Selective Expansion、Hold Scope、Scope Reduction。

这个命令的重点是继续追问功能背后的目标。 例如一个看起来普通的功能需求，在这里会被重新理解为更完整的产品任务，再决定应该扩展、收缩还是保持当前范围。

它适合放在产品定义阶段，用来提高需求表达的质量。

3. /plan-eng-review：工程可行性收敛

当产品目标已经明确，下一步就是工程 review。/plan-eng-review 对应 Eng Manager 视角，重点检查 Architecture、Code Quality、Tests、Performance 等内容。相关 skill 文档提到，它会控制每个部分的高优先级问题数量，避免 review 失控。

它主要处理这些问题：

• 架构边界

• 同步与异步流程

• 错误处理与重试

• 状态持久化

• 性能瓶颈

• 测试覆盖路径

这一层的作用，是把“可以想象”变成“可以落地”。

4. /plan-design-review 与 /design-consultation：设计方案审查与方向咨询

这两个命令都属于设计阶段，但用途不同。

/plan-design-review 面向已有 plan。它会从设计师视角审查方案，检查信息架构、关键状态、交互路径、文案层级和视觉完整性，并推动 plan 进一步完善。

/design-consultation 更适合项目早期，用来讨论整体视觉方向、产品气质和设计语言。它适合那些还没有明确风格、需要先定设计方向的项目。

前者偏“审方案”，后者偏“定方向”。

5. /review：上线前的工程风险检查

/review 是 gstack 里很重要的一个命令。README 建议用户在有代码变更的分支上优先运行它。

它关注的是一些开发阶段不一定明显、但线上代价很高的问题，例如：

• N+1 查询

• race conditions

• stale reads

• trust boundary 问题

• 缺索引

• escaping 问题

• 错误恢复逻辑

• 关键故障模式缺少测试覆盖

对于已经完成编码、准备提 PR 或上线的分支，这一步非常关键。

6. /browse：浏览器能力

/browse 为 agent 提供真实浏览器能力。顶层 SKILL.md 将其描述为一个快速 headless browser，CLAUDE.md 也建议在浏览器交互相关任务中优先使用它。

它可以完成：

• 打开页面

• 点击和填表单

• 截图

• 检查控制台

• 走完整个用户路径

文档显示，它底层基于持久化 Chromium daemon 和 Playwright，目标是让浏览器交互更快、更稳定，同时保留 session 状态。

对 Web 项目来说，这一步很重要，因为它让 agent 能直接看到页面，而不是依赖猜测。

7. /qa 与 /qa-only：测试阶段

/qa 基于浏览器能力对 Web 应用做系统化测试，并可在发现问题后进入修复循环。qa/SKILL.md 里写到，它支持 Quick、Standard、Exhaustive 三档深度。

它适合处理：

• 页面流程测试

• 表单与交互验证

• bug 发现与重新验证

• staging 环境测试

/qa-only 则更保守一些，只输出 bug 报告，不自动改代码。README 中将它单独列为一个可用 skill。

如果希望先获得问题列表，再决定是否修复，/qa-only 更合适。

8. /design-review：上线后的视觉审查

/design-review 面向 live site，重点检查真实页面的布局、层级、间距、状态覆盖和交互细节。它处理的是“功能已经出来，但页面质感还不够稳定”的问题。

这一步适合放在功能完成之后，用来补齐视觉和体验层面的细节。

9. /setup-browser-cookies 与 /investigate：测试登录态与问题调查

/setup-browser-cookies 的作用比较直接：把真实浏览器里的登录态导给测试浏览器，方便后续执行 /browse 和 /qa，尤其适合后台、会员和多权限页面。

/investigate 则面向问题调查阶段。它适合在 bug 已经出现、根因尚不明确时使用，帮助 agent 从“发现异常”进入“定位原因”。

10. /ship、/document-release、/retro：收尾与沉淀

/ship 负责发版流程，包括测试、分支检查、PR 更新等最后一公里动作。文档还提到，如果项目缺少成型的测试体系，它还会尝试补充基础测试和 CI。

/document-release 用来同步更新文档，例如 README、命令说明和项目结构，减少代码变了而文档没有跟上的情况。

/retro 则面向周度复盘。它会分析提交、节奏、测试变化和热点区域，把开发过程沉淀为可回看的记录。

结语

从命令设计上看，gstack 的重点不是增加更多“能力点”，而是把开发过程拆成多个阶段，让模型在不同阶段承担不同职责。产品定义、工程审查、浏览器测试、设计检查、发版和复盘，这些以前常常分散在个人经验里的动作，在这里被写成了一套明确的工作流。

如果只是快速浏览这个仓库，最值得优先理解的，是它的命令分工和整条链路。 把每个命令放回到对应阶段，再去试用，理解成本会低很多。