技能介绍

它解决什么问题

需求经常以“加个导出按钮”或一份 Helm brief 的形式到达，工程师容易直接跳到页面和组件，跳过了一层推理：用户从哪里开始、要做什么决策、输入出错时落到哪、流程在哪里卡住。Draft Flow 接手的是这层设计工作——在写任何组件之前，先把任务路径画清楚，并把错误、空状态和摩擦点显式标出来。

工作方式

核心流程分六步：

理解任务：解析产品 brief、功能描述或用户任务，提取四个要素——Primary task（用户要完成什么）、Starting state、Done state，以及用户心智模型。若输入是 Helm brief，success_criteria 直接映射到 done state。
绘制 Happy Path：输出 Mermaid 流程图。节点只写用户动作或系统响应，菱形节点是用户决策且两个分支都要标注，起点说明用户所处位置与触发任务的原因，终点说明完成后用户看到什么、知道什么。
补充错误与空状态：加入校验失败、首次使用空界面、死胡同路径；每条错误必须有恢复路径，错误路径用 :::error 或注释标注。
标注决策点：为每个决策分支补充说明。
标记摩擦点：审查流程中是否出现要求用户回忆未提供的信息、在缺少上下文时做决定、一次错误就要从头再来、连续超过 3 次操作无系统反馈等情况，用 ▲ FRICTION: 标出。
交付：Mermaid 流程图、决策点标注、摩擦点及建议处理方式，外加一段关键设计决策的说明。

交付形式与适用边界

输出受 docs/output-kit.md 约束：CLI 展示上限 40 行，包含 box-drawing 头部、统一严重度标识、一行结论和 Top 3 发现。内容超预算时通过 /atlas-report 写入完整 HTML 报告，CLI 只作为回执。因此它定位在任务级流程设计，不负责高保真视觉或文案；产出的是推理与结构，实现部分仍由后续 UI 和代码工作承接。

截图预览

使用场景

在定义用户注册流程时，用它识别 Primary task、Starting state 和 Done state，并输出 Mermaid 流程图帮团队理清路径。
在处理表单或 API 调用时，用它给流程图补充 validation errors 与死胡同，检查每条错误路径是否有恢复入口。
当需求文档缺少边界情况说明时，用 ▲ FRICTION 标注找出用户缺上下文或需要回忆信息的步骤。
在评审新功能时，用它标出需要用户连续做决定却没有系统反馈的步骤，并给出建议处理方式。