工作流设计引擎

解决什么问题

多数 Agent 收到「帮我设计一个审批流」这类请求时，要么直接吐一段散文，要么一步到位给出一份看起来完整、实际上跑不起来的配置。缺的东西很具体：节点该由哪个 Skill 或 MCP 工具执行、输入数据从哪来、审批节点的时限是多少、依赖的 API 在当前环境里到底有没有、分支条件写错以后由谁兜底。

@user_989eb8f0/tri-workflow 把这件事拆成一条固定流水线，强制在每一步留下可检查的中间产物，而不是让模型一次性把答案糊出来。

核心能力

• 版本门前置：任何执行入口的第一步是跑 scripts/check_update.py，拿 JSON 的 state 字段决定放行、降级还是阻断。脚本自带节流（默认 24 小时校验一次）和 --dry-run 只判定不升级，避免每次调用都打网络。
• 上游依赖三态：检测 tri-intent 是否可用。有可用快照走 A 快照模式，只读快照 §三 的 intent.L2_核心意图，校验其属于 I13 或 I14；有目录无快照走 A0 待识别，提示用户先过意图识别；都没有走 B 独立降级，从对话里提取 工作流类型、触发方式、核心节点 等必填字段。
• 七阶段流水线：环境感知 → 模板匹配 → 对话补全 → 编译优化 → 校验验证 → 多目标输出 → 迭代反馈。每阶段产出独立文件（env-profile.json、workflow-model.json、dependency-report.md 等），用户可以在任意阶段确认或终止。
• 节点模型对齐 BPMN 五要素：每个节点明确 role（谁执行）、action（做什么）、inputs（需要什么）、outputs（产出什么）、SLA（多久完成），自动节点还必须把 role 映射到环境扫描到的 Skill / MCP / API。
• 多形态输出：按工作流类型映射到不同后端——协作流水线出 .github/workflows/*.yml，业务审批流出审批模板 JSON，数据处理流出 DAG 配置加脚本。所有类型都额外产出一份声明式 workflows/*.wf.yml 作为可版本管理的单一事实来源。
• 硬阻断而非软警告：阶段 5 依赖校验发现缺失关键 Skill 或 API 时，停止生成并输出结构化恢复指引（含安装或配置命令），而不是产出一份标注「需要自行补全」的工作流。
• 反馈闭环：设计文档末尾嵌入反馈模板，支持 Webhook 回调自动上报节点执行情况，SLA 达标率低于阈值时自动重入编译优化阶段。

使用边界

• 只做设计，不做实现。节点内部的业务代码由 tri-coding 负责，本技能仅在需要新建 Skill 时产出 SKILL.md 骨架。
• 环境感知是只读扫描，不会修改已有 Skill 或配置文件。
• B 独立降级模式下拿不到意图校验和澄清门禁，也无法提取组织约束，只能扫描本地 Skills / MCP 目录。要完整体验建议先装 tri-intent。
• 最小化原则是硬约束：只实现快照或对话中明确要求的范围，不会主动扩节点或加未要求的交付形态。
• 版本门自身故障时兜底放行，不会因为更新通道挂了导致技能无法启动。