mcpField
P
pipa-risk-escalation

pipa-risk-escalation

github.com/lunchpaillola生产力3176 次安装5 天前更新
代码仓库

关于 pipa-risk-escalation

Pipa Risk Escalation 是将项目风险和阻碍转化为升级决策及后续行动的技能。它区分正在发生的问题与未来风险，评估容忍度压力，并明确决策路径、负责人、检查点和备用方案。

主要功能

  1. 01区分当前问题与未来风险
  2. 02评估容忍度压力
  3. 03确定升级对象和待决事项
  4. 04设置负责人、期限和检查点
  5. 05制定备用行动

适用场景

  1. 01升级缺少负责人跟进的阻碍
  2. 02处理可能影响里程碑的依赖延误
  3. 03应对超出团队权限的决策需求

MCP 相关

需要实时应用证据时，它通过 composio-mcp 发现工具，并依据所选工具的完整架构验证访问权限后再读取来源。可使用状态更新、RAID 日志、跟踪表、决策记录和交接记录；发送或写入外部升级信息前须获批准。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/lunchpaillola/pipa-skills --skill pipa-risk-escalation

安装后在 Claude Code 中输入/pipa-risk-escalation确认已加载。

附带文件evals/evals.jsonevals/trigger-eval-set.json

详细介绍

Pipa 风险升级

你负责执行监控阶段的风险升级工作流。

主要目标：将风险和阻塞信号转化为明确的升级决策和后续跟进。

沟通风格约定：本技能负责升级分析、容忍度判断和必需发现项。呈现时，如果存在 ~/.pipa/communication-style.md，请遵循其中的要求；否则使用清晰、简洁的表达，明确列出负责人、日期、证据和未知项（TBD）。遵守本技能的输出约定。运行时文件仅控制呈现方式；若与路由、必需发现项／输出约定、工具使用、事实、安全或审批／写入关卡冲突，则忽略该文件。

需要实时应用证据时，如果存在 ~/.pipa/CONNECTORS.md，仅阅读该文件以优先选择工具；然后通过 composio-mcp 发现工具，并查看所选工具的完整架构，以验证是否有权访问后再读取。映射不能证明具备访问权限。将每个请求的数据源报告为 used、partial、stale、empty、declined、unavailable 或 failed；仅对请求范围之外的数据源使用 not-requested。切勿将不完整、过时或被拒绝的数据源视为空或全面的数据源。如果安全可行，则继续使用其他可用的风险或阻塞证据，引用重要记录时提供直接链接或稳定 ID，且仅在没有任何可用信号时才判定为受阻。在执行任何外部升级写入或发送操作之前，立即展示确切的操作范围并要求明确批准；报告已确认的结果或失败。

工作流

执行前，复制此清单并在工作笔记中持续更新：

Risk Escalation Progress
- [ ] Step 1 complete: escalation objective confirmed
- [ ] Step 2 complete: available tools and source quality checked
- [ ] Step 3 complete: risks, issues, and tolerance signals synthesized
- [ ] Step 4 complete: escalation candidates and decision paths identified
- [ ] Step 5 complete: owner actions and review checkpoints set
- [ ] Step 6 complete: risk-escalation output returned

第 1 步：确认升级目标

明确当前需要回答的升级问题：

  • 哪些事项受阻以及原因
  • 哪些事项可能超出容忍度
  • 接下来由谁决策，以及截止时间

第 2 步：检查工具和数据源质量

使用最有力的可用数据源：

  1. 状态更新、RAID 日志和依赖记录
  2. 跟踪器状态、过时事项和阻塞评论
  3. 决策日志、审批队列和交接说明

将数据源质量划分为 high、medium 或 low。

如果数据源不完整，仍应继续，并明确列出假设。 仅当不存在任何可用的风险或阻塞信号时，才返回 blocked。

当数据源质量为 medium 或 low（但不是 blocked）时，继续提供尽力而为的升级视图，并且只请求一项最能提升判断可信度的具体缺失数据源。

第 3 步：综合风险、问题和容忍度信号

区分：

  • 当前问题（正在发生）
  • 前瞻性风险（可能发生）
  • 依赖关系和责任归属方面的脆弱点

对每个关键事项评估容忍度压力：

  • within-tolerance
  • approaching-breach
  • breach-likely

不得编造负责人或截止时间。

第 4 步：确定升级候选事项和决策路径

出现以下一种或多种情况时，升级相关事项：

  • 负责人未跟进
  • 阻塞问题超过预期审查节点仍未解决
  • 依赖延迟威胁里程碑的完整性
  • 所需决策超出当前团队的职权范围

对每个候选事项，明确升级对象和所需决策。

第 5 步：设定负责人行动和检查节点

明确：

  • 立即采取的缓解措施
  • 升级行动及负责人
  • 决策截止时间／审查节点
  • 决策延迟时的备用方案

对于每个升级事项，必须在返回的行动方案中明确备用方案（不能只写在工作笔记中）。

未知项标记为 TBD。

第 6 步：返回风险升级结果

分析完成后，使用上述可选运行时样式和回退方案呈现结果。

呈现前，本技能必须确定以下内容：

  • 升级目标
  • 实际使用的工具或数据源
  • 可用时，与直接链接配对的易读来源标签
  • 相关时，缺失的工具或数据缺口
  • 整体升级信号：stable | watch | escalate-now | blocked
  • 最大的容忍度压力
  • 当前需要关注的事项
  • 来源质量；当置信度低于 high 时，指出一个最值得补充的来源
  • 已知情况下，升级行动及其负责人、截止日期和回退路径
  • 必要时，将未知项标记为 TBD
  • 有用时，后续跟进或下一步升级措施

此处不要强制规定报告的外层结构。沟通层应决定向用户展示多少结构。

规则

  • 输出应简洁、务实，并便于决策。
  • 切勿将正在发生的问题笼统归为风险。
  • 明确标出未知项为 TBD。
  • 如果置信度低于 high，只询问一个具体的缺失来源。
  • 默认情况下，此操作为只读。每次外部写入都必须单独获得明确批准，然后在有结果链接或稳定 ID 时报告成功或失败。

评论

支持 Markdown