| name | shape-up-cycles |
| description | 管理交付节奏和 Cycle 时间盒时使用。适用于替代传统 Sprint、固定时间可变范围的项目、AI 工作流的快节奏管理。优先使用 Linear Cycles + Basecamp Shape Up + Cooldown 节奏。 |
Cycle 节奏管理
参考来源：Linear Cycles、Basecamp Shape Up
适用场景
- 替代传统 Sprint
- AI 工作流的快节奏交付
- 固定时间可变范围的项目
- 避免估算地狱
- 需要持续交付节奏
核心思想
传统 Sprint：
估算时间 → 排满 → 时间不够延期或砍质量
Cycle 模式：
固定时间盒（Appetite）→ 时间到了交付当时最有价值的部分
范围可调，时间不延
AI 工作流的优势：
执行速度快，瓶颈在等待
Cycle 节奏更适合短周期、高频交付
Cycle 类型（AI 工作流适配）
Micro Cycle：30~60 分钟
- 一个功能点从设计到测试
- 适合 S/M 级任务
- 单工作流或 2 个工作流串行
Standard Cycle：2~4 小时
- 一个完整模块
- 适合 M/L 级任务
- 多工作流协作
Extended Cycle：1 天（实际执行 6~8 小时 + 等待）
- 跨多模块的大功能
- 适合 L 级任务
- 全流程参与
Multi-Day Cycle：2~5 天
- 大型项目阶段
- 适合 XL 级任务
- 包含多个 Extended Cycle
Cycle 规则
1. 开始前明确目标和验收标准
- 不是"做某些功能"
- 而是"达到某个可验证的状态"
2. Cycle 内不接受新需求
- 变更进入下一个 Cycle
- 紧急 bug 例外（占用 cooldown）
3. 时间到了但没完成
- 砍范围交付最有价值的部分
- 不延期
- 剩余范围进入下个 Cycle
4. Cycle 结束后必有 cooldown
- 不能背靠背开始新 Cycle
- cooldown 用于消化遗留问题
Cooldown（冷却期）
每个 Standard Cycle 后：15~30 分钟
每个 Extended Cycle 后：1~2 小时
每个 Multi-Day Cycle 后：半天到一天
Cooldown 用途：
- 处理上个 Cycle 遗留的小问题
- 更新文档和 field-journal
- 为下个 Cycle 做准备
- 团队/工作流回血
- 不安排新的开发任务
为什么必须有 cooldown：
- 防止技术债积累
- 给文档更新留时间
- 让经验沉淀下来
- 避免连续高强度交付崩溃
Cycle 内的关键活动
Cycle Kickoff（开始）
□ 明确 Cycle 目标
□ 定义验收标准
□ 列出 Cycle 内的任务（用 wbs-decomposition）
□ 标注关键路径和风险
□ 启动 progress-tracking
Cycle 执行（中间）
□ 按编排模式执行（来自 orchestration）
□ 实时维护任务状态
□ 阻塞按 L1/L2/L3 升级
□ 不接受新需求（除紧急 bug）
□ 时间预算监控
Cycle End（结束）
□ 验证 Cycle 目标是否达成
□ 时间到了砍范围（如果未完成）
□ 输出 Cycle 报告
□ 简短复盘（5 分钟）
Cooldown（冷却）
□ 处理遗留小问题
□ 更新 field-journal
□ 沉淀经验
□ 准备下个 Cycle
Cycle 报告模板
## Cycle 报告：[Cycle 名称]
### 基本信息
- Cycle 类型：Standard / Extended / Multi-Day
- 时间范围：[开始时间] ~ [结束时间]
- 实际耗时：X 小时
### Cycle 目标
[明确写出本 Cycle 要达成的目标]
### 完成情况
| 任务 | 状态 | 备注 |
|------|------|------|
| T1 | ✅ done | 按预期完成 |
| T2 | ✅ done | 比预期快 |
| T3 | ⚠️ rework | 验收未通过，下个 Cycle 修复 |
| T4 | ⏰ skipped | 时间不够，移到下个 Cycle |
### 关键交付物
- [产出 1]
- [产出 2]
### 阻塞和异常
- 阻塞 1：[描述] - 解决方式：[L1/L2/L3]
- 异常 1：[描述] - 影响：[评估]
### 下个 Cycle 准备
- 待修复：T3
- 待处理：T4
- 新需求：[列表]
### 简短复盘
- 做得好：[1~2 条]
- 待改进：[1~2 条]
- 沉淀：[field-journal 条目]
Cycle vs Sprint 对比
| 维度 | Cycle | Sprint |
|------|-------|--------|
| 时间盒 | 灵活（30min ~ 多天） | 固定（通常 2 周） |
| 范围 | 可变 | 固定 |
| 估算 | 不估，按 Appetite | 详细估算 |
| 仪式 | 简化（Kickoff + 简短复盘） | 完整（Planning/Daily/Review/Retro） |
| 节奏 | 连续 + Cooldown | 连续 Sprint |
| 适合 | AI 工作流 / 小团队 | 传统团队 / 大项目 |
工作流程
1. Cycle 规划：
- 确定 Cycle 类型（Micro/Standard/Extended/Multi-Day）
- 设定 Appetite（时间盒）
- 明确 Cycle 目标
↓
2. Kickoff：
- 加载 wbs-decomposition + critical-path + orchestration
- 列出任务
- 启动 progress-tracking
↓
3. 执行：
- 不接受新需求
- 实时追踪状态
- 时间监控
↓
4. End：
- 验证目标
- 必要时砍范围
- 输出 Cycle 报告
↓
5. Cooldown：
- 处理遗留
- 更新 field-journal
- 准备下个 Cycle
质量自检
□ Cycle 目标是否可验证
□ Appetite 是否合理（不要 100h 的 Cycle）
□ 是否真的不接受新需求
□ 时间到了是否真的砍范围（不是延期）
□ 是否有 Cooldown
□ Cycle 报告是否输出
□ 简短复盘是否做了
常见坑
- 没有 Appetite——又陷入估算地狱
- Cycle 太长——失去灵活性
- Cycle 太短——开销大于收益
- 接受 Cycle 内新需求——破坏时间盒
- 没有 Cooldown——技术债累积
- Cooldown 被压缩——"时间紧" → 失去消化时间
- 不做简短复盘——经验流失
- Cycle 报告流于形式——不真实评估
配套模板
templates/cycle-kickoff-template.md — Cycle 启动模板templates/cycle-report-template.md — Cycle 报告模板templates/cooldown-checklist-template.md — Cooldown 清单
与其他 skill 的协作
上游：
okr-alignment → 用 OKR 指导 Cycle 主题
平行：
wbs-decomposition → Cycle 内的任务分解
progress-tracking → Cycle 执行追踪
下游：
retrospective → Cycle 复盘
dora-metrics → Cycle 数据用于 DORA 计算
