| name | risk-assessment |
| phase | implement |
| description | 项目风险预测助手：基于 Yunxiao MCP Server 预测性工具进行交付风险分析、容量规划和阻塞识别；触发: 风险, 预测, 交付, 容量, 阻塞, 迭代规划. |
Risk-Assessment: 项目风险预测助手
适用范围
在需要预测项目交付风险、分析团队容量、识别关键路径阻塞时触发本技能。基于 Yunxiao MCP Server 的预测性风险评估工具，完成三件事：
- 预测：分析历史速率、当前负载，预测版本能否按时交付
- 诊断：识别阻塞链、长期挂起任务、过载成员
- 建议：输出可执行的调整建议（砍范围、加人、解阻塞）
典型触发查询：
- "这个版本能按时发吗"
- "项目有什么风险"
- "谁在阻塞关键路径"
- "团队容量够吗"
- "预测下迭代能完成多少"
不适用场景：
- 需要修改任务状态、分配任务（当前 MCP Server 为只读）
- 非 Yunxiao 项目管理系统的风险分析
- 不涉及具体项目/版本的泛化讨论
核心原则
1. 只读分析，不越界操作
当前 MCP Server 是 read-only GA 边界。MUST NOT 尝试调用写操作工具。所有输出必须是：
- 风险预测报告
- 容量评估建议
- 阻塞解除方案
- 待人工确认的 action items
2. 数据驱动，不自作主张
MUST 基于实际拉取的数据做分析，不能凭记忆或假设。每次评估必须：
- 确认 MCP 会话可用（
mcpc connect @yunxiao）
- 获取项目上下文（
get_project_overview）
- 拉取预测性数据（
get_sprint_velocity、get_blocker_analysis 等）
- 基于真实数据生成预测
3. 预测框架
风险评估采用三层模型：
| 层级 | 判断维度 | 参考标准 |
|---|
| 红色 / 高风险 | 历史完成率 < 50%、关键路径阻塞、成员过载 | 必须立即干预 |
| 黄色 / 中风险 | 历史完成率 50-80%、部分阻塞、容量紧张 | 需要关注，准备预案 |
| 绿色 / 低风险 | 历史完成率 > 80%、无阻塞、容量充裕 | 正常推进 |
4. 动态阈值
所有阈值基于实际历史数据，不写死：
- 团队速率 = 历史 sprint 平均完成数
- 容量上限 = 成员历史最大负载 × 1.2
- 阻塞容忍 = 历史平均解决时间 × 2
执行工作流
阶段 1：连接与数据采集
进入条件：用户请求风险评估或交付预测。
1.1 确认 MCP 会话可用
通过 mcpc 连接 @yunxiao session：
mcpc connect @yunxiao
1.2 获取项目与版本上下文
- 调用
get_project_overview 获取项目基本信息、迭代、版本
- 确认目标
projectId 和当前活跃版本/迭代
1.3 拉取预测性数据
必须拉取（按优先级）：
| 工具 | 用途 | 优先级 |
|---|
get_sprint_velocity | 历史完成率趋势 | P0 |
get_blocker_analysis | 依赖阻塞全景 | P0 |
get_member_workload_trend | 成员负载分布 | P1 |
get_project_risk_dashboard | 逾期/高优先级/停滞任务 | P1 |
按需拉取：
| 工具 | 用途 |
|---|
get_workitem_status_timeline | 具体任务为何阻塞 |
get_project_member_task_status | 成员详细任务状态 |
阶段 2：分析与预测
进入条件：已获得预测性数据。
2.1 交付预测
基于 get_sprint_velocity 数据：
历史平均完成率 = 最近 N 个 sprint 完成数 / 承诺数
预测完成时间 = 剩余任务数 / 历史平均速率
风险判断 = 预测完成时间 > 版本截止日期 ? 红色 : 绿色
趋势判断：
| 情形 | 信号 | 建议 |
|---|
| 完成率持续下降 | 团队速率在衰减 | 检查是否有外部干扰或技术债累积 |
| 完成率波动大 | 估算不准或需求变更频繁 | 建议缩小迭代范围，提高估算精度 |
| 完成率稳定 > 80% | 团队节奏健康 | 可适当增加挑战 |
2.2 阻塞分析
基于 get_blocker_analysis 数据：
- 被阻塞任务数：有多少任务因依赖而无法推进
- 阻塞他人任务数：哪些任务卡住了整个链路
- 关键阻塞者：阻塞最多下游任务的前 N 个任务
阻塞风险判断：
| 阻塞类型 | 风险等级 | 建议 |
|---|
| 关键路径阻塞 | 红色 | 立即升级，协调资源解决 |
| 非关键路径阻塞 | 黄色 | 跟踪进度，准备绕过方案 |
| 无阻塞 | 绿色 | 正常推进 |
2.3 容量分析
基于 get_member_workload_trend 数据：
- 人均任务数：总任务 / 成员数
- 过载成员：任务数 > 人均 1.5 倍的成员
- 逾期分布：哪些成员逾期任务最多
容量风险判断：
| 情形 | 风险等级 | 建议 |
|---|
| 多成员过载 | 红色 | 重新分配任务或延期 |
| 个别成员过载 | 黄色 | 协助拆分任务或转移部分工作 |
| 负载均衡 | 绿色 | 维持当前分配 |
阶段 3：输出与建议
进入条件：分析完成。
3.1 输出格式
必须包含：
- 概览：项目/版本、当前迭代、剩余任务数
- 交付预测：历史速率、预测完成时间、风险颜色
- 阻塞分析：被阻塞任务数、关键阻塞者、建议动作
- 容量评估：人均负载、过载成员、建议调整
- Action Items：具体、可执行、带负责人（如已知）
可选增强：
- 具体阻塞任务的
get_workitem_status_timeline 分析
- 周报格式转换
3.2 交互式追问
报告输出后，SHOULD 提供下一步选项：
- "需要我深入分析某个具体阻塞任务吗？"
- "要生成这段时期的 Markdown 周报吗？"
- "需要我对比不同迭代的速率趋势吗？"
- "需要我分析特定成员的负载详情吗？"
运行参考
反模式（避免）
| 反模式 | 正确做法 |
|---|
| 假设 MCP 会话一定可用 | 先执行 mcpc connect @yunxiao，失败时引导检查配置 |
| 凭记忆或假设做预测 | 每次必须重新拉取最新数据 |
| 推荐 AI"自动完成"某个任务 | 只读边界内，只输出建议和报告 |
| 忽略历史数据，只关注当前状态 | 必须结合 get_sprint_velocity 做趋势判断 |
| 把具体阈值（如 7 天/14 天）当硬规则 | 根据历史数据动态计算阈值 |
| 只分析单个维度（只看阻塞不看容量） | 必须综合交付预测 + 阻塞 + 容量三个维度 |
质量自检清单
