面向软件需求的流程验证与追踪 Skill

把模糊需求
变成可验证、可追踪的流程规格

FlowSpec 把流程图当作需求验证与追踪工具，而不是把原文逐句换成节点。它区分事实与假设、检查异常路径、产出可编辑 draw.io 图，并让验收、测试与需求一一对应。

开始使用 输出产物
3分层证据
draw.io原生可编辑
CLI确定性校验
flow.login.drawio
开始 · 登录
F1 · 需求源: PRD#12
→
校验凭据
F2 · 3 次重试上限
H1 阈值待验证
假设 · 超时 30s
→
通过 · 进入系统
AC-01 ✓
已确认事实 待验证假设 信息缺口
PROBLEM / 痛点

一份流程图，能回答这些吗？

/ 01

凡是说不清的，都被悄悄补全了

大多数生成工具会把没写明的规则圆滑地补上，让图看起来「完整」，却丢失了业务真相。阈值、超时、权限、失败路径——没人知道它们来自哪里。

→ 缺少证据分层
/ 02

图很漂亮，但没法校验

不可达节点、无终点路径、无退出条件的循环、决策分支不完备……这些结构问题靠肉眼很难发现，等到集成时才爆雷。

→ 缺少确定性的结构校验
/ 03

需求一变，牵一发动全身

验收标准、测试场景、流程节点散落在不同文档里。改一处需求，没人清楚哪些验收、哪些测试、哪些分支会受影响。

→ 缺少追踪矩阵
THE LOOP / 核心闭环

从一句模糊需求，到可评审的规格

1

识别证据

事实 / 假设 / 缺口 分层

▸
2

建立模型

流程或状态流转

▸
3

规范化 JSON

稳定 ID + 追踪关系

▸
4

结构校验

脚本检查不变量

▸
5

原生 draw.io

可编辑图形

▸
6

验收 + 测试

Given/When/Then

▸
7

追踪矩阵

需求 ↔ 节点 ↔ 测试

▸
8

变更影响

稳定 ID 传播

WHY FLOWSPEC / 核心差异

它不是画图工具，是需求的验算器

🔬

证据第一位

把「已确认事实、待验证假设、信息缺口」设为一等数据，阻断模型凭常识发明规则。

  • 不反问已能从材料核实的事实
  • 阈值/权限/超时必须有来源
  • 状态诚实：draft → review_ready → verified
📐

可校验的中间模型

用规范化 JSON 做确定性中间层，脚本验证结构不变量，而非依赖文本直觉。

  • 显式开始 / 明确终点
  • 不可达节点、无终点路径
  • 循环退出条件、重试上限、外部写失败
🧭

稳定 ID 追踪

需求来源 → 节点/边 → 验收 → 测试互相定位，变更自动生成影响报告。

  • 一项需求可控全部后续影响面
  • 元数据保留在 draw.io 中继续编辑
  • 验收标准可执行、可测试
对比说明：draw.io 官方 Skill、drawio-skill 等负责「画出可编辑的图」——它们专注于绘制质量与布局。FlowSpec 补上的是它们都不做的一层：需求的证据分层、结构校验与验收/测试追踪。输出侧的 draw.io 只是这条验证闭环的末端产物。

同类对照 · 能力边界

开源 Agent Skills 生态中与 FlowSpec 相近的产物，按「需求闭环」四层能力对比。

能力 draw.io 官方 Skill drawio-skill mermaid-flowchart-formatter business-analyst-agent FlowSpec
事实/假设/缺口分层 ✕ ✕ ✕ △ 轻量 一手证据第一位
规范化 JSON 中间模型 + 结构校验 ✕ ✕ ✕ ✕ 一手确定性脚本校验
原生可编辑 .drawio 输出 同构核心能力 核心能力 ✕ ✕ 末端产物支持
稳定 ID · 需求→验收→测试 追踪 ✕ ✕ ✕ △ 追踪矩阵 一手变更影响传播
异常路径/状态冲突审计 ✕ ✕ 仅样式 △ 有限 一手不可达/无终点/循环
结论：输出侧「画 draw.io」能力已同质化。FlowSpec 的独占差异收敛到 需求侧闭环——事实分级、确定性结构校验、稳定 ID 变更传播，这三项在纯作图 Skill 中均不存在。
OUTPUTS / 每一次交付

一套可直接评审的规格包

01 · 证据清单

事实 · 假设 · 缺口

哪些已被证实、哪些只是假设、哪些必须追问，一条条写明来源、风险与验证方式。

02 · 可编辑图形

原生 .drawio 流程图 / 状态图

图文件是未压缩的原生 XML，节点、边、泳道与追踪元数据可在 draw.io 中继续编辑。

03 · 逻辑审计

异常路径与状态冲突

严重度、问题、证据、影响、建议逐条列出，让边界不再是隐性假设。

04 · 验收标准

Given / When / Then

稳定 ID、关联节点，含「不得发生」的副作用与可观测的验证方式。

05 · 测试场景

正常 · 边界 · 错误 · 状态 · 恢复

覆盖完整路径的测试，附带前置、步骤、预期与结束状态。

06 · 追踪矩阵

变更影响报告

需求来源 ↔ 节点/边 ↔ 验收 ↔ 测试 一一对应；有基线时自动产出影响分析。

GET STARTED / 机器可校验

一个 CLI，把规格变成可验证的产物

 flowspec · cli
$ python3 flowspec.py validate spec.json
✔ 结构校验通过 · 1 个显式开始 · 2 个终点 · 引用完整
$ python3 flowspec.py validate spec.json --strict
⚠ 警告：H1 假设「超时 30s」尚无证据，未达 review_ready
$ python3 flowspec.py render spec.json --output flow.drawio
✔ 已生成 flow.drawio · 原生 XML · 可在 draw.io 继续编辑
$ python3 flowspec.py diff before.json after.json --format markdown --output impact.md
✔ 变更影响 · 影响 3 个节点 / 2 条验收 / 4 个测试
$ # 校验只证明结构，不证明业务真实 —— 真实行为仍需环境与真机验证
支持的平台 ↓
FOR TEAMS / 谁在用

需求澄清与协作的公共语言

PRODUCT

产品经理

把模糊 PRD 与会议纪要变成边界清晰、证据分层的流程规格，需求澄清更快、更少歧义。

ANALYSIS

业务分析师

产出结构可校验的流程与状态模型，异常路径与信息缺口一目了然。

ENGINEERING

研发与测试

拿到与验收、测试、需求互相对齐的可编辑图，变更影响评估不再靠拍脑袋。

AVAILABLE ON

跨平台可移植

OpenAI Claude Generic Agent-Skills-Compatible