Matt Pocock Skills-新增ToTests和ToUserFlow

仓库地址：petrezhu/skills

Matt Pocock Skills - 新增 spec-to-tests 和 spec-to-userflow

在 Matt Pocock 的 AI Coding Skills 体系中新增了两个 skill，填补了从 spec 到实现之间的关键空白：

to-spec  →  spec-to-userflow  →  spec-to-tests  →  to-tickets  →  implement
 产出 spec     产出动线图           产出测试矩阵       产出工单         实现

spec-to-userflow（动线图）

作用

把 spec 中的用户故事转化为项目的 UserFlow.md：用户走过的每一条旅程、屏幕状态、分支路径、失败路径、退出点、风险等级，以及故事溯源。

核心理念： spec 说用户要什么，动线图说用户怎么走到那里。Vibe coding 中最容易出问题的就是”走过的路”：某个屏幕状态没人设计过（空态、错误态、过期态），某个分支没人接线，某条路径没人走过。

产出物：UserFlow.md

Flow 分区（FLOW-01, FLOW-02, ...）
屏幕清单（Screen inventory）
故事溯源（Story traceability）
缺口报告（Gap report）

每个 Flow 包含：

• 步骤表：用户动作 → 系统响应 → 屏幕/状态
• 分支：决策分支、失败路径、放弃点
• 风险等级：P0~P3（与 spec-to-tests 共用同一套分级）
• 故事溯源：每个用户故事至少映射到一个步骤；孤儿故事进缺口报告

使用方式

# 在项目根目录执行，spec 已存在的情况下
/spec-to-userflow

• 首次运行：生成 UserFlow.md
• 后续运行：增量扩展，不会全量替换
• 产出后接 /spec-to-tests，让测试矩阵从动线图中消费 Layer 1

适用场景

• 有 spec / 需求文档时（to-spec 产出后）
• CLI / API 产品同样适用，用资源状态转换替代屏幕

---

spec-to-tests（测试矩阵）

作用

把 spec、需求、已实现代码转化为结构化、可溯源的测试系统 Tests.md。把手工测试从”探索着找问题”变成”对着矩阵验证”。

核心理念： 不要让 AI 做 100% 的测试。让 AI 结构化测试空间：测什么、怎么测、怎么判断结果、怎么记录失败。自动化承担重复工作，人类承担最后一公里需要判断力的部分。

DONE 的定义

Code Complete
+ Automated PASS
+ Manual PASS
+ Regression PASS

“代码写完了”不等于”功能完成了”。”Agent 说搞定了”不等于 DONE。

产出物：Tests.md

三层结构，顶层级永远是用户动线，不是文件/类/函数：

User Flow（用户走不走得通）
    → Module / Capability（动线覆盖不到的关键能力）
        → Failure Matrix（真正会让用户出问题的异常条件）

三层详解

Layer 1 - 用户动线

• 来源：UserFlow.md 的每个 FLOW-NN
• 每步、每分支、每失败路径都变成测试用例
• 如果没有 UserFlow.md，从 spec 的用户故事推导，但在报告中标注缺口

Layer 2 - 模块/能力

• 覆盖用户动线触达不到的区域
• 核心业务逻辑、状态转换、数据一致性、权限边界、外部依赖、高回归风险模块

Layer 3 - 失败矩阵

• 按特性风险选取探测维度：

维度	探测条件
输入	正常、空、非法、边界、超长、特殊字符、重复、缺字段
用户操作	重复点击、快速操作、取消、返回、刷新、中途退出
状态	首次使用、有数据、无数据、部分数据、过期数据、重复数据、转换中
网络	正常、慢、超时、4xx、401/403、404、500、离线、空响应、畸形响应
环境	浏览器差异、视口、移动端、弱网、资源加载失败、并发操作

测试 ID 和状态

ID 前缀按能力域划分：AUTH-001, DASH-001, API-001, UI-001
状态只有三种：PASS / FAIL / BLOCKED
执行属性：AUTOMATED / MANUAL / HYBRID

使用方式

# Phase A: 构建测试系统（spec 已存在，测试还没建）
/spec-to-tests

# Phase B: 实现完成后验证
/spec-to-tests  （自动识别已有 Tests.md，进入验证模式）

流程主线

to-spec → spec-to-userflow → spec-to-tests → to-tickets → implement → spec-to-tests(验收) → code-review

与其他 Skill 的关系

方向	Skill	关系
上游	to-spec	产出 spec，用户故事是 Layer 1 的原料
上游	spec-to-userflow	产出 UserFlow.md，Layer 1 优先从中消费
下游	to-tickets	按动线分组工单
配合	tdd	在约定好的接缝处写自动化测试
配合	diagnosing-bugs	FAIL 的根因分析
验收	code-review	实现完成后、review 前先跑 Phase B

---

两者协同的工作流

1. /to-spec              ← 产出 spec
2. /spec-to-userflow     ← 从 spec 生成 UserFlow.md（动线图）
3. /spec-to-tests        ← 从 spec + UserFlow.md 生成 Tests.md（测试矩阵）
4. /to-tickets           ← 按动线分组生成工单
5. /implement            ← 实现代码
6. /spec-to-tests        ← Phase B：跑自动化测试 + 输出手工检查清单
7. /code-review          ← 最终 review

关键点：

• spec-to-userflow 在 spec-to-tests 之前运行，因为测试矩阵的 Layer 1 优先消费动线图
• 两个 skill 都是增量更新，不会全量覆盖已有的 .md 文件
• 风险分级（P0~P3）两套 skill 共用同一套词汇表，P0 动线 = P0 测试