莫愁前路无知已，天下谁人不识君。——高适

gstack：把 Claude Code 组织成一支能思考、交付、复盘的软件团队

写软件这件事，正在发生一种明显的变化。

过去，一个人面对的是编辑器、终端、文档、浏览器、测试、代码评审与发布流程。每一个环节都需要亲自切换角色：先像产品经理一样追问需求，再像架构师一样拆解系统，接着像开发者一样实现，随后又变成测试人员、设计师、发布工程师与技术写作者。

而 gstack 的想法，是把这些角色组织进同一套 AI 编程工作流。

它以 Claude Code 为核心，也支持更多 AI Agent，将一组有明确职责的 Skills 组合成一条完整的软件交付路径。从产品思考到技术规划，从实现到评审，从质量验证到发布，再到复盘与知识沉淀，gstack 希望让一个开发者拥有一支可以协作推进的软件团队。

它不是一组互不相关的快捷命令。

它更像一套有节奏的工程方法。

1	思考 → 规划 → 构建 → 评审 → 测试 → 发布 → 复盘

从一个模糊想法开始，而不是从第一行代码开始

很多项目一开始就进入编码，往往不是因为需求已经足够清晰，而是因为开始写代码看起来最有进展。

但一个模糊的需求，经常隐藏着更大的产品问题。

用户说想做一个每日简报应用，真正需要的也许不是“简报”，而是一个能帮他提前发现日程冲突、补充会议信息、校正地点与准备事项的个人助理。

用户说想加一个通知功能，真正的问题也许是信息没有在正确的时机抵达正确的人。

gstack 的 /office-hours 就是为这种时刻准备的。

它把自己放在 YC Office Hours 的角色中，通过六个强制问题追问问题本身。它不满足于接收一个功能请求，而会重新审视问题、挑战默认前提、生成不同实现路径，并推动需求朝着可交付的最小切口收敛。

1	/office-hours

这个环节的目的不是延缓开发，而是避免团队太早爱上第一个解决方案。

在 gstack 的流程中，好的产品工作不是立刻把需求翻译成任务列表，而是先确认自己究竟在解决什么。

CEO Review：让功能请求接受战略拷问

当需求已经有了雏形，下一步不是立刻开始画架构图，而是继续问一个更难的问题：

这真的是最值得做的版本吗？

/plan-ceo-review 扮演 CEO 或创始人的角色，对计划进行战略层面的重新审视。它会寻找隐藏在请求背后的更大产品机会，也会识别范围不够、范围过大或方向偏离的问题。

1	/plan-ceo-review

这一阶段提供四种范围模式：

扩展
选择性扩展
保持范围
缩减

这四种选择反映了产品规划中常见的现实。

有些方案需要更大胆地展开，才能触及真正的产品价值。

有些方案只需要补上关键缺口，不应无限膨胀。

有些方案本身已经足够聚焦，应该守住范围。

还有些方案则需要被削减，先验证最小可行的那一部分。

gstack 不把“加更多功能”默认当作进步。它允许计划被挑战，也允许计划被收窄。

Eng Review：把隐藏假设拉到台面上

产品方向清楚之后，工程问题才真正开始浮现。

数据从哪里来。

状态如何流转。

失败时会发生什么。

边界条件如何处理。

测试要覆盖哪些路径。

安全问题在哪里。

架构是否能支撑后续变化。

/plan-eng-review 对应工程经理角色，负责把这些问题组织成可执行的技术计划。

1	/plan-eng-review

它会关注架构、数据流、图示、边界条件与测试，并将那些原本容易被忽略的假设显式化。

一个计划如果只写“实现某功能”，它很可能还没有准备好进入开发。

一个真正可执行的计划，需要知道数据如何进入系统，状态如何变化，异常如何处理，哪些地方需要测试，以及什么情况下应该停止并重新确认方向。

gstack 希望让工程评审发生在代码之前，而不是等到实现完成后才发现基础假设不成立。

设计评审不只是看起来好看

AI 写界面时，很容易产出看起来完整、却缺少辨识度和判断力的结果。

这种问题在 gstack 中被称为 AI Slop。

/plan-design-review 以高级设计师的视角审查设计计划。它会为不同设计维度评分，解释满分状态应该是什么样子，并对计划进行修改。

1	/plan-design-review

它不是简单地要求“做得更漂亮”。

它要求设计具备明确的质量标准。

对于开发者体验，gstack 还有 /plan-devex-review。

1	/plan-devex-review

这个 Skill 会围绕开发者角色、首次获得可用结果所需时间、流程摩擦点与产品中的关键体验展开审查。

面向最终用户的产品，需要设计评审。

面向开发者的 API、CLI、SDK 与文档，同样需要开发者体验评审。

gstack 将这两类问题分开看待，因为用户体验与开发者体验虽然都重要，但它们关注的细节并不相同。

`/autoplan`：把多轮规划串成一条自动审查流水线

当一个任务同时涉及产品、设计、开发者体验与工程架构时，逐个运行审查命令会显得繁琐。

/autoplan 用于执行完整规划流程。

/autoplan

它会自动运行 CEO、设计、开发者体验与工程评审，并确保工程评审最后执行。

这一顺序很重要。

前面的审查可能改变产品范围、设计要求和使用方式。工程评审放在最后，意味着它审查的是经过前序环节修订后的最终计划，而不是一个随时还会变形的初稿。

规划不是文档的堆叠。

在 gstack 的方法里，规划是一条会不断接收上游结论、逐渐收敛的流程。

构建之后，真正的考验才开始

写完代码并不代表任务完成。

代码可能通过静态检查，却在真实环境中出现竞态条件。

某个接口可能逻辑正确，却在无效输入、取消请求、重复投递或部分失败后暴露问题。

页面可能在正常路径上看起来没问题，却在真实浏览器操作时出现断裂。

因此，gstack 在实现之后继续安排多个角色进入工作。

`/review`：寻找那些能通过 CI 的生产问题

/review 扮演 Staff Engineer。

/review

它的任务是寻找那些可能通过持续集成、却会在生产环境中出问题的缺陷。

它会自动修复明显问题，也会针对需要判断的风险提出询问。除此之外，它还会检查完整性缺口，并通过简化视角识别过度构建的代码。

这一点很有价值。

代码评审不应只盯着错误，也应当识别复杂度是否已经超过问题本身所需要的程度。

有时候，最好的修复不是补更多代码，而是删掉不必要的路径。

`/investigate`：没有调查，就没有修复

/investigate 对应调试器角色。

1	/investigate

它强调一条原则：

1	没有调查，就没有修复

它会追踪数据流、验证假设，并在连续三次修复失败后停止继续猜测。

这种限制很克制。

面对错误时，最容易发生的事情就是不断尝试补丁。改一个地方，不行；再改另一个地方，还是不行；最后系统里留下更多没有经过验证的改动。

gstack 希望调试从“连续试错”变成“建立假设、验证假设、确认根因”的过程。

QA 不只适用于网页

很多人一提到质量验证，就想到浏览器自动化。

但软件不只有网页。

命令行工具需要验证输入、输出、退出码与取消行为。

API 需要验证请求、错误与边界条件。

Webhook 需要验证重复投递与部分失败后的恢复。

后台任务需要验证运行路径与失败处理。

gstack 的 /qa 和 /qa-only 面向这些不同场景。

/qa

/qa-only

/qa 会探索并验证行为，复现问题，编写失败回归，再修复根因并重新验证。

/qa-only 则聚焦探索与报告，它可以提出回归测试建议，但不会修改产品代码或测试。

对于 CLI 和 API，gstack 并不强制使用浏览器。它会先识别目标表面、可使用的工具与写入权限。若本地原生工具或安全测试夹具不可用，报告会指出阻碍与未覆盖契约，而不是虚构一次通过的测试结果。

这是一种很重要的工程态度。

没有执行的验证，不能被包装成验证完成。

探索不是随机敲命令

gstack 对 QA 中的探索也提出了明确要求。

探索不是随机地执行许多命令。

它应当从前一个结果中学习，再选择下一个最有价值的验证动作。

每次新的发现性探测前，QA 会记录简短的证据说明，其中包含：

上一次结果
正在验证的假设
下一步命令

发现的问题必须可复现。

新测试必须在修复前失败，在修复后通过。

单元测试保护逻辑。

集成测试与端到端测试保护真实边界，尤其是那些模拟对象可能掩盖的问题。

这套要求让 QA 从“跑一遍看看”变成有证据链的探索过程。

`/ship`：发布不是推送代码那么简单

/ship 扮演发布工程师。

/ship

它会同步主分支、运行测试、探索变更行为、审计测试覆盖与文档，然后完成验证、推送并创建 Pull Request。

这意味着发布并不只是执行 Git 命令。

它是一次最终检查。

变更是否真的可用。

测试是否足够。

文档是否仍然正确。

是否有未被注意到的行为变化。

是否已经准备好交给审查和部署流程。

gstack 还提供 /land-and-deploy。

1	/land-and-deploy

它用于合并 Pull Request，等待持续集成与部署完成，并检查生产环境健康状态。

从“审批通过”到“生产验证完成”，发布工程师仍然留在流程中。

文档不是最后才想起来的事情

在许多项目里，文档更新通常发生在发布前的最后几分钟。

但真正的问题在于，代码行为一旦变化，文档就可能立刻开始过时。

/document-release 用于在每次发布时审查变更行为与项目文档之间的一致性。

1	/document-release

它会检查相关文档是否需要更新，并在最终验证与发布前纠正事实偏差。

如果文档改动风险较高，则需要审批，而不是默默改写。

/document-generate 则用于从零生成缺失文档。

1	/document-generate

它会先研究代码库，再按照 Diataxis 框架编写参考文档、操作指南、教程或解释性文档。

文档在 gstack 中不是一个额外负担。

它是发布质量的一部分。

从发布到复盘，软件团队需要记住自己做过什么

一轮交付结束后，团队不应该只剩下一个合并后的提交。

哪些工作推进得顺利。

哪些测试质量在变化。

哪些人或角色承担了哪些工作。

哪些问题反复出现。

哪些偏好和约束值得在未来继续使用。

gstack 用 /retro 承担工程复盘。

/retro

它可以生成团队感知的每周回顾，包括个人维度拆分、交付节奏、测试健康趋势与成长机会。

/retro global 则可以跨项目运行。

而 /learn 则用于管理跨会话积累的知识。

/learn

它可以审查、搜索、清理和导出项目级的模式、陷阱与偏好。

这让 gstack 的工作流不只从任务开始，也不会在 Pull Request 合并后立即遗忘。

经验可以沉淀。

偏好可以累积。

问题可以被再次识别。

一支虚拟团队，各自负责不同阶段

gstack 将软件交付流程拆分为多个有职责感的角色。

其中包括：

Skill	角色	主要职责
`/office-hours`	YC Office Hours	通过强制问题重新理解产品问题
`/plan-ceo-review`	CEO 或创始人	挑战范围，寻找更高价值的产品方向
`/plan-eng-review`	工程经理	确定架构、数据流、边界条件与测试计划
`/plan-design-review`	高级设计师	评估设计质量并识别 AI Slop
`/plan-devex-review`	开发者体验负责人	审查开发者角色、流程摩擦与关键体验
`/review`	Staff Engineer	审查生产风险、完整性与复杂度
`/investigate`	调试器	追踪根因，避免无依据修复
`/qa`	QA 负责人	探索真实行为、复现问题、修复并验证
`/qa-only`	QA 报告员	进行探索与证据报告，不修改代码
`/cso`	首席安全官	执行安全审计并提供明确覆盖范围
`/ship`	发布工程师	测试、审计、推送与创建 Pull Request
`/land-and-deploy`	发布工程师	合并、部署与生产健康验证
`/canary`	SRE	监控部署后的控制台错误、性能回退与页面失败
`/benchmark`	性能工程师	比较页面加载、核心 Web 指标与资源体积
`/document-release`	技术写作者	审查发布变更与文档事实一致性
`/retro`	工程经理	进行团队与工程节奏回顾
`/learn`	记忆系统	管理跨会话的项目经验与偏好

这些角色并不是为了制造更多流程。

它们的价值在于，让不同阶段都有相应的审查视角。

产品问题不应只由代码视角处理。

设计问题不应只由工程视角处理。

发布问题不应只由 Git 命令处理。

每一类风险，都需要有合适的角色去发现。

设计探索，不必只等第一个方案出现

gstack 中的设计能力不仅包括设计评审，也包括主动探索。

/design-consultation 用于从零构建设计系统。

1	/design-consultation

它会研究已有环境、提出创意风险、生成较真实的产品模型，并写入设计文档。

/design-shotgun 则用于快速生成多个方向。

1	/design-shotgun

它会创建四到六个 AI Mockup 版本，在浏览器中打开对比板，收集反馈，再继续迭代。

这种方式很适合处理“我知道想解决什么，但还不知道界面应该长什么样”的阶段。

相比死盯着第一个方案不断微调，多方案并排比较更容易发现方向本身的问题。

而当设计方向确定之后，/design-html 可以将 Mockup 或文字描述转为真正可工作的 HTML。

1	/design-html

它强调动态布局与文本重排，不把页面当成固定尺寸的截图复刻。

浏览器能力：让 Agent 真正看见产品

浏览器是许多产品问题真正发生的地方。

按钮能不能点。

输入有没有反馈。

页面是否在特定尺寸下错位。

真实会话中的认证状态是否影响流程。

控制台有没有错误。

一个完整的 UI 测试不应只依赖静态代码分析。

gstack 提供 /browse。

/browse

它让 Agent 能够驱动浏览器，查看真实页面、执行点击、获取截图与进行交互。

对于网页数据提取，gstack 提供 /scrape。

/scrape

它可以从网页中提取表格、列表、价格等结构化数据。

在 macOS 上，如果 Aside 浏览器已经启动，gstack 会优先使用 Aside。

当 Aside 不可用时，gstack 会自动切换到自身提供的 Chromium 后备浏览器。

1	/open-gstack-browser

这一命令可以启动 GStack Browser。它是一个带有侧边栏、反自动化检测能力与自动模型路由的 AI 控制 Chromium 浏览器。

如果 Agent 在验证码、认证墙或多因素认证界面前无法继续，也可以使用浏览器交接能力，将同一页面与现有 Cookie、标签页状态交给人类处理。

`/pair-agent`：让多个 Agent 看同一个网页

多 Agent 协作最容易出现的问题，是每个 Agent 都在不同环境里工作。

一个 Agent 看到了网页。

另一个 Agent 看不到同一份会话。

一个负责产品分析。

另一个负责代码修复。

但它们之间没有共享的视觉现场。

/pair-agent 用于让其他 AI Agent 连接到 gstack 的浏览器。

1	/pair-agent

它可以与 OpenClaw、Hermes、Codex、Cursor 等能够连接的 Agent 协作。

一个命令，一次粘贴，多个 Agent 就可以围绕同一个浏览器会话工作。

这让跨 Agent 协作不再只依赖文本转述。

第二意见：让不同模型互相挑战

gstack 提供 /codex 与 /claude-code。

/codex

1	/claude-code

它们用于从另一个模型环境获得独立审查、挑战或咨询。

在 Claude Code 中，可以通过 /codex 调用 OpenAI Codex CLI 的第二意见。

在 Codex 等其他环境中，则可以通过 /claude-code 获取 Claude Code 的独立审查。

这一设计不假设某一个模型在所有任务上都永远最好。

相反，它把独立视角当作工程质量的一部分。

尤其在架构判断、复杂修复、代码审查与方案挑战中，第二意见可以帮助团队发现单一推理路径中未被看见的问题。

安全护栏：需要时把边界收紧

AI Agent 可以很快，也可能很大胆。

当任务涉及生产环境、敏感目录、不可逆操作或复杂排查时，速度并不总是第一目标。

gstack 提供多个安全控制 Skill。

`/careful`

/careful

它会在执行危险命令前给出警告，例如递归删除、删除数据库、强制推送与硬重置。

`/freeze`

/freeze

它可以将文件修改限制在单一目录中，避免调试时误改范围外文件。

`/guard`

/guard

它将 /careful 与 /freeze 组合起来，适用于需要更高安全边界的工作。

`/unfreeze`

/unfreeze

它解除编辑范围限制。

这些能力体现出 gstack 的一个重要态度：

Agent 不应只被设计成更快地执行。

它也应当能在需要时被明确约束。

团队模式：把工作方法同步给整个仓库

gstack 支持团队模式。

在仓库中执行相关设置后，项目可以要求或建议成员使用 gstack。团队模式会在 Claude Code 会话启动时进行自动更新检查，并避免把大量 vendored 文件直接复制进每个项目。

README 提供的团队初始化方式如下：

1	(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"

其中，required 可以替换为 optional。

前者用于明确要求。

后者用于鼓励团队成员使用。

这种设计适合希望将 AI 辅助开发流程纳入团队规范的项目。

团队不只是共享代码，也可以共享 Agent 的工作方式。

安装：从 Claude Code 开始，也可以走向更多宿主

gstack 的基础安装依赖包括：

Claude Code
Git
Bun 1.0 或更新版本
Windows 环境下还需要 Node.js

安装时，可以将仓库克隆到 Claude Code 的 Skills 目录，再运行设置脚本。

1
2
3

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

对于更多 AI Agent，可以通过 --host 指定目标。

1
2
3

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack
./setup --host auto

也可以只安装到指定宿主：

1	./setup --host codex

查看安装状态：

1	./setup --status

状态输出会按安装记录展示宿主、层级、范围、版本与路径。

gstack 将宿主支持分为三类：

full
experimental
instruction-only

full 表示经过真实工作流认证。

experimental 表示可以安装并通过一致性测试，但尚未拥有认证运行记录。

instruction-only 则不会真正安装完整能力，而是提供需要复制给 Agent 的规则摘要。

指令摘要：即使不能安装，也可以带走方法论

并不是所有 Agent 都支持完整 Skills、Hooks 或安装机制。

对于只会读取规则文件的 Agent，gstack 提供了一份精简摘要。

它可以被复制到项目的 AGENTS.md 或其他 Agent 会读取的位置。

摘要中包含 gstack 的理念、复用路径与表达规则。

这意味着 gstack 不把自己的方法论限制在某一个工具里。

完整安装能带来自动化技能、浏览器能力、Hooks、命令与工作流。

但即使只能复制一份规则，项目仍然可以使用其核心的思考与协作方式。

GBrain：让 Agent 在会话之外保留知识

一次会话结束后，Agent 很容易忘记之前了解过的项目细节。

这会导致下一次工作又从重复阅读、重复搜索和重复解释开始。

gstack 提供与 GBrain 的集成。

GBrain 被描述为 AI Agent 的持久知识库，可以帮助 Agent 在不同会话之间保留知识。

初始化可以通过：

1	/setup-gbrain

它提供多种路径：

连接已有的 Supabase 地址
自动创建 Supabase 项目
使用本地 PGLite
连接远程 GBrain MCP

初始化后，可以将 GBrain 注册为 Claude Code 的 MCP Server，让搜索和写入能力以工具形式出现。

对于代码同步，使用：

1	/sync-gbrain

它可以增量索引代码库，也支持完整重建与预览模式。

GBrain 还支持每个远程仓库分别定义信任级别：

read-write
read-only
deny

这让不同项目可以拥有不同的知识访问边界。

有些仓库允许 Agent 搜索并写入经验。

有些仓库只允许读取共享知识。

有些仓库则完全禁止与知识库交互。

可观察的外发记录与可选遥测

gstack 的遥测默认关闭。

首次运行时，工具会询问是否愿意提供匿名使用数据。

如果用户选择开启，发送的信息包括：

Skill 名称
运行时长
成功或失败状态
gstack 版本
操作系统

README 明确说明，不会发送代码、文件路径、仓库名称、分支名称、提示词或用户生成内容。

用户可以随时关闭遥测：

1	gstack-config set telemetry off

此外，gstack 对由自身发起的离机发送会写入带哈希链的收据。

这些记录保存在：

1	~/.gstack/security/egress.jsonl

这让网络外发行为拥有可审计记录。

对于涉及多种外部模型、浏览器能力、远程知识库与可选集成的工具来说，这类明确边界尤为重要。

10 到 15 条并行 Sprint，前提是有共同流程

并行 Agent 很容易制造混乱。

十个 Agent 如果没有共同结构，可能只是十个同时修改代码、重复分析问题、互相覆盖结论的噪声源。

gstack 的核心观点是，并行能力需要建立在 Sprint 结构之上。

1	思考 → 规划 → 构建 → 评审 → 测试 → 发布 → 复盘

当不同 Agent 知道自己处在什么阶段、应当使用什么 Skill、要向下游留下什么产物时，并行工作才更容易变成协作。

一个 Agent 可以围绕新想法进行 /office-hours。

另一个 Agent 可以进行 /review。

第三个 Agent 可以执行 /qa。

第四个 Agent 可以准备 /ship。

每个工作单元都不是孤立执行，而是在同一条软件交付链上占据明确位置。

gstack 的本质，不是一组命令，而是一种软件工厂

gstack 最有意思的地方，不在于它包含多少 Slash Command。

它的价值在于，它试图把软件开发中的角色、阶段、质量门槛与知识积累组织起来。

它希望产品构思先接受质询。

希望计划先经过 CEO、设计、开发者体验与工程视角的审查。

希望实现之后仍然面对代码评审、真实 QA 与安全检查。

希望发布不只是推送代码。

希望文档不被遗忘。

希望复盘和记忆能够进入下一轮工作。

它把个人开发者从“一个人不断切换角色”的状态中，推向“一个人调度一支虚拟团队”的状态。

这支团队不会替代判断。

它会提出问题。

会挑战假设。

会要求证据。

会报告缺口。

会帮助把模糊意图拆成可验证的软件交付过程。

而这，正是 gstack 想交付的东西：不是更快地产出代码，而是更系统地把软件做出来。