Flow feature
通用交付流程。用于 feature / modification / ui / refactor / design / change / cicd 等 Delivery 类任务。v2 先按风险执行，再按需要引入治理。From its SKILL.md
npx -y skills add laozaidad/feflow --skill flow-featureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.2 KB, as published. Nobody here has run it
flow-feature — v2 通用交付流程
flow-feature 在 v2 中不再是“默认分阶段广播器”，而是 Delivery 模式下的通用执行规范。
它的目标是：
- 先基于代码和仓库事实理解任务
- 按风险决定治理深度
- 让低风险任务保持直接
- 让高风险任务拥有足够的追踪、证据和回滚意识
适用范围：
- 新功能
- 现有功能修改
- UI/交互优化
- 组件或页面重构
- 设计落地
- 非事故型 CI/CD 或工程改造
硬规则
- 先搜索代码，再做实现判断。
- 不默认要求
.feflow/初始化。 - 不默认创建 Item。
- 不做“需求评审一次、计划评审一次、再开始写代码”的固定广播式交互。
- 只有在目标歧义、范围分叉、外部影响明显、或操作不可逆时，才停下来确认。
- 用户面向输出应使用自然语言，不要把内部控制平面术语暴露成主要界面。
风险分级
| 级别 | 特征 | 默认策略 |
|---|---|---|
| L1 | 局部、小范围、低风险 | 直接分析、实现、验证 |
| L2 | 多文件、中等风险、存在联动 | 轻量计划 + 适度治理 |
| L3 | 跨模块、高风险、外部行为明显变化 | 启用重治理、评审、回滚意识 |
通用执行顺序
所有 Delivery 任务先按这个顺序思考：
- 明确任务目标和边界
- 读取关键代码和相关调用链
- 判断风险级别
- 决定是否需要治理能力（Item / Memory / Evidence）
- 执行改动
- 做与风险相称的验证
- 输出结果和残余风险
不要先创建 Item，再倒推任务。
L1：直接交付路径
适用于：
- 文案、样式、局部逻辑
- 单文件修复或小范围修改
- 改动边界清晰、可快速验证
执行节奏：
- 读取相关文件
- 直接实现
- 做最小但可信的验证
- 汇报结果
默认不要求：
- Item
- 正式需求文档
- 正式开发计划文档
- 正式评审记录
- 完整证据包
若 .feflow/ 已存在，也不应因为“可以记录”就强迫把 L1 任务流程化。
L2：结构化交付路径
适用于：
- 多文件改动
- 功能或状态联动
- API、组件、store、路由之间有明确耦合
执行节奏：
- 读代码并输出一个简短执行方案
- 若
.feflow/已存在，可选择性加载相关记忆 - 只有在这些场景下才建议创建 Item：
- 任务预计跨多轮会话
- 任务需要证据链或依赖关系
- 任务涉及多人协作
- 任务影响范围已接近 L3
- 分步实现，但对用户展示保持简洁
- 运行明确的验证集合
- 总结改动、验证结果、残余风险
L2 允许存在简短计划，但这个计划应服务于执行，而不是取代执行。
L3：治理型交付路径
适用于：
- 跨模块改动
- 共享接口、公共组件或架构边界变更
- 构建、部署、权限、SSR、全局状态等高风险区域
- 需要跨会话追踪和明确回滚策略的任务
执行要求：
- 必须先完成足够的代码调研和风险判断
- 若
.feflow/可用，应创建 Item 并记录关键决策 - 必须有明确的验证策略
- 必须有最小可行回滚意识
- 需要时引入评审或额外检查
对用户输出应聚焦：
- 影响面
- 改动策略
- 关键风险
- 验证方式
- 需要确认的唯一关键决策
不要把 L3 变成“每个内部分阶段都要求用户点头”的体验。
记忆与证据
何时加载记忆
- L1：仅在明显命中历史问题时加载
- L2：推荐加载相关模块记忆
- L3：应加载相关约束、事件和历史模式
何时沉淀证据
- L1：以实际验证结果为主，可直接内联说明
- L2：对关键验证保留简要证据
- L3：应保留足够证据支撑发布或评审
何时更新记忆
仅在以下场景更新：
- 新增了值得复用的约束
- 发现了高复发风险的问题
- 形成了稳定的新模式
- 纠正了已有错误认知
不要把普通小改动全部写入长期记忆。
用户确认策略
不需要确认
- 正常读代码
- 低风险本地修改
- 明确范围内的实现推进
- 常规验证
需要确认
- 目标本身存在歧义
- 两种方案会显著改变范围或用户体验
- 改动具有破坏性或不可逆
- 涉及外部/生产/共享状态
推荐产物
并非所有任务都需要写文件。
| 场景 | 推荐产物 |
|---|---|
| L1 | 直接结果 + 验证摘要 |
| L2（无工作区） | 内联计划 + 结果摘要 |
| L2（有工作区且需追踪） | 简版计划、实施记录、测试摘要 |
| L3 | 决策摘要、实施记录、测试证据、必要时发布说明 |
退出条件
任务完成前至少满足：
- 改动与目标一致
- 风险被说明
- 验证与风险相称
- 未把范围偷偷扩大
异常分流
- 若发现任务本质是故障恢复或生产止血，转入
flow-hotfix - 若发现问题本质是缺陷修复而不是功能交付，可调用
flow-bugfix的根因分析节奏 - 若发现缺少必要上下文但仍可先做仓库理解，应先退回 Assist 而不是强行立项