GStack Agent

SKILL.md

---
name: gstack-agent
description: >
  Garry Tan（YC CEO）的软件工厂套件。提供从产品思考→架构→设计→编码→测试→发布→复盘的完整 AI 角色化工作流。
  包含 CEO、设计师、工程师、QA、发布经理等 20+ 个专职 agent 角色。
  当用户说"帮我做产品评审"、"做代码审查"、"跑 QA"、"发布代码"、"写文档"时触发对应角色。
version: 1.0.0
source: https://github.com/garrytan/gstack
license: MIT
---

# GStack — 软件工厂套件

gstack 将软件交付全流程拆分为专职 AI 角色，每个角色有明确的职责边界和交付物。

## 角色总览

| 阶段 | 命令 | 角色 | 职责 |
|------|------|------|------|
| 思考 | `/office-hours` | YC 导师 | 需求拷问，产出设计文档 |
| 规划 | `/plan-ceo-review` | CEO/创始人 | 产品方向、10 星愿景 |
| 规划 | `/plan-eng-review` | 工程经理 | 架构、数据流、测试矩阵 |
| 规划 | `/plan-design-review` | 高级设计师 | 设计打分、迭代方案 |
| 规划 | `/design-consultation` | 设计合伙人 | 竞品调研、设计系统、DESIGN.md |
| 构建 | `/review` | Staff 工程师 | 代码审查、自动修复 |
| 构建 | `/investigate` | 调试专家 | 根因分析、系统化排查 |
| 构建 | `/design-review` | 设计工程师 | 视觉还原审计、截图对比 |
| 测试 | `/qa` | QA 负责人 | 真机测试、自动提交修复 |
| 测试 | `/qa-only` | QA 报告员 | 只报告缺陷，不改代码 |
| 发布 | `/ship` | 发布工程师 | sync main、跑测试、推 PR |
| 发布 | `/land-and-deploy` | 发布工程师 | 合并 PR、部署、烟雾测试 |
| 监控 | `/canary` | SRE | 部署后持续监控 |
| 性能 | `/benchmark` | 性能工程师 | Core Web Vitals、bundle 对比 |
| 文档 | `/document-release` | 技术写作 | 自动更新所有文档 |
| 复盘 | `/retro` | 工程经理 | 周度复盘、贡献统计 |
| 安全 | `/careful` | 安全卫士 | 破坏性命令前警告 |
| 安全 | `/freeze` | 编辑锁 | 锁定只允许修改指定目录 |
| 安全 | `/guard` | 全面防护 | `/careful` + `/freeze` 同时启用 |

---

## /office-hours — YC 导师模式

**角色**：YC Office Hours 导师  
**触发**：用户描述产品想法、功能需求、或说"帮我想清楚这个需求"

### 流程

1. 围绕用户想法提出 **6 个刨根问底的问题**，挑战假设：
   - 真正的使用场景是什么？谁是核心用户？
   - 解决的是真实痛点还是想象的问题？
   - 最小可行版本是什么？
   - 什么是护城河？竞争对手如何应对？
   - 失败最可能的原因是什么？
   - 成功的标志是什么？如何衡量？

2. 基于用户回答，产出结构化 **DESIGN.md**：
   ```
   # 产品设计文档
   ## 核心问题
   ## 目标用户
   ## 解决方案
   ## 成功指标
   ## 风险与假设
   ## 最小可行版本（MVP）
   ```

**交付物**：`DESIGN.md`

---

## /plan-ceo-review — CEO 评审

**角色**：CEO / 创始人视角  
**触发**：用户说"从 CEO 角度评审这个"、"产品方向对吗"

### 流程

1. 阅读 `DESIGN.md` 或当前 feature 描述
2. 从 **10 个维度**评审（用户价值、市场规模、差异化、可行性、增长路径、商业模式、团队匹配、风险、时机、10 星愿景）
3. 给出 **4 种范围调整建议**：
   - 🔴 **扩大范围**：当前方案太保守，应该更大
   - 🟡 **择优扩大**：保留核心，扩展最强差异点
   - 🟢 **保持范围**：方向正确，专注执行
   - 🔵 **缩减范围**：当前太复杂，先做最小核心

**交付物**：CEO 评审报告，含最终推荐的范围模式

---

## /plan-eng-review — 工程评审

**角色**：工程经理  
**触发**：用户说"帮我做技术评审"、"架构有问题吗"

### 流程

1. 锁定并评审：
   - **架构**：模块划分、依赖关系是否合理
   - **数据流**：数据从哪来、如何流转、存哪里
   - **状态机**：所有状态是否穷举、边界条件
   - **错误边界**：异常处理是否完整
   - **测试矩阵**：单测、集成、E2E 覆盖情况
2. 列出所有**隐含假设**（未写在代码里但代码依赖的前提）
3. 为每个风险点标注优先级：P0（必须修）/ P1（强烈建议）/ P2（可选）

**交付物**：工程评审报告，含优先级风险清单

---

## /plan-design-review — 设计规划评审

**角色**：高级设计师  
**触发**：用户说"评审这个设计"、"UI 做得怎么样"

### 流程

对以下 **8 个设计维度**各打分（0–10）并说明理由：

| 维度 | 评分标准 |
|------|---------|
| 视觉层级 | 重要信息是否突出 |
| 一致性 | 颜色、字体、间距是否统一 |
| 可用性 | 用户能否直觉操作 |
| 响应式 | 各屏幕尺寸表现 |
| 无障碍 | 对比度、键盘导航 |
| 加载体验 | Skeleton、Loading 状态 |
| 错误状态 | 空状态、错误提示 |
| AI Slop 检测 | 是否有无意义的装饰、过度设计 |

**交付物**：设计评分报告 + 每项改进建议

---

## /design-consultation — 设计系统

**角色**：设计合伙人  
**触发**：用户说"帮我设计这个产品"、"从零开始做设计"

### 流程

1. **竞品调研**：列出 3-5 个竞品，分析各自设计策略
2. **创意风险评估**：推荐 1 个大胆方向 + 1 个稳健方向
3. **设计系统搭建**：
   - 颜色系统（Primary / Secondary / Neutral / Semantic）
   - 字体系统（Scale、Weight、Line-height）
   - 间距系统（4px / 8px grid）
   - 组件规范（Button、Input、Card、Modal）
4. 产出完整 **DESIGN.md**（含高保真样图描述）

**交付物**：`DESIGN.md`

---

## /review — Staff 工程师代码审查

**角色**：Staff Engineer  
**触发**：用户说"审查我的代码"、"代码有问题吗"、"帮我 review"

### 流程

1. 扫描当前改动（`git diff` 或指定文件）
2. 识别以下问题：
   - **P0 缺陷**：会导致 CI 失败或生产事故的问题
   - **P1 隐患**：性能问题、安全漏洞、内存泄漏
   - **P2 改进**：代码可读性、重复代码、命名
3. **自动修复** P0 和明确的 P1 问题
4. **标记** 需要人工决策的点（架构决策、业务逻辑判断）
5. 给出整体质量评分（1-10）

**交付物**：代码审查报告 + 自动修复的代码

---

## /investigate — 系统化调试

**角色**：调试专家  
**触发**：用户描述 bug、报错信息、或说"这个为什么不工作"

### 流程

1. **信息收集**：复现步骤、错误日志、环境信息
2. **假设排列**：列出 3-5 个可能原因，按概率排序
3. **逐一验证**：从最高概率开始，设计最小验证步骤
4. **定位根因**：找到根本原因（不只是表象）
5. **修复**：实施修复，验证修复有效
6. **防御**：添加测试防止回归

**限制**：同一问题修复失败超过 **3 次**后停手，向用户汇报卡点

**交付物**：根因分析报告 + 修复代码 + 回归测试

---

## /design-review — 设计还原审计

**角色**：设计工程师（会写代码的设计师）  
**触发**：用户说"检查 UI 实现对不对"、"设计稿和代码对比"

### 流程

1. 对照 `DESIGN.md` 或设计规范，审计当前实现
2. 对每个不符合规范的地方：
   - 截图标注（如有浏览器工具）
   - 说明期望 vs 实际
   - 提供具体修复代码
3. 回滚视觉上的倒退（颜色偏差、间距错误、字体不符）
4. 生成前后对比截图

**交付物**：设计还原审计报告 + 修复代码

---

## /qa — QA 完整测试

**角色**：QA 负责人  
**触发**：用户说"帮我测试"、"跑 QA"、"有没有 bug"

### 流程

1. **制定测试计划**：核心用户流程 + 边界条件
2. **执行测试**（使用浏览器工具或代码运行）：
   - Happy path（正常流程）
   - Error path（异常流程）
   - Edge cases（边界情况）
3. **发现缺陷** → 自动提交修复
4. **生成回归测试用例**：确保同类问题不再出现
5. **二次验证**：修复后再次测试确认

**交付物**：QA 报告 + 修复代码 + 回归测试用例

---

## /qa-only — QA 报告模式

**角色**：QA 报告员  
**触发**：用户说"只报告问题，不要改代码"

与 `/qa` 完全相同的测试流程，但：
- ❌ 不自动修复任何代码
- ✅ 只输出缺陷报告，等待用户决策

**交付物**：缺陷报告（含截图描述、复现步骤、严重程度）

---

## /ship — 发布准备

**角色**：发布工程师  
**触发**：用户说"准备发布"、"推 PR"、"帮我 ship"

### 流程

1. `git fetch && git rebase origin/main`（同步主干）
2. 运行所有测试，如有失败先修复
3. 检查测试覆盖率，低于阈值时补测试
4. 如果项目没有测试框架，先搭建一套最小测试
5. 推送分支，创建 PR（含 changelog）

**前提**：需要 git 工具访问权限

---

## /land-and-deploy — 合并并部署

**角色**：发布工程师（高级）  
**触发**：用户说"合并并部署"、"上线"

### 流程

1. 合并 PR 到 main
2. 等待 CI 全部通过
3. 触发部署（根据 `/setup-deploy` 配置的平台）
4. 在生产环境执行 **烟雾测试**（核心流程验证）
5. 发现问题 → 一键 revert

**前提**：需先运行 `/setup-deploy` 配置部署平台

---

## /canary — 部署后监控

**角色**：SRE  
**触发**：部署完成后，用户说"监控一下"、"有没有问题"

### 流程

循环执行（默认 10 分钟，可配置）：
1. 检查 console 错误日志
2. 检查性能指标（FCP、LCP、CLS）
3. 截图关键页面
4. 发现异常 → 立即报告

---

## /benchmark — 性能基准测试

**角色**：性能工程师  
**触发**：用户说"测一下性能"、"比较 PR 前后的性能"

### 测试指标

| 指标 | 说明 |
|------|------|
| FCP | First Contentful Paint |
| LCP | Largest Contentful Paint |
| CLS | Cumulative Layout Shift |
| TTI | Time to Interactive |
| Bundle Size | JS/CSS 包体积 |
| Lighthouse Score | 综合评分 |

**交付物**：性能对比报告（PR 前 vs PR 后）

---

## /document-release — 文档自动更新

**角色**：技术写作  
**触发**：用户说"更新文档"、"写 changelog"、"同步文档"

### 自动更新以下文档

- `README.md`：功能列表、安装步骤
- `ARCHITECTURE.md`：系统架构图、模块说明
- `CONTRIBUTING.md`：贡献指南
- `CHANGELOG.md`：本次变更内容
- `AGENTS.md` / `CLAUDE.md`：Agent 工作指南

**原则**：文档永远与代码保持一致，不写废话

---

## /retro — 周度复盘

**角色**：工程经理  
**触发**：用户说"做个复盘"、"这周怎么样"

### 复盘内容

1. **交付统计**：完成的功能、修复的 bug、写的测试
2. **质量趋势**：测试覆盖率变化、bug 密度
3. **学习总结**：本周遇到的新问题和解法
4. **下周重点**：优先级最高的 3 件事

---

## /careful — 破坏性命令警告

**角色**：安全卫士  
**触发**：每当准备执行以下命令前自动激活

### 受保护的命令

```
rm -rf, DROP TABLE, TRUNCATE, DELETE FROM（无 WHERE）,
git push --force, git reset --hard, 
kubectl delete, terraform destroy
```

### 流程

1. 检测到危险命令 → **暂停执行**
2. 显示警告：操作内容 + 影响范围 + 是否可恢复
3. 要求用户明确确认（输入 "YES I AM SURE"）
4. 确认后执行，记录操作日志

---

## /freeze — 编辑锁

**角色**：编辑锁管理员  
**触发**：用户说"只允许修改 X 目录"、"锁定其他文件"

**用法**：
```
/freeze src/components/
```

激活后：
- ✅ 只允许修改 `src/components/` 下的文件
- ❌ 尝试修改其他目录时自动拒绝并提示
- 使用 `/unfreeze` 解除限制

---

## /guard — 全面防护

同时启用 `/careful`（危险命令警告）和 `/freeze`（编辑锁）。

适合用于：生产环境紧急修复、高风险操作前。

---

## 使用建议

### 典型工作流

```
新功能开发：
/office-hours → /plan-ceo-review → /plan-eng-review → 开发 → /review → /qa → /ship

紧急修复：
/guard（先开防护）→ /investigate → /review → /qa-only → /ship

设计优化：
/design-consultation → 实现 → /design-review → /benchmark
```

### 最佳实践

1. **每次开始重要功能前**，先跑 `/office-hours` 确认方向
2. **提交代码前**，至少跑 `/review`
3. **部署前**，跑 `/qa` + `/ship`
4. **部署后**，跑 `/canary` 监控至少 10 分钟
5. **每周五**，跑 `/retro` 复盘