gstack 使用操作手册

/office-hours · YC Office Hours

具体用法：

> /office-hours
> /office-hours 我想给应用加 AI 总结功能
> /office-hours --depth deep   # 更激进的挑战模式

调用后 Agent 会问 6 个强制性问题，逐题回答，不能跳过：

1. 用户具体在什么场景说"想要"？给 3 个真实引用
2. 这事在 OKR 里排第几？不做会失去多少用户？
3. 有没有"成本更低 80% 价值"的替代方案？
4. ……

讨论结束后产出 DESIGN.md（或 docs/superpowers/specs/YYYY-MM-DD-<name>-design.md），后续所有 Skill 都会读它。

为什么这样设计：

Garry Tan 在 YC 做了 10 年 office hours，发现 90% 创业失败不是执行问题，是做错了产品——做了用户说要的，错过了用户真正需要的。这个 Skill 把 YC 的提问框架代码化：用问题暴露假设，用替代方案打破执着。

这样用的好处：

• ✅ 砍掉 60% 不必要范围：很多"必须功能"在追问下其实是"想要"
• ✅ 提前暴露伪需求：5 分钟对话省掉 5 天白做工
• ✅ 产出 design doc 是后续 Skill 的输入：跳过它 → /autoplan 没有评审对象
• ✅ 训练你的产品直觉：用多了会内化这 6 个问题

/autoplan · Review Pipeline

具体用法：

> /autoplan
> /autoplan --skip ceo,design   # 跳过特定视角
> /autoplan --only eng          # 只跑工程视角

会自动按需调度 4 个 Skill：/plan-ceo-review → /plan-design-review → /plan-eng-review → /plan-devex-review，并把所有需要你拍板的"品味决策"打包成单次 AskUserQuestion。

为什么这样设计：

这是"智能调度"的体现——纯后端服务不需要 design review，纯 SDK 不需要 design review。手动跑 4 个命令容易遗漏或重复，/autoplan 根据需求类型自动判断哪些视角适用。

这样用的好处：

• ✅ 省 60% 时间：相比手动一个个跑 plan-*-review
• ✅ 不会漏视角：Agent 自动判断当前需求需要哪几种 review
• ✅ 决策点集中：一次性问完所有要你定的事，不打断思路
• ✅ 编码了决策原则：经验沉淀进 Skill，不依赖你记住

/plan-ceo-review · CEO / Founder 视角

具体用法：

> /plan-ceo-review
> /plan-ceo-review --mode expansion       # 扩展模式
> /plan-ceo-review --mode hold-scope      # 保持现有范围
> /plan-ceo-review --mode reduction       # 缩减模式

4 种模式：

• Expansion：挖隐藏的 10 星产品（"你做的不是 X，是 Y"）
• Selective Expansion：保留核心，挑战 1-2 个维度
• Hold Scope：仅做合规挑战，不扩范围（已 ship 周期）
• Reduction：砍范围（资源紧 / 期限紧）

为什么这样设计：

CEO 视角和工程师视角天然冲突——工程师想"全部都做"，CEO 想"做最赚的那个"。把 CEO 思维代码化，让 AI 在你激情澎湃想做大功能时帮你踩刹车。

这样用的好处：

• ✅ 找到 10 星产品：你描述"日报 App"，AI 指出你其实在做"AI 助理"
• ✅ 避免范围爆炸：早期就把 V2/V3 的事剥离
• ✅ 4 种模式覆盖不同阶段：早期用 expansion，成熟期用 hold-scope

/plan-eng-review · 工程经理视角

具体用法：

> /plan-eng-review

产出包含：

• ASCII 数据流图（请求 → 服务 → DB）
• 状态机图（订单 / 用户状态等）
• 错误路径表（每个 step 的失败处理）
• 测试矩阵（输入边界 × 期望输出）
• 失败模式分析（FMEA 简化版）

为什么这样设计：

大多数 AI 产生的代码都"看起来对、跑起来错"——因为 AI 没有把架构画出来过。强制 ASCII 数据流图是让 AI 把隐含假设显式化。状态机能防止"3 个布尔 = 8 种状态"的失控组合爆炸。

这样用的好处：

• ✅ 架构问题前置发现：在写代码前就发现"这个状态机没法表达取消订单"
• ✅ 测试矩阵自动转单测：后续 /ship 可直接用
• ✅ code review 时有据可依：同事看到数据流图秒懂改动影响范围

/plan-design-review · 设计师视角

具体用法：

> /plan-design-review

会对每个设计维度打 0-10 分，并解释什么是 10 分：

• 视觉层级（信息密度 vs 留白）
• 交互反馈（loading / error / empty 三态）
• 响应式布局（5 个断点）
• 无障碍（ARIA / 对比度 / 键盘）
• 动效合理性
• AI Slop 检测（千篇一律的 bot 模板）

为什么这样设计：

"AI Slop" 是 Garry Tan 创造的术语——指 AI 默认产出的"看似漂亮实则套模板"的设计：渐变背景 + 中心对齐表单 + 紫色按钮。这种设计 2024 年还能用，2026 年用户一眼识破。Skill 显式列出 AI Slop 模式，强制 Agent 偏离它。

这样用的好处：

• ✅ 避免"AI 设计味"：差异化产品视觉
• ✅ 0-10 打分量化：知道还差多少能 ship
• ✅ 逐项交互式确认：一次只问一个，不被信息淹没

/plan-devex-review · 开发者体验视角

具体用法：

> /plan-devex-review
> /plan-devex-review --mode polish    # 已有 SDK 优化
> /plan-devex-review --mode triage    # 时间紧，找最值得改的

对标 TTHW（Time-To-Hello-World）—— 从开发者第一次看文档到运行第一个 demo 的时间。Stripe、Vercel、OpenAI 的 TTHW 都 < 5 分钟。

3 种模式：DX EXPANSION（从零设计 SDK）、DX POLISH（优化已有 SDK）、DX TRIAGE（找改一个最值得的）。20-45 个强制问题。

为什么这样设计：

SDK / API / CLI 的成败 90% 在 DX。/plan-design-review 是给终端用户的，/plan-devex-review 是给开发者用户的。两者用户群不同 → 评审维度完全不同。

这样用的好处：

• ✅ 找到 friction point：哪一步把 50% 用户劝退？
• ✅ 对标头部 SDK：你的 TTHW vs 行业最佳
• ✅ 设计"魔法时刻"：让开发者"第一次跑通"产生 wow

/design-shotgun · 设计探索

具体用法：

> /design-shotgun 登录页大改版，要"未来感"但别太花
> /design-shotgun --variants 6      # 生成 6 个变体（默认 4-6）
> /design-shotgun --refine 2,4      # 基于第 2、4 个再生成新一轮

Agent 会：

1. 调用 GPT Image 同时生成 4-6 个 mock 变体
2. 在浏览器打开对比板（4 张并列）
3. 等你给反馈（"②好但太像 Stripe"）
4. 基于反馈生成下一轮，直到你满意
5. 把你的偏好存入 taste memory（跨项目复用）

为什么这样设计：

"用文字描述视觉"是反人类的——你说"现代但不花哨"，AI 给你的可能差得远。看到选项再选比文字描述快 10 倍。Taste memory 学习你的偏好后，第 3 个项目开始 AI 自动避开你不喜欢的风格。

这样用的好处：

• ✅ 视觉直觉直接调用：不用翻译成文字
• ✅ 跨项目偏好累积：3 个项目后 AI 懂你"喜欢留白、讨厌渐变"
• ✅ 一轮 5 分钟 vs 反复改 2 小时：效率碾压传统流程

/design-html · 设计转代码

具体用法：

> /design-html ./mock-final.png
> /design-html --framework react      # 显式指定框架
> /design-html --type dashboard       # 类型路由（landing/dashboard/form）

把 mock 图片变成生产级 HTML/CSS。自动检测项目框架（React/Svelte/Vue），用 Pretext 计算文本布局——文字真的会随宽度 reflow，高度真的会随内容调整。

为什么这样设计：

普通 AI 写 HTML 的通病：硬编码像素 → 在某个屏幕宽度看着对、其他都崩。Pretext 是 Garry 团队开发的计算布局库（30KB 零依赖），文字宽度由计算得出而非硬编码。智能 API 路由根据布局类型选不同 Pretext 模式（landing 用 hero pattern，dashboard 用 grid）。

这样用的好处：

• ✅ 真正响应式：不只是写了 @media，是数学计算的 reflow
• ✅ shippable 不是 demo：直接进生产，不用 dev 重写
• ✅ 30KB 开销：比 Tailwind + 任意 UI 库小 90%

/review · 资深工程师视角

具体用法：

> /review                    # 审当前 diff
> /review --base main        # 与 main 对比
> /review --autofix          # 找到的问题自动修
> /review --strict           # 更严格（发现 nice-to-have 也报）

会查的"CI 通过但生产爆炸"问题：

• SQL 拼接 / N+1 查询
• LLM 调用未做信任边界（用户输入直接进 prompt）
• 条件副作用（if 块里偷偷改了 state）
• Promise 未 await / Race condition
• 边界条件遗漏（空数组、null、undefined）

对每个问题分级：AUTO-FIXED（已自动修）/ ASK（需你拍板）/ FYI（仅提醒）。

为什么这样设计：

普通 ESLint / Prettier 抓的是"语法 / 风格"问题。/review 抓的是"语义级"问题——这些往往只在生产数据下暴露，本地测试发现不了。比如 SQL 拼接看起来对，跑一年没事，直到有用户名带 '。

这样用的好处：

• ✅ 覆盖 CI 抓不到的层：和 lint 互补不重复
• ✅ 简单问题自动修：你只需对 ASK 分类做决策
• ✅ 每次合并前的最后关卡：拦下 80% 生产事故

/cso · 安全官视角

具体用法：

> /cso                                  # 全量扫描
> /cso --focus "auth,payment"           # 聚焦特定模块
> /cso --threshold 9                    # 只报 9 分以上的（默认 8）
> /cso --include-fp                     # 包含 false positive（学习用）

OWASP Top 10 + STRIDE 威胁建模。零噪音模式：

• 17 个 false positive 排除规则（不报告"明显但不是漏洞"的事）
• ≥8/10 confidence 才报（避免狼来了）
• 每个发现独立验证（用第二轮 LLM check）
• 必须包含具体利用场景（不是"理论上可能"）

为什么这样设计：

传统安全扫描器（Snyk / Semgrep / Bandit）的通病：一次报 200 条，开发者关掉。/cso 反其道而行：宁少勿滥，每条都附带可执行的攻击 PoC（如 curl ...）。这种风格让开发者真的会处理。

这样用的好处：

• ✅ 真问题：8/10 + 验证 → 几乎 0 个 false positive
• ✅ 有 PoC：可以直接在 staging 复现验证
• ✅ 低噪音 = 真的有人看：传统扫描的 200 条没人读

/investigate · 系统化调试

具体用法：

> /investigate
> /investigate 支付按钮 5% 概率不响应
> /investigate --logs ./logs/2024-01-15.log
> /investigate --max-attempts 5     # 默认 3 次失败后停止

4 阶段方法论：Reproduce → Isolate → Fix → Verify。每阶段不通过不能进下一阶段。

铁律："NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST"。

为什么这样设计：

新手 / AI 调试的通病：直接跳到 Fix 阶段，"应该是 X 问题，改一下试试"。结果修了一处坏了三处。/investigate 强制走 4 阶段，3 次失败修复后自动停止——避免越调越乱。

这样用的好处：

• ✅ 找到真根因：不再是"症状缓解"
• ✅ 3 次熔断：避免无限尝试浪费时间
• ✅ 有日志可追溯：每个假设和测试结果都记录

/qa <url> · 真实浏览器 QA

具体用法：

> /qa https://staging.example.com
> /qa http://localhost:3000 --flow login,checkout
> /qa --auth-cookies ./cookies.json   # 已登录态测试
> /qa --mobile                         # 移动视口

启动真 Chromium（不是模拟器），按以下步骤工作：

1. 探索页面，识别核心 user flow
2. 真点击、真输入、真验证
3. 发现 Bug 后自动修复（原子提交）
4. 修复后自动生成 regression test（Playwright/Cypress）
5. 重新跑 flow 验证

为什么这样设计：

单元测试 + 集成测试覆盖不到的 30% bug 都在用户流层级——比如"按钮按了 loading，但 API 没调"。这种 bug 只有真浏览器跑过才发现。/qa 给 Agent "一双眼睛"，从此 Agent 不再只能猜测页面行为。

这样用的好处：

• ✅ 找到 e2e 层 bug：UT 抓不到的 30% 错误
• ✅ 修了一个 + 一个 regression test：永久免疫
• ✅ 让并行 Agent 真正可行：Garry 自己说 /qa 让他从 6 → 12 并行 worker

/benchmark · 性能基线

具体用法：

> /benchmark https://example.com           # 建立基线
> /benchmark --compare main                # 与 main 分支对比
> /benchmark --metric LCP,FCP,CLS          # 只测核心 vitals

测三件事：

• 页面加载时间（FCP / LCP / TTI）
• Core Web Vitals（LCP / CLS / INP）
• 资源大小（JS / CSS / Image）

为什么这样设计：

性能回归是"缓慢累积"——这周加 50ms，下周再加 80ms，半年后页面卡。每个 PR 都跑 benchmark 是把累积变成可见。

这样用的好处：

• ✅ 性能回归早发现：单 PR 多 100ms 就拦下
• ✅ 数据驱动决策：不再"感觉慢"
• ✅ 对标行业基准：知道你和 Stripe / Vercel 差多少

/ship · PR 自动化

具体用法：

> /ship                              # 标准流程
> /ship --hotfix                     # 热修复（跳过部分门禁）
> /ship --no-test                    # 跳测试（紧急时用）
> /ship --base develop               # 指定 base 分支

完整流程：

1. 同步 main / develop（避免落后）
2. 跑测试（有就用，没有自动 bootstrap 测试框架）
3. 覆盖率审计（生成 coverage report）
4. git push
5. 用 gh CLI 开 PR，正文自动生成（含 changes / tests / screenshots）

为什么这样设计：

Ship 流程的"碎"是开发者最大痛点——同步、跑测试、推、写 PR 描述、贴截图……每个动作 1 分钟，5 个动作 5 分钟，每天若干次。/ship 把这些原子化为单命令。

这样用的好处：

• ✅ 从 5 分钟 → 30 秒
• ✅ PR 描述质量高：自动包含 diff 摘要、测试覆盖、截图
• ✅ 没测试框架自动 bootstrap：新项目第一次 ship 顺便配 Vitest/Jest

/land-and-deploy · 部署一条龙

具体用法：

> /land-and-deploy
> /land-and-deploy --priority urgent     # 紧急部署
> /land-and-deploy --skip-canary         # 跳过金丝雀（小改）
> /land-and-deploy --env staging         # 指定环境

从"PR approved"到"verified in production"全自动：

1. 合并 PR（squash merge）
2. 等 CI 通过
3. 触发部署（Vercel / Railway / Fly.io / 自定义脚本）
4. 等部署完成
5. 跑 production health check（关键 endpoint）
6. 30 分钟内监控 Sentry / DataDog

为什么这样设计：

"approved 后到生产 OK"之间通常有 4-6 个动作，工程师容易在中间环节出错（忘了部署 / 没看 health check）。/land-and-deploy 把它们串成一个事务：任一步失败自动停止 + 通知。

这样用的好处：

• ✅ 不用守着部署：触发后做别的事
• ✅ 失败自动停：避免坏代码进生产
• ✅ 30 分钟监控：捕获部署后的延迟问题

/canary · 部署后监控

具体用法：

> /canary --duration 30m
> /canary --duration 2h --alerts slack    # 告警发 Slack
> /canary --baseline yesterday            # 对比昨日基线

监控 3 类指标：

• Console error 频率（前端）
• 性能回归（Core Web Vitals 偏移）
• 页面失败（5xx / 超时）

异常超阈值自动 ping 你（或 Slack）。

为什么这样设计：

部署 ≠ 没问题。30% 的生产故障在部署后 30 分钟才暴露（缓存、CDN、长连接）。/canary 让你在事故升级前发现。

这样用的好处：

• ✅ 缩短 MTTR：5 分钟发现 vs 用户投诉后 2 小时
• ✅ 免费的"上线值守"：以前要工程师盯着
• ✅ 异常对比基线：知道是新问题还是老问题

/freeze · 编辑锁

具体用法：

> /freeze src/payment              # 只允许改这个目录
> /freeze src/auth tests/auth      # 多个目录
> /freeze .                        # 锁定整个项目（只读）
> /unfreeze                        # 解锁

为什么这样设计：

AI 在调试一个 bug 时，常会"顺手"重构旁边的模块（"反正看着不顺眼"）——这种意外改动是生产事故的常见来源。/freeze 给 Agent 划红线。

这样用的好处：

• ✅ 避免 scope creep：debug 时不会越界改其他模块
• ✅ diff 干净：PR review 不会被无关改动淹没
• ✅ 调试期心理安全：放心让 AI 探索

/careful · 危险命令护栏

具体用法：

> /careful                # 启用危险命令警告
> /careful off            # 关闭

启用后，以下命令执行前会先警告并让你确认：

• rm -rf
• SQL DROP / TRUNCATE / DELETE FROM
• git force-push / reset --hard / clean -fdx
• kubectl delete
• npm publish

为什么这样设计：

AI 跑命令的速度比人快 100 倍——也意味着错误传播速度也快 100 倍。一个 rm -rf $UNDEFINED_VAR/ 几秒就能毁掉 home 目录。

这样用的好处：

• ✅ 关键时刻多 1 秒：足够你看出"等等不对"
• ✅ 不影响日常命令：只警告高风险
• ✅ 覆盖最容易踩的坑：基于真实事故复盘

/guard · 全模式保险

具体用法：

> /guard
# 等价于：/careful + /freeze [当前目录]

为什么这样设计：

生产环境作业（hotfix、紧急回滚、数据迁移）需要双重保险。/guard 一键开启。

这样用的好处：

• ✅ 降低生产作业心智负担：一个命令而不是两个
• ✅ 明确进入"高警觉模式"：自己也会更专注

/learn · 跨 Session 项目记忆

具体用法：

> /learn                              # 列出已学习的内容
> /learn add "我们的 API 错误码用 4 位数字"
> /learn add "src/legacy/ 不要动，正在弃用"
> /learn search 错误码
> /learn prune                        # 清理过期项
> /learn export                       # 导出（备份 / 分享给同事）

为什么这样设计：

每次新 Session，Agent 都"失忆"——你要重新解释项目约定。/learn 把项目特定知识持久化到本地，下次新 Session 自动加载。这是把 Agent 训练成"老员工"的关键。

这样用的好处：

• ✅ 越用越懂你的代码库：累积记忆 vs 每次失忆
• ✅ 团队共享知识：导出给同事的 onboarding 加速 5 倍
• ✅ 防止"踩同一个坑两次"：bug 和教训写进去就不会重犯

/retro · 复盘

具体用法：

> /retro                       # 当前项目本周复盘
> /retro --period month        # 月度
> /retro global                # 跨所有项目和 AI 工具
> /retro --team               # 含每个成员的明细

产出：

• 本周 ship 频率（PR / commit / lines）
• 测试健康趋势（覆盖率、通过率）
• 每人 streak（连续 ship 天数）
• 成长机会（哪些 skill 用得少？）

为什么这样设计：

"AI 让我多产 X 倍"是直觉，/retro 让它变成数据。看到自己 ship 节奏的拐点，是优化工作流最强的反馈。

这样用的好处：

• ✅ 数据驱动选工具：看到 /qa 用得多 → 验证 ROI
• ✅ 每周可视化进步：心理上很爽
• ✅ 找到瓶颈：哪个阶段卡得最久？