| name | progress-tracking |
| description | 追踪项目进度和处理阻塞时使用。适用于项目执行阶段、定期状态汇报、阻塞升级。优先使用任务状态机 + 三级阻塞升级 + 进度摘要格式。 |
进度追踪与阻塞处理
适用场景
- 项目执行阶段的状态追踪
- 定期向用户汇报进度
- 阻塞发生时的升级处理
- 任务失败的恢复策略
任务状态机
每个任务在生命周期中经历以下状态：
┌─────────────────────────────────────────────────────┐
│ │
│ todo → in_progress → review → done │
│ ↓ ↓ ↓ │
│ skipped blocked rework → in_progress │
│ ↓ │
│ waiting_human │
│ ↓ │
│ in_progress │
│ │
└─────────────────────────────────────────────────────┘
状态定义
todo - 未开始，等待依赖完成
in_progress - 正在执行
blocked - 被外部因素阻塞（依赖未完成、工具不可用）
waiting_human - 需要人工介入（审批、确认、提供材料）
review - 执行完成，等待验收
rework - 验收未通过，需要返工
done - 验收通过，任务完成
skipped - 经评估后跳过（需说明原因）
状态流转规则
1. 只有依赖全部 done 的任务才能进入 in_progress
2. blocked 必须标注阻塞原因和预期解除时间
3. waiting_human 必须标注等待谁、等待什么、超时策略
4. review 失败后进入 rework，不能直接标 done
5. skipped 必须记录原因，且不能跳过门禁任务
阻塞升级策略
L1（自动解决，5 分钟内）：
- 工具暂时不可用 → 重试或换工具
- 上游产物小问题 → 自动修复后继续
- 处理：项目经理工作流自己解决，不打扰用户
L2（协调解决，15 分钟内）：
- 工作流间产物不匹配 → 协调双方对齐
- 依赖延迟但有替代路径 → 调整计划
- 处理：项目经理协调相关工作流，简短通知用户
L3（人工介入，立即升级）：
- 需求不清无法继续 → 请求用户澄清
- 外部依赖完全不可用 → 通知用户等待
- 安全/合规问题 → 暂停并请求授权
- 处理：通知用户后等待响应，不可继续
进度摘要格式
## 进度摘要 [日期/时间]
### 整体状态：🟢 正常 / 🟡 有风险 / 🔴 阻塞
### 完成情况
- 已完成：6 / 总任务数 10
- 当前阶段：开发阶段
- 关键路径状态：正常 / 延迟 N 分钟
### 正在执行
- T4 后端开发 by backend-engineer — 预计还需 15 分钟
- T5 前端开发 by frontend-engineer — 预计还需 20 分钟
### 已完成
- T1 PRD 评审 ✅
- T2 API 契约 ✅
- T3 数据库设计 ✅
### 阻塞项
- T6 联调 — 原因：等待 T4 完成 — 影响：关键路径 — 行动：等待
- T7 QA 测试 — 原因：等待 T6 完成 — 影响：关键路径 — 行动：等待
### 风险预警
- R3（QA 测试发现 Bug）— 概率变化：升高（T4 复杂度高于预期）— 建议行动：预留 30min 修复缓冲
### 下一步
- T6 联调（依赖 T4, T5 完成后开始）
- 用户决策点：是否需要在 QA 后增加性能测试？
失败恢复与回滚
任务失败处理
当某个工作流执行失败时：
1. 评估失败类型：
- 可重试失败（网络超时、工具暂时不可用）→ 自动重试（最多 2 次）
- 逻辑失败（代码编译错误、测试不通过）→ 进入 rework
- 不可恢复失败（依赖永久不可用）→ 升级到人工
2. 评估影响范围：
- 只影响当前任务 → 局部处理
- 影响下游任务 → 通知下游暂停
- 影响关键路径 → 触发计划调整
3. 恢复策略：
- 从最近的成功检查点恢复
- 不要从头重跑整个流程
- 保留失败日志用于复盘
项目级回滚
当项目需要整体回滚时（如上线后发现严重问题）：
1. 立即止血：回滚到上一个稳定版本
2. 保留现场：保存所有日志和状态
3. 定位问题：哪个工作流的产出有问题
4. 评估修复成本：修复 vs 重做
5. 更新计划：加入修复任务和重新验证
6. 复盘：为什么门禁没有拦住这个问题
工作流程
1. 项目执行中：
- 实时维护任务状态机
- 每个里程碑节点输出进度摘要
↓
2. 检测到异常：
- 状态变 blocked → 应用阻塞升级策略
- 验收失败 → 进入 rework
- 任务失败 → 应用失败恢复
↓
3. 重要节点（每个里程碑）：
- 输出进度摘要给用户
- 检查关键路径是否延迟
- 检查风险触发条件
↓
4. 项目结束：
- 生成最终进度报告
- 沉淀到 retrospective
质量自检
□ 每个任务是否有明确状态（不是"做了一些"）
□ blocked 任务是否标注了原因和预期解除时间
□ 进度摘要是否包含关键路径状态
□ 阻塞是否按 L1/L2/L3 升级
□ 失败任务是否记录了原因和恢复路径
□ 用户是否能从摘要中知道项目健康度
常见坑
- 状态只有"进行中"和"完成"——缺少 blocked/rework/waiting_human 等中间状态
- 阻塞后沉默——不主动升级，等用户问才说
- 进度摘要没有数字——只有"还在做"
- 关键路径状态不明确——不知道是否会延期
- 失败后从头重跑——浪费已完成的工作
- 不区分阻塞等级——L1 也升级到用户，L3 自己硬撑
- 预期解除时间不写——blocked 不知道要等多久
配套模板
templates/status-report-template.md — 进度摘要 + 阻塞报告 + 任务状态追踪模板
与其他 skill 的协作
上游：
wbs-decomposition → 任务列表
critical-path → 关键路径
milestone-gate → 里程碑节点
平行：
risk-management → 监控风险触发条件
change-control → 处理变更带来的状态变化
下游：
retrospective → 复盘进度问题
dora-metrics → 度量交付效能
