pipa-status-update

Pipa 状态更新

运行一个监控阶段的状态工作流，将分散的交付信号转化为可用于决策的状态报告。

主要目标：清楚回答“当前进展如何、哪些事项需要关注、接下来会发生什么？”，并明确责任人和后续跟进。

状态撰写规则：让报告的开篇几行就能传达核心内容。领导者无需滚动页面，就应了解当前状态和需要提出的问题。

RAG/RAID 运作规则：

• 使用 RAG（green、yellow、red、blocked）表达交付状态
• 维护简洁的 RAID 视图（risks、assumptions、issues、dependencies）
• 为每个红色/黄色信号指定责任人、下一步行动和升级触发条件

沟通风格约定：此技能负责状态分析、RAID 推理和必要的责任人信号。呈现内容时，如果存在 ~/.pipa/communication-style.md，则按其要求执行；否则输出清晰、简洁的内容，并明确列出责任人、日期、证据和未知项（TBD）。保留此技能的输出约定。运行时文件仅控制呈现方式；若与路由、必要发现/输出约定、工具使用、事实、安全或批准/写入门槛冲突，则忽略该文件。

当用户要求提供实时应用证据时，如果存在 ~/.pipa/CONNECTORS.md，请读取它，但仅用于优先选择工具；随后使用 composio-mcp 发现工具，并通过完整的所选工具架构验证访问权限，然后再读取数据。映射关系不能证明具有访问权限。将每个请求的数据源标记为 used、partial、stale、empty、declined、unavailable 或 failed；仅对请求范围之外的数据源使用 not-requested。绝不能将部分数据、过时数据或已拒绝的数据源视为空或完整数据。只要安全，就应继续使用其他可用的状态证据；引用重要记录时，提供便于理解的标签以及直接链接或稳定 ID；仅当没有任何可用的项目状态信号时才阻止继续。进行任何外部更新或发送前，必须立即展示范围明确的具体操作，并要求明确批准；报告已确认的结果或失败情况。

工作流

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

Status Progress
- [ ] Step 1 complete: status objective and audience confirmed
- [ ] Step 2 complete: available sources and signal quality confirmed
- [ ] Step 3 complete: project state and RAG signal synthesized
- [ ] Step 4 complete: RAID items and owner gaps identified
- [ ] Step 5 complete: decisions and next milestones clarified
- [ ] Step 6 complete: status output returned

不得跳过任何步骤。

步骤 1：确认状态目标和受众

确定用户当前需要什么：

• 可直接用于站会的团队更新
• 面向利益相关者或领导层的汇总
• 会前项目健康状况概览
• 跨职能后续跟进检查

设定受众对应的语气和详细程度：

• 团队级：具体任务和责任人行动
• 领导层级：简明信号、主要风险和决策请求

此处不要决定最终措辞或开篇形式。请使用上述可选的运行时风格及其默认风格来呈现发现。

步骤 2：确认数据源和信号质量

按以下顺序使用最有力的数据源：

1. Pipa 系统记录（Jira、Linear、ClickUp、Asana、Trello）
2. 最新状态说明或会议摘要
3. 交付材料（里程碑计划、待办事项视图、发布说明）
4. 沟通信号（Slack、评论、电子邮件往来）

对数据源质量进行分类：

• high：Pipa 记录以及近期状态信号
• medium：有 Pipa 记录或状态说明，但其中一方较弱
• low：仅有叙述性内容或上下文不完整

如果数据不完整，请基于现有信息继续，并列出提高可靠性所需的最少补充信息。

仅当没有任何可用的项目状态信号时，才返回 blocked。

第 3 步：综合当前项目状态和 RAG 信号

构建简明的状态信号：

• 当前状态：green、yellow、red 或 blocked
• 自上一个可见检查点以来发生的变化
• 当前需要关注的事项

优先报告成果，而非活动日志。应从已交付的影响、风险降低或决策进展等方面说明进展，而不是会议节奏。

除非项目提供了特定的评估标准，否则使用以下默认状态判断规则：

• green：没有实质性阻碍；计划偏差看起来可由现有负责人在现有时间表内弥补
• yellow：存在一个或多个需要在本周期主动管理的重要风险、延误或负责人缺口
• red：若不立即干预、重新规划或升级处理，交付目标将面临实质性风险
• blocked：缺少必要的源信号，或关键依赖导致当前无法推进

优先使用来源事实，再进行推断。两者应分开。

来源事实包括：

• 未完成与已完成工作的变化
• 里程碑或交付物状态
• 新增的高优先级事项
• 已记录的阻碍或依赖延误

推断信号包括：

• 可能的进度压力
• 协调风险
• 跟进执行的不稳定性

不要虚构负责人、截止日期或完成百分比。

第 4 步：识别 RAID 事项和负责人缺口

提炼出影响结果的最少一组问题：

• 风险：尚未发生但未来可能出现的问题
• 假设：被认为属实且会影响执行的条件
• 问题：当前正在发生的阻碍或问题
• 依赖：外部前置条件、审批或交接
• 负责人缺口（未知时填写 TBD）

每个标记的问题都必须包含下一步行动和明确的下一状态。

风险质量门槛：

• 对于没有负责人、触发条件和缓解措施的风险，应将其视为担忧；在这些字段补齐之前，不要将其纳入主要报告

不要把风险和问题合并为一类。如果某事项正在发生，应归类为问题。

在工作分析中，将来源事实与推断分开。只有当推断会改变决策、行动或升级路径时，才在最终消息中提及。

第 5 步：明确决策和下一阶段里程碑

列出：

• 当前需要作出的决策
• 近期里程碑或检查点
• 每位负责人接下来应采取的行动

如果决策负责人不明确，标记为 TBD，并建议由相关职责角色负责。

第 6 步：返回状态发现

分析后，使用可选的运行时样式及上述回退方案呈现发现。

在呈现之前，此技能必须确定：

• 当前状态：green、yellow、red 或 blocked
• 说明当前状态原因的一句话
• 本周期内发生或取得的进展
• 当前需要关注的事项
• 最精简且有用的一组 RAID 事项
• 在适用时，在靠前位置明确列出一项决策、负责人或下一步行动
• 对于 yellow、red 或 blocked，在靠前位置明确列出一套负责人—行动—升级方案
• 可进一步查看的来源；有可用的直接链接时，使用易于理解的标签
• 信心有限时所缺少的最少输入

必要时，将 RAID 类型标记为 [R]、[A]、[I] 或 [D]，但如果简短的项目符号更清晰，就不要强行使用表格。

如果状态为 blocked，应明确说明，并包括：

• 一项具体缺失的来源
• 该来源的重要性
• 解除阻塞的最佳下一步

规则

• 保持输出可执行且简洁。
• 优先使用便于决策的项目符号，而非叙述性段落。仅在确实能提升清晰度时使用表格。
• 开头几行必须独立成文：说明项目状态及原因、明确提出请求，并交代当前状态或进展。
• 将请求放在靠前位置，并使用粗体标注日期。
• 对于 yellow、red 或 blocked 状态，在开头附近明确列出一项包含负责人、行动和升级措施的安排，不要让后续跟进事项含糊不清。
• 尽可能将报告控制在一屏手机屏幕内。
• 使用平实语言，仅突出少数关键字词，便于快速浏览。
• 避免使用证明工作已完成的表述（例如“召开了同步会议”或“启动了审查”），除非与结果相关。
• 将未知事项明确标记为 TBD。
• 当来源质量为 medium 或 low 时，在最终消息中指出最少还缺少哪些输入。
• 不要自动关闭事项。
• 保留来源引用和提供的直接链接，但在最终输出中优先使用易读的标签，而非原始 ID。
• 对于 yellow 或 red，明确列出一项升级触发条件。
• 情况需要时，尽早标记为 yellow 或 red；不要粉饰不确定的状态。
• 除非需要更多 RAID 事项来解释状态，否则最终输出优先保留一到两项。
• 默认情况下，此操作为只读。每次外部写入都必须另行获得明确批准，然后在可用时提供结果链接或稳定 ID，并报告成功或失败。