Superpowers / agent-skills / gstack 三件套使用手册
版本：v1.0 | 适用平台：Claude Code | 最后更新：2026年4月
目录
第一部分：单独项目使用手册
- 第1章 Superpowers 使用手册
- 第2章 agent-skills 使用手册
- 第3章 gstack 使用手册
第二部分：组合使用指南
- 第4章 如何同时安装三件套
- 第5章 三件套组合的职责分工模型
- 第6章 分场景的推荐使用流程
- 第7章 实战案例：完整项目开发流程
第一部分：单独项目使用手册
第1章 Superpowers 使用手册
1.1 项目定位
Superpowers = 你的AI编码纪律官
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
作者：Jesse Vincent (Prime Radiant) Stars：~107K License: MIT
核心理念：
"AI的问题不是能力，而是缺乏纪律。"
→ Superpowers 强制你走完一套标准化的工程流程
工作方式：
自动触发（不是手动/command调用）
你 just 描述需求 → Superpowers 自动进入第1阶段
不遵循流程 → 代码被删，从头开始
1.2 安装
标准安装
# 在 Claude Code 中执行：
/plugin install superpowers@claude-plugins-official
# 或通过作者的市场安装：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
安装后验证
在 Claude Code 中输入任何需求，观察是否自动触发 brainstorming 流程：
- ✅ 出现 "Let's brainstorm this" 或类似话术 → 安装成功
- ❌ 直接开始写代码 → 安装失败，检查 plugin 是否已激活
1.3 核心技能清单
Superpowers 有 14 个核心技能，分 5 组：
组1：元技能（管理所有技能的系统）
| 技能 | 触发条件 | 作用 |
|---|---|---|
| using-superpowers | 会话启动时自动加载 | 入口技能。教会 AI 如何发现和调用其他技能。必须安装 |
| writing-skills | 当你需要创建新技能时 | 用 TDD 方法论编写新 SKILL.md，日常开发不需要 |
组2：规划阶段（功能开发前使用）
| 技能 | 触发条件 | 作用 |
|---|---|---|
| brainstorming | 任何功能开发前自动触发 | Socratic 问答式需求澄清。AI 会不断追问你，直到需求清晰。核心技能 |
| writing-plans | brainstorming 完成后自动触发 | 将批准的设计拆解为 2-5 分钟的任务，每个任务含精确文件路径。核心技能 |
| using-git-worktrees | 计划完成后自动触发 | 在 .worktrees/ 中创建隔离分支，并行开发不污染主工作区。可选 |
组3：执行阶段（核心开发流程）
| 技能 | 触发条件 | 作用 |
|---|---|---|
| executing-plans | 计划已就绪时 | 按计划批量执行，每个任务完成后做 checkpoint。核心技能 |
| subagent-driven-development | 计划包含可并行独立任务时 | ⭐ 旗舰技能。每个任务派发独立子代理执行，两阶段审核（合规→质量）。推荐使用 |
| test-driven-development | 任何实现代码开始前强制触发 | 强制 RED-GREEN-REFACTOR。先写测试→测试失败→写实现→重构。核心技能 |
| dispatching-parallel-agents | 多个独立问题域 | 为不同领域同时派发子代理。大型项目推荐 |
组4：审查阶段
| 技能 | 触发条件 | 作用 |
|---|---|---|
| requesting-code-review | 每个任务完成后 | 预审查清单 + 结构化 diff 审查，按严重度分级。核心技能 |
| receiving-code-review | 你给出审查意见时 | 教 AI 如何专业回应反馈——不同意的要据理力争。可选 |
| systematic-debugging | 遇到 Bug 时 | 4 阶段根因分析：调查→模式分析→假设→修复。推荐使用 |
| verification-before-completion | 任务结束前 | 必须运行全新的验证命令，不能复用之前的输出。核心技能 |
组5：收尾阶段
| 技能 | 触发条件 | 作用 |
|---|---|---|
| finishing-a-development-branch | 所有任务完成后 | 验证→选择合并/PR/保留/丢弃→清理。核心技能 |
1.4 完整工作流（7个强制阶段）
Superpowers 7 阶段强制流程
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ 阶段 1：需求澄清 │
│ ───────────────────────────────────── │
│ 触发技能：brainstorming │
│ 做什么：AI 通过 Socratic 提问法（追问5-10轮）把你的模糊想法变成 │
│ 清晰的功能需求 │
│ 你的角色：回答问题，确认方向 │
│ │
│ ▼ │
│ │
│ 阶段 2：写规格文档 │
│ ───────────────────────────────────── │
│ 触发技能：brainstorming（第二阶段） │
│ 做什么：基于澄清的需求，生成 SPEC 文档（目标/结构/测试计划/边界条件） │
│ 你的角色：逐段审批，确认才能进入下一阶段 │
│ │
│ ▼ │
│ │
│ 阶段 3：写计划 │
│ ───────────────────────────────────── │
│ 触发技能：writing-plans │
│ 做什么：将 SPEC 拆解为 2-5 分钟的原子任务 │
│ ⭐ 要求：每个任务必须有明确的文件路径、完整代码、验证步骤 │
│ ❌ 禁止："TBD"、"类似任务 N"、"// 现有代码..." │
│ 你的角色：确认计划合理 │
│ │
│ ▼ │
│ │
│ 阶段 4：TDD 编码 │
│ ───────────────────────────────────── │
│ 触发技能：test-driven-development │
│ 做什么：先写测试(红)→运行确认失败→写实现(绿)→重构 │
│ ⚠️ 如果你先写了实现代码 → Superpowers 会删除代码，强制重新开始 │
│ 你的角色：审查实现结果 │
│ │
│ ▼ │
│ │
│ 阶段 5：子代理开发 │
│ ───────────────────────────────────── │
│ 触发技能：subagent-driven-development │
│ 做什么：将大任务拆成独立子任务，每个派发一个子代理并行执行 │
│ 两阶段审核：① 是否符合 SPEC → ② 代码质量审查 │
│ 你的角色：审核子代理输出 │
│ │
│ ▼ │
│ │
│ 阶段 6：代码审查 │
│ ───────────────────────────────────── │
│ 触发技能：requesting-code-review │
│ 做什么：AI 对照计划审查所有变更 │
│ 严重等级：CRITICAL → 必须修复 / HIGH → 应该修复 / MEDIUM → 考虑 │
│ 你的角色：决定是否合并 │
│ │
│ ▼ │
│ │
│ 阶段 7：收尾 │
│ ───────────────────────────────────── │
│ 触发技能：finishing-a-development-branch │
│ 做什么：运行验证→自动 Git 操作→选择合并/PR/保留/丢弃 │
│ 你的角色：确认收尾方式 │
│ │
└─────────────────────────────────────────────────────────────────────┘
1.5 使用建议
✅ 推荐使用的场景
| 场景 | 推荐度 | 说明 |
|---|---|---|
| 新功能开发 | ⭐⭐⭐⭐⭐ | Superpowers 的天菜——从 brainstorming 到 merge 全流程 |
| Bug 修复 | ⭐⭐⭐⭐ | 会自动进入 debugging 流程（跳过 brainstorming） |
| 重构 | ⭐⭐⭐⭐ | 强制 TDD 确保重构不破坏行为 |
| 大型多文件改动 | ⭐⭐⭐⭐⭐ | subagent-driven-development 并行执行效率最高 |
| 团队协作项目 | ⭐⭐⭐⭐⭐ | 保证所有人的代码质量一致 |
❌ 不推荐使用的场景
| 场景 | 原因 |
|---|---|
| 改一行配置 | 7阶段流程对微调来说太沉重 |
| 快速原型/实验 | 强制 TDD 拖慢探索速度 |
| 紧急修复 | 走完流程可能黄花菜都凉了 |
| 纯学习/探索 | Superpowers 是为"交付"设计的，不是为"学习"设计的 |
应该安装哪些技能？
必须安装（7个核心技能）：
using-superpowers + brainstorming + writing-plans + executing-plans
+ test-driven-development + requesting-code-review + finishing-a-development-branch
→ 构成完整开发流水线
按需安装（4个推荐技能）：
subagent-driven-development → 大型项目（任务并行）
systematic-debugging → 经常修 Bug
verification-before-completion → 质量要求高的项目
dispatching-parallel-agents → 极大型项目
可以不装（3个小众技能）：
receiving-code-review → 除非你经常给 AI 提审查意见
using-git-worktrees → 除非你经常并行开发多个分支
writing-skills → 除非你要自己写技能
第2章 agent-skills 使用手册
2.1 项目定位
agent-skills = 你的AI编码教科书
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
作者：Addy Osmani (Google AI 工程总监) Stars：~21K License: MIT
核心理念：
"技能编码了资深工程师的工作流、质量门和质量标准。"
→ 把 Google 内部工程文化打包成 20 个可执行的技能模块
工作方式：
手动 /command 调用（不是自动触发）
你主动调用 /spec → agent-skills 指导 AI 按资深工程师的方式工作
2.2 安装
# Claude Code（推荐）
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
# 也可以在 Claude Code 中输入：
我安装了 agent-skills，帮我激活它
跨平台安装（agent-skills 的独特优势）
# Cursor
cp -r skills/ .cursor/rules/
# Gemini CLI
gemini skills install https://github.com/addyosmani/agent-skills.git --path skills
# Windsurf / Copilot / Kiro / OpenCode
# 将 SKILL.md 内容作为规则配置
验证安装
在 Claude Code 中输入 /spec 或 /plan → 应该看到对应技能被激活
2.3 核心技能清单（20个）+ 完整参考
阶段1：定义 (Define) — 命令 /spec
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 1 | idea-refine | 把模糊想法变成具体的提案 | 不明确的需求、创业点子 | 输入: "我有一个想法..." |
| 2 | spec-driven-development | 写 PRD：目标/结构/风格/测试计划/边界条件 | 所有功能开发前 | 输入: "为新功能写 spec" |
阶段2：计划 (Plan) — 命令 /plan
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 3 | planning-and-task-breakdown | 将 SPEC 拆解为小型可验证任务，含验收标准和依赖排序 | 任何实施前 | 输入: "规划实现" |
阶段3：构建 (Build) — 命令 /build
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 4 | incremental-implementation | 薄垂直切片 + 功能标记 + 回滚能力 | 所有实施任务 | 开始编码时 |
| 5 | test-driven-development | 红-绿-重构 + 测试金字塔(80/15/5) | 核心逻辑 | 需要测试时 |
| 6 | context-engineering | 精确的上下文注入（规则文件 + MCP 集成） | 复杂项目上下文管理 | 上下文复杂 |
| 7 | source-driven-development | 所有决策基于官方文档，引用来源减少幻觉 | 新框架/新库集成 | 引入新技术时 |
| 8 | frontend-ui-engineering | 组件架构 + 设计系统 + 响应式 + WCAG 2.1 AA | 前端开发 | 写 UI 时 |
| 9 | api-and-interface-design | 契约优先 + Hyrum 法则 + 单版本规则 | API 设计 | 设计接口时 |
阶段4：验证 (Verify) — 命令 /test
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 10 | browser-testing-with-devtools | Chrome DevTools MCP 检查 DOM/控制台/网络/性能 | Web 项目 | 需要浏览器测试 |
| 11 | debugging-and-error-recovery | 5步骤：复现→定位→缩小→修复→防护 | Bug 修复 | 遇到错误时 |
阶段5：审查 (Review) — 命令 /review
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 12 | code-review-and-quality | 五轴审查 + 变更大小限制(~100行) + 严重级别标签 | 所有代码提交前 | 完成编码后 |
| 13 | code-simplification | Chesterton's Fence（先理解再简化）+ 500行规则 | 复杂代码简化 | 代码过于复杂时 |
| 14 | security-and-hardening | OWASP Top 10 + 密钥管理 + 依赖审计 + 三层边界防护 | 所有项目 | 安全审查时 |
| 15 | performance-optimization | 先测量后优化 + Core Web Vitals + 性能分析 | 性能优化 | 需要优化性能时 |
阶段6：发布 (Ship) — 命令 /ship
| # | 技能 | 用途 | 适合场景 | 触发条件 |
|---|---|---|---|---|
| 16 | git-workflow-and-versioning | Trunk-based + 原子提交 + 提交即保存点 | 版本管理 | 提交代码时 |
| 17 | ci-cd-and-automation | 左移 + 质量门流水线 + 功能标记 + 失败反馈 | CI/CD 设置 | 配置部署时 |
| 18 | deprecation-and-migration | 代码即负债 + 弃用策略 + 僵尸代码清除 | 旧代码清理 | 需要弃用功能时 |
| 19 | documentation-and-adrs | 架构决策记录 + API 文档 + 记录"为什么" | 需要文档时 | 代码完成后 |
| 20 | shipping-and-launch | 预发布检查清单 + 灰度发布 + 回滚流程 + 监控设置 | 上线发布 | 准备部署时 |
附加：3 个专家角色（在 agents/ 目录）
| 角色 | 视角 | 适合场景 |
|---|---|---|
| code-reviewer | 资深 Staff Engineer | 正式的代码审查 |
| test-engineer | QA 专家 | 测试策略评审 |
| security-auditor | 安全专家 | 安全审计 |
附加：4 份参考检查清单（在 references/ 目录）
| 清单 | 内容 | 加载方式 |
|---|---|---|
| testing-patterns.md | 测试模式与策略 | 按需（bash cat） |
| security-checklist.md | 安全检查清单 | 按需 |
| performance.md | 性能优化指南 | 按需 |
| accessibility.md | 无障碍标准 | 按需 |
2.4 每个技能的独有特色：反理性化表
这是 agent-skills 区别于其他项目的最大特色。每个技能都内置了"防 AI 偷懒机制"：
以 /review 中的 code-review-and-quality 为例：
技能内部的反理性化表
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 常见的借口 技能的预置反驳
────────────────── ──────────────────
"这只是个小改动，不用审查" "90%的生产事故来自'小改动'"
"测试回头再补" "回头=永远不会。现在补。"
"这个函数太复杂但能工作" "能工作≠应该合并。先简化。"
"我已经在脑子里审查过了" "代码审查是外显过程，不是内隐思考"
"改动超过100行了，因为..." "拆成多个PR。不可审查=不可合并。"
/spec 中的 spec-driven-development 的反理性化表：
"先写代码，spec 再补" "没有目标的代码重构成本是写spec的10倍"
"这个需求太简单不需要spec" "越简单的需求越容易被误解"
"用户不会那样用" "不要让AI假设用户行为。写下来验证。"
"先发版，有问题再修" "修复线上bug的成本是修复spec的100倍"
使用技巧：当你看到 AI 想要走捷径时，直接用 /review 或 /test 命令"唤醒"对应技能，反理性化表会自动约束 AI 行为。
2.5 使用建议
应该安装哪些技能？
第一阶段（新手必装，5个核心技能）：
spec-driven-development → 所有项目从 spec 开始
planning-and-task-breakdown → 先规划再动手
test-driven-development → 测试驱动
code-review-and-quality → 提交前审查
git-workflow-and-versioning → 规范版本管理
→ 这5个覆盖了最核心的开发生命周期
第二阶段（扩展安装，5个推荐技能）：
code-simplification → 代码简化
security-and-hardening → 安全审查
incremental-implementation → 增量开发
debugging-and-error-recovery→ 系统化调试
shipping-and-launch → 上线发布
第三阶段（按需安装，10个专业技能）：
browser-testing-with-devtools → Web 项目需要
frontend-ui-engineering → 前端项目需要
api-and-interface-design → API 项目需要
performance-optimization → 性能敏感项目
idea-refine → 产品需求不明确时
context-engineering → 复杂项目需要
source-driven-development → 引入新技术时
ci-cd-and-automation → 需要 CI/CD 时
documentation-and-adrs → 需要文档时
deprecation-and-migration → 需要弃用旧代码时
典型使用流程
📝 开发一个新功能：
Step 1: /spec 写一个清晰的 PRD
→ AI 引导你定义目标、范围、测试计划
→ 激活 idea-refine + spec-driven-development
Step 2: /plan 拆解任务
→ AI 将 spec 拆成可验证的子任务
→ 激活 planning-and-task-breakdown
Step 3: /build 开始编码
→ AI 用 TDD 方式增量实现
→ 激活 incremental-implementation + test-driven-development
Step 4: /verify 做完了？
→ AI 运行测试、做浏览器验证
→ 激活 browser-testing-with-devtools
Step 5: /review 审查代码
→ AI 做5轴审查 + 安全检查 + 性能检查
→ 激活 code-review-and-quality + security-and-hardening
Step 6: /ship 准备发布
→ AI 做预发布检查 + 版本管理 + 文档更新
→ 激活 git-workflow + ci-cd + shipping
✅ 推荐场景 vs ❌ 不推荐场景
| 场景 | 推荐度 | 原因 |
|---|---|---|
| 所有编码工作 | ⭐⭐⭐⭐⭐ | 不强制流程，但提供最佳实践参考 |
| 新手学习 | ⭐⭐⭐⭐⭐ | 每个技能都是"教科书"，边用边学 |
| 团队标准化 | ⭐⭐⭐⭐⭐ | 团队统一用同一套技能库 |
| 跨平台开发 | ⭐⭐⭐⭐⭐ | Claude/Cursor/Gemini 都能用 |
| 快速原型 | ⭐⭐⭐⭐ | 手动调用，想用哪个用哪个 |
| 紧急修复 | ⭐⭐⭐⭐ | 只调 /test + /review 即可 |
| 大型项目 | ⭐⭐⭐⭐ | 20个技能覆盖全生命周期 |
第3章 gstack 使用手册
3.1 项目定位
gstack = 你的AI虚拟团队
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
作者：Garry Tan (Y Combinator CEO) Stars：~55K License: MIT
核心理念：
"不要让一个 AI 做所有事。给它不同角色，每个角色专注于一件事。"
→ 25+ 个斜杠命令，每个对应一个团队成员角色
工作方式：
手动 /command 调用
你像 CEO 一样指挥："/office-hours 帮我想想这个功能值不值得做"
→ "/plan-eng-review 审查下架构"
→ "/qa 测试一下"
→ "/ship 发布"
3.2 安装
# 方法1：在 Claude Code 中直接说
Install GStack
# 方法2：手动克隆
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git \
~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup
# 方法3：项目级安装（项目专属配置）
mkdir -p .claude/skills
cp -r ~/.claude/skills/gstack .claude/skills/gstack
cd .claude/skills/gstack
./setup
安装配置（首次运行 /office-hours 时自动引导）
首次调用任意 gstack 命令时，会经历以下配置流程：
1. "Boil the Lake" 介绍 → 理解 gstack 的"完整性原则"
2. 遥测选择 → community / anonymous / off
3. 主动模式 → 是否允许 gstack 自动建议技能
4. 路由规则 → 自动在 CLAUDE.md 中添加技能路由配置
5. 版本检查 → 检测是否有旧版本需要更新
验证安装
在 Claude Code 中输入 / 查看所有可用命令
→ 应该看到 /office-hours /plan-ceo-review /qa /ship 等
3.3 完整命令清单（25+）
组1：产品与战略（做什么）
| 命令 | 对应角色 | 一句话功能 | 适合场景 |
|---|---|---|---|
/office-hours | 产品质疑者 | 6个强制问题来验证你的想法：用户是谁？为什么是现在？核心洞察？ | 🔥 每个项目的起点 |
/plan-ceo-review | CEO/产品负责人 | 战略视角审查：质疑范围、ROI 评估、MVP 成本核算 | 大功能启动前 |
/plan-eng-review | 工程经理 | 架构审查：数据流图、边界条件、测试矩阵、找出隐藏假设 | 技术方案设计 |
/plan-design-review | 设计负责人 | 设计系统审查：评分 0-10 分维度、识别"AI 味"设计 | 有 UI 改动时 |
/plan-devex-review | 开发者体验 | 开发者体验审查：API 设计、文档、上手难度 | 做开源/API 时 |
/autoplan | 编排器 | 依次自动运行 CEO → Engineering → DevEx 三重审查 | 快速评审 |
组2：设计与编码（怎么做）
| 命令 | 对应角色 | 一句话功能 | 适合场景 |
|---|---|---|---|
/design-consultation | 设计师 | 设计咨询：配色、布局、交互模式建议 | 界面设计 |
/design-shotgun | 设计师 | 快速多方案设计探索 | 需要多个备选 |
/design-html | 设计师 | 直接将设计转为 HTML/CSS | 前端实现 |
/review | 资深工程师 | 代码审查：安全、Bug、架构问题 | 任何代码提交前 |
/investigate | 调试专家 | 结构化根因分析：不找到根因不修复 | 棘手 Bug |
组3：测试与质量（确保做对了）
| 命令 | 对应角色 | 一句话功能 | 适合场景 |
|---|---|---|---|
/qa | QA 工程师 | ⭐ 打开真实浏览器→模拟点击→发现Bug→自动修复→生成回归测试 | 核心流程测试 |
/qa-only | QA 报告员 | 同上但只报告不修（不想让 AI 改代码时） | 外部 QA 审核 |
/cso | 安全负责人 | OWASP Top 10 + STRIDE 威胁建模 | 安全审计 |
/benchmark | 性能工程师 | Core Web Vitals + Bundle 大小对比 | 性能优化 |
/canary | SRE | 金丝雀发布检查：控制台错误、性能回归监控 | 灰度发布 |
组4：发布与运维（上线）
| 命令 | 对应角色 | 一句话功能 | 适合场景 |
|---|---|---|---|
/ship | 发布经理 | 版本管理 + 变更日志 + 发布自动化 | 准备发布 |
/land-and-deploy | DevOps | 合并 PR → 等 CI → 部署 → 验证生产健康 | 一键上线 |
/document-release | 技术写手 | 更新 README/ARCHITECTURE/CONTRIBUTING 与已发布代码同步 | 发版后 |
/setup-deploy | DevOps | 一次性部署配置（检测 Fly/Render/Vercel/Netlify/Heroku/GHA） | 项目初始化 |
/retro | 工程经理 | 周回顾：每人产出、连续发货记录、测试健康状况 | 每周一次 |
组5：工具与安全（跨阶段）
| 命令 | 对应角色 | 一句话功能 | 适合场景 |
|---|---|---|---|
/browse | UI 测试员 | 浏览器自动化：截图、点击、表单填写 | UI 验证 |
/codex | 第二意见 | OpenAI Codex CLI 做独立代码审查，跨模型对比 | 高安全需求 |
/pair-agent | 结对程序员 | 结对编程模式 | 复杂逻辑 |
/learn | 知识库 | 从会话中学习/记录知识 | 持续改进 |
/checkpoint | 版本控制 | 保存进度、设置检查点、恢复 | 长时间开发 |
/freeze | 范围锁定 | 限制文件编辑到一个目录，防止范围蔓延 | 调试/修复时 |
/guard | 全防护 | /careful + /freeze 的组合 | 高安全性需要 |
/careful | 安全守卫 | 危险操作前警告（rm -rf, DROP TABLE, force-push） | 任何项目 |
3.4 典型工作流
第一天：想清楚做什么
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. /office-hours → 验证产品方向（6个强制问题）
2. /plan-ceo-review → 战略层面审查
3. /plan-eng-review → 技术层面审查
4. /plan-design-review → 设计层面审查
编码日：动手做
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. 直接和 Claude 对话编码 / 用 /design-html 做前端
6. /review → 代码审查
7. /investigate → 如果遇到 Bug
测试日：确保质量
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. /qa → 浏览器端到端测试
9. /cso → 安全审计
10. /benchmark → 性能检查
发布日：上线
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11. /ship → 版本 + 变更日志
12. /land-and-deploy → 一键部署
13. /document-release → 更新文档
每周：复盘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
14. /retro → 周回顾
3.5 关键特色功能详解
/qa 浏览器测试（不依赖 MCP）
/qa 命令的完整执行流程：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 启动持久化 Chromium 实例
→ 编译好的原生二进制（非 MCP），Mac/Linux 原生支持
→ 延迟比 MCP 低 10 倍
2. 打开目标 URL
→ 保持 Cookies、Session、浏览器状态
3. 模拟用户操作流程
→ 点击、输入、滑动、表单提交
4. 验证和反馈
→ 截图证据 + Console 错误检查
→ 发现 Bug → 自动修复 → 生成回归测试
→ 没发现 → 报告测试通过
5. CAPTCHA 处理
→ 如果遇到验证码 → 切换到可见浏览器
→ 让你手动解决 → 解决后自动恢复
/codex 交叉验证
/codex 命令：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
同一份代码同时发给 Claude + Codex CLI
输出交叉对比报告：
┌────────────────────────────────────────────────────┐
│ │
│ 两家都发现的问题：🔴（最严重） │
│ - SQL 注入风险（Claude + Codex 都标记了） │
│ │
│ 只有 Claude 发现的问题：🟡 │
│ - 类型安全缺陷 │
│ │
│ 只有 Codex 发现的问题：🟡 │
│ - 内存泄漏风险 │
│ │
└────────────────────────────────────────────────────┘
3.6 使用建议
应该安装哪些命令？
必须安装（8个核心命令，覆盖完整周期）：
/office-hours → 产品验证（你不需要每次都做，但每阶段做一次）
/review → 代码审查（每次提交前）
/qa → 浏览器测试（Web 项目）
/ship → 发布管理（准备上线时）
/browse → 浏览器自动化（随时验证）
/investigate → Bug 调试（遇到 Bug 时）
/careful → 安全守卫（一直开启）
/freeze → 范围锁定（调试时）
按需安装（8个推荐命令）：
/plan-ceo-review → 大功能启动前
/plan-eng-review → 技术方案设计时
/plan-design-review → 有 UI 改动时
/cso → 安全审计时
/benchmark → 性能优化时
/land-and-deploy → 需要部署时
/document-release → 发布后
/retro → 每周一次
特定场景安装（8个专业命令）：
/design-consultation /design-shotgun /design-html → 设计师
/codex → 高安全项目需要两个模型交叉验证
/canary → 灰度发布
/learn → 持续学习的项目
/pair-agent → 复杂逻辑需要结对编程
/checkpoint → 长时间开发项目
/setup-deploy → 项目初始化
/autoplan → 需要快速三视角审查
✅ 推荐场景 vs ❌ 不推荐场景
| 场景 | 推荐度 | 原因 |
|---|---|---|
| 独立开发者做产品 | ⭐⭐⭐⭐⭐ | 一个人 = 一个团队，从 CEO 到 QA 全齐 |
| Web 全栈应用 | ⭐⭐⭐⭐⭐ | 浏览器测试 + 一键部署最强 |
| 从0到1 MVP | ⭐⭐⭐⭐⭐ | /office-hours 能帮你想清楚方向 |
| 快速迭代项目 | ⭐⭐⭐⭐⭐ | 角色分工明确，QA/发布一个命令搞定 |
| 团队协作 | ⭐⭐⭐⭐ | /retro 周复盘有用 |
| 非 Web 项目 | ⭐⭐⭐ | /qa /browse 对后端/嵌入式项目价值有限 |
| 纯学习/探索 | ⭐⭐ | gstack 是为"交付"设计的，不是学习 |
第二部分：组合使用指南
第4章 如何同时安装三件套
4.1 安装路径和顺序
三件套共存安装方案
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
步骤一：安装 Superpowers（强制流程层）
─────────────────────────────────────
/plugin install superpowers@claude-plugins-official
→ 安装到 Claude Code 的 plugin 系统
步骤二：安装 agent-skills（标准参考层）
─────────────────────────────────────
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
→ 安装到 Claude Code 的 plugin 系统
步骤三：安装 gstack（角色团队层）
─────────────────────────────────────
git clone --single-branch --depth 1 \
https://github.com/garrytan/gstack.git \
~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
→ 安装到 ~/.claude/skills/gstack/
三者的最终目录结构：
~/.claude/
├── skills/
│ └── gstack/ # gstack 技能
├── plugins/ # Superpowers + agent-skills 由 plugin 管理
│ ├── claude-plugins-official/
│ │ └── superpowers/ # Superpowers 技能
│ └── addy-agent-skills/
│ └── agent-skills/ # agent-skills 技能
4.2 安装后的配置（CLAUDE.md）
要让三者和睦共处，需要在项目根目录的 CLAUDE.md（或全局 ~/.claude/CLAUDE.md）中添加分工指引：
# 技能路由配置
## 三套技能的职责分工
### Superpowers（自动流程引擎）
负责所有需要强制流程的工作：需求澄清、功能规划、TDD、代码审查、分支管理。
- 自动触发：brainstorming → writing-plans → TDD → code-review → finishing-branch
- 开发者不需要手动干预，Superpowers 会自动判断何时进入哪个阶段
### agent-skills（质量标准库）
负责提供编码标准和最佳实践参考。
- 手动调用：/spec /plan /build /test /review /ship /code-simplify
- 当 Superpowers 进行到相应阶段时，可以引用 agent-skills 的标准
- 特别用于：安全审计、性能优化、代码简化
### gstack（角色团队）
负责需要特定角色视角的工作。
- 手动调用：/office-hours /plan-ceo-review /qa /ship /cso /browse /retro
- 用于：产品验证、浏览器测试、部署上线、安全审计、周复盘
## 技能冲突裁决
- 代码审查 → 先让 Superpowers 自动审查，再用 gstack 的 /review 或 /codex 做二次审查
- 规划 → Superpowers 的 writing-plans 拆解任务，gstack 的 /autoplan 做多视角评审
- 测试 → Superpowers 执行 TDD 单元测试，gstack 的 /qa 做浏览器端到端测试
4.3 Token 管理建议
三者同时加载可能有 Token 压力（Superpowers 约 15-25K + agent-skills 约 3-5K + gstack 约 10-15K）：
Token 预算管理策略
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
总预算：100K（Claude 上下文窗口）
─────────────────────────────────
日常编码 ██████████████████████████████████░░░░░░░░ 80K/100K
（三件套全部激活）
大型重构 ██████████████████████████████████████████ 接近满载
（需要保留足够空间给实际代码）
优化策略：
• 使用 /freeze（gstack）限制文件范围，减少无效上下文
• 不需要 gstack 时，在 CLAUDE.md 中注释掉对应路由
• 长时间会话中定期 /clear 重置
• gstack 建议启用 --prefix 模式（命令前加 /gstack- 前缀避免混淆）
第5章 三件套组合的职责分工模型
5.1 三层分工架构
业界社区对三者的共识是：它们互补而非竞争。最佳实践是按三个"职责层"来分工：
三层职责分工模型
┌─────────────────────────────────────────────────────────────┐
│ │
│ 决策层（WHAT + WHY） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ gstack 负责 │ │
│ │ │ │
│ │ /office-hours → 产品方向验证 │ │
│ │ /plan-ceo-review → 战略评审 │ │
│ │ /plan-eng-review → 架构评审 │ │
│ │ /plan-design-review → 设计评审 │ │
│ │ │ │
│ │ 核心产出：想清楚"做什么"和"为什么做" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 标准层（HOW + STANDARD） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ agent-skills 负责 │ │
│ │ │ │
│ │ /spec → 用 PRD 规范写清楚需求 │ │
│ │ /plan → 按 Google 标准拆任务 │ │
│ │ /build → 用 TDD/增量方式编码 │ │
│ │ /review → 5轴审查 + 安全 + 性能 │ │
│ │ │ │
│ │ 核心产出：资深工程师的"怎么做"标准流程 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 执行层（DO + CHECK） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Superpowers 负责 │ │
│ │ │ │
│ │ brainstorming → 自动触发，帮你澄清需求 │ │
│ │ writing-plans → 自动拆任务到文件级 │ │
│ │ TDD → 强制先写测试再写实现 │ │
│ │ subagent-dev → 并行执行子任务 │ │
│ │ finishing-branch → 验证+合并 │ │
│ │ │ │
│ │ 核心产出：强制走完标准流程，保证质量 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 🔑 一句话总结： │
│ gstack 想清楚 → agent-skills 教你怎么做 → Superpowers 盯着你做│
│ │
└─────────────────────────────────────────────────────────────┘
5.2 关键交接点
三件套之间有 5 个关键交接点：
交接点1：需求阶段 → 定义阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
gstack agent-skills
────── ───────────
/office-hours → 验证产品方向
/plan-ceo-review → 战略评审 /spec → 写正式 PRD
/plan-eng-review → 架构评审 /plan → 拆任务
交接：产品方向确认后，交给 agent-skills 写正式 spec
🔑 什么时候用 gstack 就够了？
→ 小功能、个人项目
🔑 什么时候需要完整流程？
→ 大功能、团队项目
交接点2：定义阶段 → 执行阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
agent-skills Superpowers
─────────── ───────────
/spec 完成 writing-plans 读取 spec
/plan 完成 TDD 开始执行
交接：spec 定稿后，Superpowers 自动接管执行
🔑 注意：
Superpowers 的 brainstorming 可能和 /spec 有重叠
→ 可以让 Superpowers 做 brainstorming，再手动用 /spec 写正式文档
→ 或者直接跳到 /spec，避免重复
交接点3：编码阶段（测试分工）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Superpowers gstack
─────────── ──────
TDD：单元测试 /qa：端到端浏览器测试
集成测试 /browse：可视化验证
性能测试
分工：
● Superpowers 确保"代码是对的"
● gstack 确保"产品运行是对的"
交接点4：审查阶段（多层审查）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Superpowers → agent-skills → gstack
────────── ─────────── ──────
一级审查 二级审查 三级审查
自动审查 标准审查 角色审查
(基本检查) (5轴+安全+性能) (/codex 交叉验证)
推荐流程：
1. Superpowers 自动做一版审查
2. 手动调用 agent-skills 的 /review 做标准审查
3. 高安全项目再调 gstack 的 /codex 做跨模型验证
交接点5：发布阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Superpowers → gstack
────────── ──────
finishing- /ship → 版本+变更日志
branch /land-and-deploy → CI/CD+部署
(验证+合并) /document-release → 文档更新
第6章 分场景的推荐使用流程
场景1：个人开发者做自己的产品
最适合的配置：gstack（主要）+ agent-skills（辅助）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原因：个人开发者最需要的是"想清楚做什么"和"快速发布"
Superpowers 的强制流程对个人来说可能太重
Day 1：想清楚
┌─────────────────────────────────────────────────────────────┐
│ /office-hours → 验证你的产品想法（6个强制问题） │
│ /plan-ceo-review → 战略评审确认方向 │
└─────────────────────────────────────────────────────────────┘
Day 2-5：动手做
┌─────────────────────────────────────────────────────────────┐
│ /spec → agent-skills 写 PRD │
│ /plan → agent-skills 拆任务 │
│ 自由编码 → 直接和 Claude 对话写代码 │
│ /review (gstack) → 代码审查 │
│ /qa → 浏览器测试 │
└─────────────────────────────────────────────────────────────┘
Day 6：发布
┌─────────────────────────────────────────────────────────────┐
│ /cso → 安全审计 │
│ /ship → 版本+变更日志 │
│ /land-and-deploy → 部署上线 │
└─────────────────────────────────────────────────────────────┘
用到的命令：/office-hours /plan-ceo-review /spec /plan /review /qa /cso /ship /deploy
≈ 9 个命令，覆盖全流程
场景2：团队日常功能开发（质量优先）
最适合的配置：Superpowers（主要）+ agent-skills（标准参考）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原因：团队最需要的是"每个人的代码质量一致"
Superpowers 的强制流程 + agent-skills 的标准化 = 黄金组合
阶段1：需求
┌─────────────────────────────────────────────────────────────┐
│ Superpowers brainstorming 自动触发 │
│ → AI 追问你需求细节 │
│ → 生成 SPEC 文档 │
└─────────────────────────────────────────────────────────────┘
阶段2：规划
┌─────────────────────────────────────────────────────────────┐
│ Superpowers writing-plans 自动触发 │
│ → 拆解任务到文件级 │
│ → 你可以引用 agent-skills 的 /plan 做交叉参考 │
└─────────────────────────────────────────────────────────────┘
阶段3：编码
┌─────────────────────────────────────────────────────────────┐
│ Superpowers TDD 强制触发 │
│ → 先写测试 → 确认失败 → 写实现 → 重构 │
│ → 可以用 agent-skills 的 /build 作为参考 │
└─────────────────────────────────────────────────────────────┘
阶段4：审查
┌─────────────────────────────────────────────────────────────┐
│ Superpowers 自动审查 │
│ → 你可以再手动调 agent-skills /review 做二次审查 │
│ → 检查安全 + 性能 + 代码简化 │
└─────────────────────────────────────────────────────────────┘
阶段5：合并
┌─────────────────────────────────────────────────────────────┐
│ Superpowers finishing-branch 自动触发 │
│ → 验证 → 合并 │
└─────────────────────────────────────────────────────────────┘
用到的工具：Superpowers 自动流程 ≈ agent-skills 的 /review 按需
≈ Superpowers 做 80% 的工作，agent-skills 补 20%
场景3：完整三件套（全栈 + 高安全要求）
最适合的配置：全部安装，按阶段分工
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原因：需要从产品验证、到工程标准、到强制执行的完整闭环
Phase 1：产品验证（gstack 主导）
┌─────────────────────────────────────────────────────────────┐
│ 输入：我有一个想法... │
│ │
│ /office-hours → 6 个强制问题验证需求 │
│ /plan-ceo-review → 战略层面 ROI 评估 │
│ /plan-eng-review → 技术可行性评估 │
│ /plan-design-review → 设计可行性评估 │
│ │
│ 产出：通过验证的产品方向 + 技术方案 │
└─────────────────────────────────────────────────────────────┘
Phase 2：正式定义（agent-skills 主导）
┌─────────────────────────────────────────────────────────────┐
│ 输入：已确认的产品方向 │
│ │
│ /spec → 写 PRD（目标、范围、验收标准） │
│ /plan → 拆任务（依赖排序、验收条件） │
│ │
│ 产出：清晰的 PRD + 可执行的任务列表 │
└─────────────────────────────────────────────────────────────┘
Phase 3：开发执行（Superpowers 主导）
┌─────────────────────────────────────────────────────────────┐
│ 输入：任务列表 │
│ │
│ brainstorming → writing-plans → TDD → subagent-dev │
│ （自动触发，按 Superpowers 标准流程走） │
│ │
│ 产出：通过测试的代码 │
└─────────────────────────────────────────────────────────────┘
Phase 4：质量验证（混合）
┌─────────────────────────────────────────────────────────────┐
│ 输入：已实现的代码 │
│ │
│ Superpowers 自动审查（基础检查） │
│ agent-skills /review（5轴+安全+性能） │
│ gstack /qa（浏览器端到端测试） │
│ gstack /cso（安全审计） │
│ gstack /benchmark（性能基准） │
│ gstack /codex（跨模型交叉验证） │
│ │
│ 产出：经过多层验证的可靠代码 │
└─────────────────────────────────────────────────────────────┘
Phase 5：发布（gstack 主导）
┌─────────────────────────────────────────────────────────────┐
│ 输入：验证通过的代码 │
│ │
│ Superpowers finishing-branch → 验证+合并到主分支 │
│ gstack /ship → 版本管理+变更日志 │
│ gstack /land-and-deploy → CI/CD + 部署上线 │
│ gstack /document-release → 文档更新 │
│ │
│ 产出：上线运行的产品 │
└─────────────────────────────────────────────────────────────┘
Phase 6：复盘（gstack 主导）
┌─────────────────────────────────────────────────────────────┐
│ 输入：已发布的产品 │
│ │
│ gstack /retro → 周复盘：每人产出、测试健康、发布统计 │
│ │
│ 产出：下一轮的改进方向 │
└─────────────────────────────────────────────────────────────┘
场景4：快速修复 / 小改动
最适合的配置：gstack 的 /investigate + /review（最轻量）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原因：小改动不需要三件套全上，轻量组合就够了
┌─────────────────────────────────────────────────────────────┐
│ 遇到 Bug： │
│ /investigate → 系统化根因分析 │
│ 修复 → /review → 提交 │
│ │
│ 改配置/修文案： │
│ 直接改 → 提交（不需要任何 skill） │
│ │
│ 小功能（1-2 文件）： │
│ agent-skills /build → 增量实现 │
│ agent-skills /review → 快速审查 │
│ 提交 │
└─────────────────────────────────────────────────────────────┘
第7章 实战案例：完整项目开发流程
案例：用三件套从头开发一个 Web 应用
项目：一个开源的 Markdown 笔记应用
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Day 1：产品验证
──────────────────────────────────────────────────────
你：我想做一个开源的 Markdown 笔记应用，支持本地优先+Git同步
┌→ gstack /office-hours
│ AI 提问（6 个强制问题）：
│ Q1: 用户是谁？→ 开发者和写作者
│ Q2: 解决了什么问题？→ 不想被 Notion/Obsidian 锁定
│ Q3: 为什么是现在？→ Obsidian 闭源趋势明显
│ Q4: 核心洞察？→ 用户想要"Markdown 文件的所有权"
│ Q5: 最小可行产品是什么？→ 本地编辑器+基本的 Git 同步
│ Q6: 怎么知道做对了？→ 用户愿意把笔记迁移进来
│
└→ 你确认方向 → 进入下一阶段
┌→ gstack /plan-eng-review
│ AI 审查技术方案：
│ → 建议：前端用 React + TipTap（Markdown WYSIWYG）
│ → 建议：后端用 Node.js + isomorphic-git（纯 JS Git 实现）
│ → 建议：存储用本地文件系统（不是数据库）
│ → 潜在风险：Git 冲突处理、大文件性能
│
└→ 你同意技术选型 → 进入下一阶段
Day 2：需求定义
──────────────────────────────────────────────────────
┌→ agent-skills /spec
│ AI 生成 PRD：
│ → 目标：构建一个本地优先的 Markdown 笔记应用
│ → 范围：编辑器、文件管理、Git 同步、搜索
│ → 不在范围内：协作编辑、移动端
│ → 技术栈：React + TipTap + isomorphic-git
│ → 测试策略：单元测试(80%) + 集成测试(15%) + E2E(5%)
│ → 边界条件：大文件(>10MB)、特殊字符编码、Git 冲突
│
└→ 你逐段审批 → 确认 spec
┌→ agent-skills /plan
│ AI 拆解任务：
│ Task 1: 项目脚手架（Vite + React + TypeScript）
│ Task 2: 文件系统抽象层（读写 Markdown 文件）
│ Task 3: 编辑器组件（TipTap 集成 + Markdown 渲染）
│ Task 4: 文件树组件（目录浏览 + 文件管理）
│ Task 5: Git 同步模块（init/commit/push/pull）
│ Task 6: 搜索功能（全文搜索）
│ Task 7: 预览模式（Markdown 渲染）
│
└→ 你确认任务拆分
Day 3-7：开发执行
──────────────────────────────────────────────────────
你不用说话，Superpowers 自动接管：
Phase 1: Brainstorming（自动触发）
AI 确认你对每个任务的理解
→ 你确认
Phase 2: Writing Plans（自动触发）
AI 将每个任务拆解到文件级：
Task 1 → src/App.tsx, src/main.tsx, vite.config.ts, package.json
Task 2 → src/lib/file-system.ts, src/types.ts
Task 3 → src/components/Editor.tsx, src/lib/markdown.ts
...
Phase 3: TDD（自动触发，每个任务）
Task 1:
→ AI 先写测试（vite.config.test.ts 测试构建）
→ 运行测试（确认失败）
→ 写实现（配置 Vite + React）
→ 运行测试（通过）
→ 重构
Task 2:
→ AI 先写测试（测试文件读写、目录遍历）
→ ...
Phase 4: Subagent Development（自动触发）
Task 3 和 Task 4 独立 → 两个子代理并行
→ 各自完成 → 各自审查 → 合并
Phase 5：审查
──────────────────────────────────────────────────────
Superpowers 自动审查：
→ 基本检查：代码风格、命名规范、类型安全
你手动调用加强审查：
┌→ agent-skills /review
│ 5轴审查：
│ → 架构：组件拆分是否合理？（编辑器组件应该更薄）
│ → 安全：文件系统路径是否有注入风险？（需要加 sanitize）
│ → 性能：大文件渲染是否有卡顿？（需要虚拟滚动）
│ → 测试：覆盖率达到 80%？（当前 72%，需要补测试）
│ → 可维护性：代码复杂度是否OK？（一个函数超过50行）
│
└→ 修复发现的问题
┌→ agent-skills /code-simplify
│ → 检测到 file-system.ts 中有一个函数太复杂
│ → 拆分为 3 个小函数
│
└→ 代码更简洁
┌→ gstack /qa
│ → 启动浏览器
│ → 测试：新建笔记 ✓ / 编辑 Markdown ✓ / Git 同步 ✓ /
│ 搜索 🔴 搜索有 Bug（输入中文不触发）→ 自动修复
│ → 测试报告：4/5 通过，1 个 Bug 已修复
│
└→ 产品验证通过
┌→ gstack /cso
│ → OWASP Top 10 审计
│ → 发现：文件路径遍历风险（使用相对路径时）
│ → 建议：使用 path.resolve + 路径前缀校验
│
└→ 修复安全问题
Phase 6：发布
──────────────────────────────────────────────────────
Superpowers finishing-branch：
→ 验证所有测试通过
→ 合并到 main 分支
┌→ gstack /ship
│ → 版本号：v0.1.0
│ → 生成 CHANGELOG.md
│ → 自动打 Git tag
│
└→ 准备好发布的包
┌→ gstack /document-release
│ → 更新 README.md（安装说明、使用指南）
│ → 更新 ARCHITECTURE.md（架构文档）
│ → 更新 CONTRIBUTING.md（贡献指南）
│
└→ 文档就绪
┌→ gstack /land-and-deploy
│ → 推送到 GitHub
│ → CI/CD（GitHub Actions）自动构建
│ → 部署到 GitHub Pages
│
└→ 产品上线 🎉
Weekly：复盘
──────────────────────────────────────────────────────
┌→ gstack /retro
│ → 本周产出分析
│ → 代码质量趋势
│ → 测试覆盖率报告
│ → 下周期改进点
│
└→ 持续改进
附录：快速参考卡
日常开发速查
新手推荐 → agent-skills（最简单，不强制）
个体户推荐 → gstack（角色全，从0到1）
团队推荐 → Superpowers + agent-skills（质量保障）
全能推荐 → 三件套全上（按阶段分工）
何时用什么
想验证想法 → gstack /office-hours
想写清楚需求 → agent-skills /spec
想拆任务 → agent-skills /plan 或 Superpowers writing-plans
想开始编码 → 让 Superpowers TDD 自动进行
想查 Bug → gstack /investigate
想测浏览器 → gstack /qa
想做安全审计 → gstack /cso 或 agent-skills security-and-hardening
想审查代码 → Superpowers 自动 + agent-skills /review
想部署上线 → gstack /ship + /land-and-deploy
想做周复盘 → gstack /retro
三件套选择决策树
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 你想做到什么？ │
│ │
│ ├── 快速验证一个想法 → gstack /office-hours │
│ │ │
│ ├── 从0到1做产品 → gstack（主力）+ agent-skills（辅助） │
│ │ │
│ ├── 保证代码质量 → Superpowers（自动流程）+ agent-skills（标准） │
│ │ │
│ ├── 团队标准化 → agent-skills（定义标准）+ Superpowers（执行） │
│ │ │
│ ├── 全栈+高安全 → 三件套全上（见第7章案例） │
│ │ │
│ └── 只是小改动 → 什么都不用装，直接改 │
│ │
└─────────────────────────────────────────────────────────────────────┘
编写说明：本文档基于 2026 年 4 月三个项目的最新版本编写。由于项目迭代速度很快，建议定期检查官方仓库获取最新信息。
参考链接：
- Superpowers - obra/superpowers
- agent-skills - addyosmani/agent-skills
- gstack - garrytan/gstack
- Claude Code Skills 规范 | SKILL.md Format