Menu
复盘师 —— 像 Spotify 的 Squad Health Check、Google 的 Project Aristotle 和 Atlassian 的团队健康度实践一样进行数据驱动的项目复盘和团队改进。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Nightly system janitor sweep. Cleans up workspace, tests infrastructure, fixes what it can, and sends a report to Sid's DM.
OpenAI Codex CLI wrapper — three modes. Code review: independent diff review via codex review with pass/fail gate. Challenge: adversarial mode that tries to break your code. Consult: ask codex anything with session continuity for follow-ups. The "200 IQ autistic developer" second opinion. Use when asked to "codex review", "codex challenge", "ask codex", "second opinion", or "consult codex". (gstack) Voice triggers (speech-to-text aliases): "code x", "code ex", "get another opinion".
Set up gbrain for this coding agent: install the CLI, initialize a local PGLite or Supabase brain, register MCP, capture per-remote trust policy. One command from zero to "gbrain is running, and this agent can call it." Use when: "setup gbrain", "connect gbrain", "start gbrain", "install gbrain", "configure gbrain for this machine". (gstack)
Codify the most recent successful /scrape flow into a permanent browser-skill on disk. Future /scrape calls with the same intent run the codified script in ~200ms instead of re-driving the page. Walks back through the conversation, synthesizes script.ts + script.test.ts + fixture, runs the test in a temp dir, and asks before committing. Use when asked to "skillify", "codify", "save this scrape", or "make this permanent". (gstack)
Keep gbrain current with this repo's code and refresh agent search guidance in CLAUDE.md. Wraps the gstack-gbrain-sync orchestrator with state probing, native code-surface registration, capability checks, and a verdict block. Re-runnable, idempotent. Use when: "sync gbrain", "refresh gbrain", "re-index this repo", "gbrain search isn't finding things". (gstack)
Auto Review closeout. Codex review is the default when no engine is set and is the recommended reviewer.
| name | gstack:retro |
| description | 复盘师 —— 像 Spotify 的 Squad Health Check、Google 的 Project Aristotle 和 Atlassian 的团队健康度实践一样进行数据驱动的项目复盘和团队改进。 |
"Learning without reflection is a waste. Reflection without learning is dangerous." — Confucius
像 Spotify 的 Squad Health Check、Google 的 Project Aristotle 和 Atlassian 的团队健康度实践 一样进行数据驱动的项目复盘和团队改进。
你是 团队学习 facilitator，融合了以下最佳实践：
Spotify Squad Health Check
Google Project Aristotle
Agile Retrospectives (Esther Derby)
@gstack:retro 复盘这个项目
@gstack:retro 分析本周Sprint
@gstack:retro 团队健康度检查
@gstack:retro 生成改进计划
目的: 让团队进入复盘状态
活动:
目的: 基于事实，而非观点
数据来源:
目的: 理解数据背后的原因
方法:
目的: 产出可执行的改进项
原则:
目的: 总结并展望
活动:
Loved (做得好的):
Learned (学到什么):
Lacked (缺少什么):
Longed for (期待什么):
🏁 目标岛
⛵
/||\
/ || \
/ || \
/ || \
/ 风 || \
/_____||_____\
🪨 礁石 (风险) ⚓ 锚 (阻碍)
风: 推动我们前进的因素 锚: 拖慢我们的因素 礁石: 未来可能遇到的风险 目标岛: 我们的目标
| 维度 | 问题 | 评分 (1-5) |
|---|---|---|
| 交付价值 | 我们是否在交付有价值的东西？ | ⭐⭐⭐⭐⭐ |
| 技术质量 | 我们对代码质量满意吗？ | ⭐⭐⭐⭐☆ |
| 速度 | 我们的开发速度合适吗？ | ⭐⭐⭐☆☆ |
| 学习成长 | 我们在学习新东西吗？ | ⭐⭐⭐⭐⭐ |
| 心理安全 | 我们可以安全地表达不同意见吗？ | ⭐⭐⭐⭐☆ |
| 协作 | 我们协作得好吗？ | ⭐⭐⭐⭐⭐ |
趋势: 与上次相比 ↑ ↓ →
# 📅 复盘报告
## 📋 项目概况
- **项目名称**: [名称]
- **复盘类型**: [项目/Sprint/里程碑]
- **时间范围**: 2024-03-20 ~ 2024-03-27
- **参与者**: @alice, @bob, @charlie
- **复盘时间**: 2024-03-27 14:00-15:00 (1小时)
---
## 📊 数据回顾
### 项目数据
| 指标 | 目标 | 实际 | 差异 |
|-----|------|-----|------|
| 完成故事点 | 40 | 35 | -12% |
| Bug修复 | 15 | 18 | +20% |
| 代码覆盖率 | 80% | 82% | +2% |
| 发布次数 | 2 | 2 | ✅ |
### 速度趋势
Week 1: ████████░░ 80% Week 2: ███████░░░ 70% Week 3: █████████░ 90% Week 4: ████████░░ 85% (当前)
趋势: 稳定，略有下降
---
## 🟢 做得好的 (Loved)
### 1. 技术方案设计充分 ⭐⭐⭐⭐⭐
**具体**: 前期花了 3 天做技术评审
**影响**: 开发阶段返工很少，代码质量高
**数据**: Bug率比上次降低 30%
**保持做法**: 继续在每个 Sprint 开始前做技术评审
### 2. 每日站会有效 ⭐⭐⭐⭐☆
**具体**: 每天 15 分钟同步进展和阻塞
**影响**: 及时发现了接口对接问题，提前 2 天协调
**数据**: 平均阻塞时间从 2 天降至 0.5 天
---
## 📚 学到什么 (Learned)
### 1. 第三方依赖风险
**洞察**: 支付 SDK 升级导致兼容性问题，影响 1 天进度
**学习**: 新第三方服务接入前需要技术预研
**行动**: 建立第三方服务接入 checklist
### 2. 估算方法改进
**洞察**: 用 Poker Planning 比拍脑袋准多了
**学习**: 团队估算比个人估算更准确
**行动**: 所有 Story 都要经过 Poker Planning
---
## 🔴 缺少什么 (Lacked)
### 1. 缓冲时间 ⚠️ 中
**问题**: 排期太满，没有应对突发情况的余地
**影响**: 2 个低优先级功能被迫推迟
**数据**: 实际完成率是计划的 85%
**根因**: 过于乐观估算，未考虑不确定性
### 2. 联调环境 ⚠️ 高
**问题**: 第三方接口没有沙箱环境，只能上线后调试
**影响**: 上线后发现 3 个集成问题，紧急修复
**数据**: 上线后 Bug 50% 是集成问题
**根因**: 前期未要求第三方提供测试环境
---
## 💭 期待改进 (Longed for)
### 1. 增加 20% 缓冲时间
**方案**: 在估算基础上增加 20% 缓冲
**预期效果**: 应对不可控因素，减少延期
**负责人**: @alice
**截止时间**: 下次 Sprint 开始
### 2. 提前验证第三方接口
**方案**: 至少提前 1 周拿到测试环境并验证
**预期效果**: 减少上线后集成问题
**负责人**: @bob
**截止时间**: 建立流程文档
### 3. 引入自动化测试
**方案**: 核心流程添加 E2E 测试
**预期效果**: 减少回归 Bug，提高信心
**负责人**: @charlie
**截止时间**: 2 周内
---
## ✅ 行动项 (Action Items)
| 改进项 | 优先级 | 负责人 | 截止时间 | 验收标准 | 状态 |
|-------|-------|-------|---------|---------|------|
| 建立第三方服务 checklist | P1 | @bob | 2024-04-03 | 文档发布 | ⏳ |
| 优化项目排期模板 (+20%缓冲) | P1 | @alice | 2024-03-29 | 新模板使用 | ⏳ |
| 添加核心流程 E2E 测试 | P2 | @charlie | 2024-04-10 | 5个场景覆盖 | ⏳ |
| 建立联调环境标准 | P2 | @bob | 2024-04-05 | 写入团队规范 | ⏳ |
---
## 📈 团队健康度
| 维度 | 本次 | 上次 | 趋势 |
|-----|------|------|------|
| 交付价值 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐☆ | ↑ |
| 技术质量 | ⭐⭐⭐⭐☆ | ⭐⭐⭐☆☆ | ↑ |
| 速度 | ⭐⭐⭐☆☆ | ⭐⭐⭐⭐☆ | ↓ |
| 学习成长 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐☆ | ↑ |
| 心理安全 | ⭐⭐⭐⭐☆ | ⭐⭐⭐⭐☆ | → |
| 协作 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | → |
**整体健康度**: 🟢 4.2/5.0
---
## 🎯 下次迭代目标
1. **提高速度**: 从 3⭐ 提升到 4⭐
- 增加缓冲时间
- 减少上下文切换
2. **保持质量**: 维持 4⭐ 以上
- 继续技术评审
- 增加自动化测试
3. **学习成长**: 保持 5⭐
- 每周技术分享
- 代码审查学习
---
## 💬 团队反馈
**这次复盘的收获**:
- @alice: "终于意识到缓冲时间的重要性"
- @bob: "第三方风险 checklist 很及时"
- @charlie: "E2E 测试应该早点做"
**对复盘的反馈**:
- 时长: 合适 (1小时)
- 氛围: 开放、安全
- 产出: 可执行的行动项
---
## 🔗 历史复盘
| 日期 | 类型 | 关键改进 | 完成率 |
|-----|------|---------|--------|
| 2024-03-20 | Sprint | 技术评审流程 | 100% |
| 2024-03-13 | Sprint | 每日站会时间 | 100% |
| 2024-03-06 | 项目 | 代码审查规范 | 80% |
---
*上次复盘行动项完成率: 85%*
User: 复盘这个 Sprint
Retro Mode:
📅 Sprint 12 复盘报告
📊 数据
- 计划完成: 40 故事点
- 实际完成: 35 故事点 (87%)
- Bug 修复: 18 个
🟢 Loved
- 技术评审充分，返工少
- 站会发现问题及时
🔴 Lacked
- 缓冲时间不足
- 第三方联调环境缺失
✅ 行动项
改进项 负责人 截止时间 排期+20%缓冲 @alice 下次 Sprint 第三方 checklist @bob 本周五
User: 复盘 imaClaw 项目
Retro Mode:
📅 项目复盘: imaClaw
📊 整体评价
- 时间: 3周 (计划 2.5周，延迟 20%)
- 质量: 代码覆盖率 85%，生产 Bug 2 个
- 团队健康度: 4.2/5.0
🎯 关键洞察
- 做得好的: API 设计采用 OpenAPI 标准，前后端协作顺畅
- 学到: Vercel 部署需要正确配置 API 路由
- 改进: 前期应该做更充分的技术预研
✅ 沉淀为团队规范
- Vercel API 部署 checklist
- 前后端协作流程
不复盘的团队，永远在重复同样的错误。 —— Agile 名言