pipeline_core/skills_library/all/flow-plan/SKILL.md

name	description	capability	tools
flow-plan	产线流程裁剪与 PM 任务拆解的通用概念规范——预制流程阶段、裁剪合法性、确认门禁、复杂度判断与子任务编排。任何产线的会话 agent 裁剪流程、PM 拆解复杂任务时先读它。触发：流程裁剪/简化流程/跳过阶段/任务拆解/子任务编排。	flow_plan_capability	create_sub_tasks

流程裁剪与任务拆解（通用概念规范）

一、概念

• 预制流程 = 产线声明的阶段链（能力包 flow_stages：key/label/描述/可裁性/角色/依赖）。
• 流程裁剪计划 = 项目级的一次性决定：哪些阶段保留、哪些裁掉。存 pipeline_flow_plans， 状态机 draft → pending_confirm → confirmed / rejected（驳回可修订重提，version+1）。
• 裁剪只在项目启动阶段有效：已有角色任务产出结果（approved/completed）后拒绝裁剪； 确认后不可改（要改流程 = 新建项目）。

二、可裁性三级（代码硬校验，不是 LLM 自觉）

trim	语义	propose 行为
no	流程必需（裁了流程不成立）	直接拒绝并说明原因
warn	质量门禁类（可裁但有风险）	允许，风险提示写进确认待办（用户双确认）
yes	自由裁剪	允许

依赖不变量：保留阶段的 deps 不得落在被裁阶段（如裁「章节骨架解析」则「章节编写」不成立）， propose 时代码校验拒绝。任何校验失败都要把原因如实转告用户，不得绕过或伪造成功。

三、确认门禁（人拍板点）

• 提案后系统发「流程裁剪确认」待办（flow_plan_confirm），只有用户能确认/驳回—— agent 没有确认工具，禁止声称「已确认」「已生效」。
• 待确认（pending_confirm）期间流转机制全局阻塞（不派发）；
• 驳回（rejected）期间同样阻塞：会话 agent 应主动 get_flow_plan 读驳回意见， 按意见修订 trim_keys 重新 propose（不要等用户催）；
• 确认后机制收敛：不再派发被裁阶段；「仅属于被裁阶段」角色的在办任务被取消 （跨阶段共用角色不受影响）。

四、会话 agent 工具

• show_flow_template：列预制流程阶段与可裁性（裁剪前必用，别凭记忆猜 key）。
• propose_flow_plan(trim_keys, user_requirements, propose_note)：生成草案+发确认待办。 user_requirements 必须写用户要求原文（进确认待办给用户看）。
• get_flow_plan：查计划状态与驳回意见。

五、PM 复杂度拆解（create_sub_tasks）

PM 推进流程时对派发的任务做复杂度判断，复杂任务拆为子任务组挂进主流程：

判断标准（满足其一即算复杂，倾向拆解）：

1. 任务描述含 ≥3 个可独立交付的工作面（如「解析六类评估项」「编写含多子系统的方案章」）；
2. 输入文档规模大（招标文件/需求书 > 50 页或 > 10 万字），单次执行易超时/漏项；
3. 产出需要多种角色协作（如同一章需要技术+商务素材）；
4. 历史同类任务 retry/revise 次数 ≥2（说明颗粒度过大）。

拆解规则：

• 每个子任务 {title, role, description, key?, depends_on?, dep_policy?}： title 具体到工作面；role 必须是本产线角色（list_roles 查）；description 写到操作层；
• 依赖编排：无依赖并行（不填 depends_on）；有先后用 key 互引 + depends_on； dep_policy 可选 {mode: all|any|at_least, n}；
• 子任务 parent_id 自动挂当前任务 → 任务树分层展示，编排子流程自动进项目主流程视图；
• 机制门禁：依赖解析失败的任务置 waiting 冒泡（不会静默降级为并行）；同标题活跃任务 自动取消（重做保护）；产线门禁风格（skip_generic_qc）自动继承；
• 拆完即交付本任务：派发子任务本身就是编排交付物，不要长等子任务完成； 子任务全部终结后由流转机制/验收环节闭环。

反模式（禁止）：

• 不判断复杂度就把所有任务一律拆碎（管理开销大于收益）；
• 拆解绕过流程裁剪计划（被裁阶段的子任务同样不得派发）；
• 用 create_sub_tasks 派其他产线的角色名（守卫会拒绝）。