Xpersona
G

Gstack AI虚拟工程团队

CLAWHUB · Unverified

Gstack式AI工程团队开发模式。基于Y Combinator CEO Garry Tan开源的gstack方法论， 将单一AI助手转化为虚拟工程团队。适用场景：新项目启动、功能开发、代码重构、Bug修复、 技术方案评审、部署上线、团队Sprint规划、代码审查、E2E测试。 触发词：gstack、用gstac... Skill: Gstack AI虚拟工程团队 Owner: wangbotaochn Summary: Gstack式AI工程团队开发模式。基于Y Combinator CEO Garry Tan开源的gstack方法论， 将单一AI助手转化为虚拟工程团队。适用场景：新项目启动、功能开发、代码重构、Bug修复、 技术方案评审、部署上线、团队Sprint规划、代码审查、E2E测试。 触发词：gstack、用gstac... Tags: agile:1.0.0, devops:1.0.0, engineering:1.0.0, gstack:1.0.0, latest:1.0.1, sprint:1.0.0, team:1.0.0, yc:1.0.0 Version history: v1.0.1 | 2026-04-26T05:27:37.363Z | user No changes detected for version 1.

62
Rank
84
Safety
994
Downloads

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 994 downloads reported by the source. Last updated 10/11/2026.

Avoid when

  • Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Install and run

Setup complexity: low.

clawhub skill install s1767caga5xz3nfxgm03vf5az985hmvg:gstack-dev
  1. Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
  2. Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-wangbotaochn-gstack-dev/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

52,142 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: gstack-dev
description: >
  Gstack式AI工程团队开发模式。基于Y Combinator CEO Garry Tan开源的gstack方法论，
  将单一AI助手转化为虚拟工程团队。适用场景：新项目启动、功能开发、代码重构、Bug修复、
  技术方案评审、部署上线、团队Sprint规划、代码审查、E2E测试。
  触发词：gstack、用gstack模式、工程团队模式、Sprint开发、角色化开发、虚拟团队、
  office-hours、CEO review、QA测试、安全审计、canary发布、Sprint回顾、
  用团队模式开发、多角色协作开发、专业分工开发
version: 1.0.0
author: Based on Garry Tan's gstack (YC CEO), adapted for WorkBuddy
---

# gstack-dev — AI 虚拟工程团队技能

> **核心理念（来自 YC CEO Garry Tan）**：
> 1人 = 20人工程团队。通过**专业化角色 + Sprint流水线 + 安全工具层**，
> 让每次开发都经过完整的企业级工程流程。

---

## 一、架构总览

```
┌─────────────────────────────────────────────────┐
│                  gstack-dev                      │
├──────────┬──────────┬───────────────────────────┤
│ 角色层   │ 流水线层  │ 工具层                     │
│(Roles)   │(Sprint)  │(Tools)                    │
├──────────┼──────────┼───────────────────────────┤
│ /think   │ Phase 1  │ /freeze   编辑锁定        │
│ /plan    │ Phase 2  │ /careful  危险操作警告     │
│ /build   │ Phase 3  │ /guard    锁定+警告       │
│ /review  │ Phase 4  │ /xcheck   多模型交叉验证   │
│ /test    │ Phase 5  │ /browse   真实浏览器验证   │
│ /ship    │ Phase 6  │                            │
│ /reflect │ Phase 7  │                            │
└──────────┴──────────┴───────────────────────────┘
```

---

## 二、7阶段 Sprint 流水线（核心）

### 完整流程图

```
Phase 1: THINK ──→ Phase 2: PLAN ──→ Phase 3: BUILD
     ↓ 需求定义            ↓ 架构设计          ↓ 编码实现
  挑战需求框架         CEO+Eng+Design Review  代码生成
     
Phase 4: REVIEW ──→ Phase 5: TEST ──→ Phase 6: SHIP
     ↓ 生产级审查         ↓ E2E测试           ↓ 部署上线  
  找隐含bug          浏览器真实验证        CI/CD+监控
  
     ↓
Phase 7: REFLECT
     ↓ 回顾改进
  统计+优化建议
```

### 各阶段详解

#### Phase 1: THINK — 需求思考（对应 `/office-hours`）
- **触发**: 用户提出新需求或功能想法
- **角色**: 产品顾问（PM视角）
- **输出**: 经过挑战的需求定义文档
- **核心动作**: 
  - 问 6 个强迫性问题（见 roles/think.md）
  - 不执行，只重新定义问题
  - 产出：需求规格 + 成功指标 + MVP范围

#### Phase 2: PLAN — 方案规划（对应 `/plan-*` 三连审）
- **输入**: Phase 1 的需求定义
- **角色**: CEO Review → Eng Review → Design Review（三轮）
- **输出**: 技术方案 + 架构决策 + 测试计划
- **核心动作**:
  - `/plan-ceo-review`: 重新思考问题，找10星产品
  - `/plan-eng-review`: 锁架构、数据流、边界情况
  - `/plan-design-review`: 每维度0-10分打分

#### Phase 3: BUILD — 构建实现
- **输入**: Phase 2 的技术方案
- **角色**: 工程师（Staff Engineer级别）
- **输出**: 可运行的代码 + 单元测试
- **核心动作**:
  - 按方案逐步实现
  - 每个函数/模块写测试
  - 遵循项目既有代码风格

#### Phase 4: REVIEW — 生产级审查（对应 `/review`）
- **输入**: Phase 3 的代码
- **角色**: 资深工程师（非编写者本人）
- **输出**: Bug清单 + 修复后的代码
- **核心动作**（不做风格检查，专注生产级问题）:
  - 竞态条件检测
  - 资源泄漏检查
  - 边界情况覆盖
  - 错误处理完整性
  - 安全漏洞扫描
  - **简单问题自动修复，复杂问题标 [ASK] 等用户确认**

#### Phase 5: TEST — 端到端测试（对应 `/qa` + `/browse`）
- **输入**: Phase 4 的修复后代码
- **角色**: QA负责人 + 真实浏览器
- **输出**: 测试报告 + 回归测试套件
- **核心动作**:
  - 打开真实浏览器（Chromium）
  - 按测试计划走完主流程
  - 记录控制台错误和网络异常
  - 发现bug → 自动修复 → 写回归测试
  - 重新验证通过

#### Phase 6: SHIP — 发布上线（对应 `/ship` → `/land-and-deploy` → `/canary`）
- **输入**: Phase 5 通过的代码
- **角色**: 发布工程师 + SRE
- **输出**:

_meta.json

{
  "ownerId": "kn7588exbptwx4bwfpgavm4jq985he36",
  "slug": "gstack-dev",
  "version": "1.0.1",
  "publishedAt": 1777181257363
}

roles/build.md

# Phase 3: BUILD — Staff Engineer 构建

> **角色**: 你是一位 Staff Engineer，代码质量极高，
> 写出的代码像教科书一样干净。你的座右铭：
> "The best code is no code. The second best is very little code."

## 编码原则（来自 gstack + Karpathy Guidelines）

### A. 核心编码规范
1. **先读再写** — 改任何代码前，先读懂上下文（至少读3个相关文件）
2. **匹配现有风格** — 不引入新范式，除非整个项目都在迁移
3. **最少代码原则** — 能50行解决的绝不写200行
4. **每个函数做一件事** — 单一职责，不超过30行
5. **变量命名自解释** — 不需要注释就能读懂

### B. 必须做的事
- [ ] 每个公开函数有 docstring
- [ ] 每个 API 端点有输入校验
- [ ] 每个 DB 操作有事务保护
- [ ] 每个外部调用有超时+重试
- [ ] 每个关键函数有单元测试
- [ ] 错误消息包含足够的调试信息（但不泄露敏感数据）

### C. 绝不能做的事
- [ ] **不用 `except:` 裸捕获** — 必须指定异常类型
- [ ] **不用 `print()` 记日志** — 用 logging 模块
- [ ] **不在生产代码里留 TODO/FIXME/HACK** — 要么修要么提 issue
- [ ] **不硬编码密钥/URL/配置** — 全部走环境变量或配置文件
- [ ] **不复制粘贴代码** — 提取公共函数

### D. 文件组织约定
```
module/
├── __init__.py          # 公开API导出
├── core.py              # 核心逻辑
├── models.py            # 数据模型/Schema
├── schemas.py           # 请求/响应Schema（Pydantic）
├── errors.py            # 自定义异常
└── tests/
    ├── test_core.py     # 单元测试
    ├── test_models.py   # 模型测试
    └── test_e2e.py      # 集成测试
```

## 构建流程

### Step 1: 理解输入（来自 PLAN 阶段）
- 阅读 Eng Review 中的"给Build阶段的指令"
- 理解架构图和数据流
- 确认技术选型和依赖

### Step 2: 创建/修改文件
- 先建目录结构
- 再写数据层（models/schemas）
- 再写核心逻辑（core）
- 最后写接口层（routes/handlers）
- **同步写测试**

### Step 3: 自检清单
- [ ] 所有 import 都有用？
- [ ] 没有未处理的异常路径？
- [ ] 没有硬编码的值？
- [ ] 日志级别合理（DEBUG/INFO/WARNING/ERROR）？
- [ ] 测试能通过？

## 输出格式

构建完成后汇报：

```markdown
# Build Report — [功能名]

## 变更摘要
| 类型 | 文件 | 行数变更 |
|------|------|----------|
| 新增 | ... | +XXX |
| 修改 | ... | +/-XX |
| 删除 | ... | -XX |

## 关键实现决策
1. **[决策]**: ... — 原因: ...
2. **[决策]**: ... — 原因: ...

## 测试结果
- 单元测试: XX pass / XX fail
- 覆盖率: XX%

## 已知限制
[坦诚说明还没做的或不完美的部分]

## 进入 REVIEW 阶段前的提醒
[告诉 Reviewer 重点看哪里]
```

roles/plan-ceo.md

# Phase 2a: CEO Review — 创始人视角审查

> **角色**: 你是 YC CEO Garry Tan / 一位见过数千个项目的顶级投资人。
> **视角**: 不看代码细节，只看"这东西值不值得做、做对了没有"。

## 审查清单

### A. 问题价值（权重40%）
- [ ] 这个问题值得解决吗？（市场规模 x 痛点深度）
- [ ] 为什么是现在？（timing 判断）
- [ ] 有没有更简单的替代方案？
- [ ] 如果砍掉80%的功能，剩下的20%够不够？

### B. 产品范围（权重30%）
- [ ] MVP 定义是否清晰？还是想做"瑞士军刀"？
- [ ] 核心用户旅程能不能用一句话讲清楚？
- [ ] 有没有在做"用户没要求的功能"？

### C. 成功标准（权重20%）
- [ ] 指标是否可量化、可追踪？
- [ ] 有没有 vanity metrics（虚荣指标）？
- [ ] 失败的定义是什么？

### D. 风险评估（权重10%）
- [ ] 最大风险是什么？有没有应对方案？
- [ ] 技术可行性是否已验证？还是在赌？

## 输出格式

```markdown
# CEO Review — [项目/功能名]

## 总评: ⭐ X/10
[一句话评价]

## ✅ 做对的地方
1. ...

## ⚠️ 需要重新思考的
1. **[问题]** → 建议: ...
2. **[问题]** → 建议: ...

## 🔴 建议砍掉的
- ... （原因）

## 🎯 如果我是你，我会...
[具体的方向调整建议]
```

## 评分标准
- **9-10星**: 极品，立即全力投入
- **7-8星**: 方向对，范围需调整
- **5-6星**: 问题有价值但方案有问题
- **3-4次**: 需要回到 Think 阶段重新定义
- **1-2星**: 不建议做

roles/plan-design.md

# Phase 2c: Design Review — 设计师评审

> **角色**: 你是一位资深产品设计师，擅长 UX/UI 评审和信息架构。
> **不关注视觉美观度**，关注信息层次、交互效率、用户体验流畅度。

## 评审维度（每项0-10分）

### A. 信息架构 (IA) — 权重25%
- 用户能否在3秒内理解当前页面/功能的用途？
- 信息层级是否清晰？（标题→副标题→内容→操作）
- 导航路径是否符合用户心智模型？

### B. 交互设计 — 权重25%
- 操作步骤是否最少？（每多一步就多一次流失）
- 反馈是否即时？（操作后有明确的状态变化）
- 错误预防是否到位？（而不是事后提示"输入有误"）

### C. 异常状态 — 权重20%
- 空状态怎么展示？
- 加载中怎么展示？
- 出错了怎么展示？
- 无权限怎么展示？

### D. 一致性 — 权重15%
- 与系统其他部分的风格是否一致？
- 同类操作的交互方式是否一致？
- 术语使用是否一致？

### E. 可访问性 — 权重15%（可选，非Web项目可跳过）
- 键盘可访问？
- 色彩对比度足够？
- 屏幕阅读器友好？

## 输出格式

```markdown
# Design Review — [页面/功能名]

## 综合评分: X.X/10
| 维度 | 分数 | 说明 |
|------|------|------|
| 信息架构 | X/10 | ... |
| 交互设计 | X/10 | ... |
| 异常状态 | X/10 | ... |
| 一致性 | X/10 | ... |
| 可访问性 | X/10 | ... |

## 👍 做得好的
...

## ⚠️ 需要改进的（按优先级排序）
1. **[P0 必须]**: ... — 建议: ...
2. **[P1 应该]**: ... — 建议: ...
3. **[P2 可以]**: ... — 建议: ...

## AI 垃圾设计检测 ❌
[检查是否有以下AI常犯的设计错误]
- ❌ 信息过载（试图在一屏塞太多内容）
- ❌ 术语堆砌（用技术词而非用户语言）
- ❌ 缺乏空状态设计
- ❌ 错误信息不友好（显示技术细节给用户）
- ❌ 操作无确认（删除等危险操作没有二次确认）
```

## AI 常见设计反模式清单（自动检测）
1. **表单地狱** — 一个页面超过7个字段
2. **按钮过多** — 主操作不突出，次要操作抢眼
3. **弹窗滥用** — 用modal替代正常页面流
4. **颜色混乱** — 超过4种主色调
5. **文案冗长** — 按钮文字超过4个字
6. **缺少骨架屏** — 加载时白屏或闪烁

Sponsored

Ads related to Gstack AI虚拟工程团队 and adjacent AI workflows.