---
name: flow
description: >
  当用户说 /flow、复杂任务、多步骤任务、编排、先优化再规划再执行时使用此技能。
  将复杂任务拆分为"Prompt优化→深度思考→规划→并发执行"管道，支持 --quick/--think/--mermaid/--discuss 等参数。
  当任务涉及 3 个以上步骤、用户提到"编排"或"flow"、或需要组合多个技能时，都应使用此技能。
  简单单步任务不要使用。深度版用 /flow-deep。
user-invocable: true
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - WebFetch
  - WebSearch
  - AskUserQuestion
  - Agent
  - TeamCreate
  - TeamDelete
  - SendMessage
  - TaskList
  - TaskCreate
  - TaskUpdate
  - TaskGet
  - EnterPlanMode
  - ExitPlanMode
---

# Flow - 复杂任务编排引擎

将多个技能串联为"优化 → 思考 → 规划 → 执行"的完整管道，通过参数灵活控制每个阶段。

## 触发条件

**TRIGGER when user:**
- 显式调用 `/flow <任务描述>`
- 请求处理复杂任务："帮我处理这个复杂任务"、"这个任务比较复杂"
- 请求编排式执行："先优化再规划再执行"、"从优化到执行"
- 使用关键词：flow、编排、管道、复杂任务流程
- 任务描述明确涉及多步骤、多角色、或需要拆分执行

**AUTO-DETECT:**
- 用户描述的任务涉及 3 个以上步骤
- 用户提及多个技能的组合使用（如"先 /prompt 再 plan 再 multi-agent"）

## 选型指南：何时用 flow vs flow-deep vs grill-me

> flow 是轻量编排。更轻用 grill-me，更重用 flow-deep。完整决策依据、组合用法、误用案例见 `references/selection-guide.md`。

**口诀**：小澄清 grill-me，大工程 flow-deep，中间 flow。拿不准问"做错了多难恢复"。

| 场景 | 入口 |
|------|------|
| 中等特性（3-5 步、单模块、可回滚） | **flow** |
| 核心重构 / 支付 / 认证 / 对外 / 安全 | **flow-deep** |
| 只想澄清、产出 design tree | **grill-me** |
| 方向都没定 | 自由对话 / brainstorming |

升级/降级信号、组合用法、三种误用 → 详见 `references/selection-guide.md`。交互式路由可用 `/ask-matt`（路由 mattpocock 体系，不覆盖 flow/flow-deep）。

## 必需依赖

| 依赖项 | 类型 | 用于阶段 |
|--------|------|---------|
| `/prompt` | Skill | Stage 1: Prompt 优化 |
| `planning-with-files` | Skill | Stage 3: 任务规划 |
| `/multi-agent` | Skill | Stage 4: 并发执行 |

**可选依赖**（按需启用）:

| 依赖项 | 类型 | 启用条件 |
|--------|------|---------|
| `/mermaid` | Skill | `--mermaid` 或 `--deep` |
| Sequential Thinking | **MCP** (不是 Skill) | `--think` / `--think-hard` 或 `--deep` |
| `/flow-deep` | Skill | `--code-plan` (Stage 3.6 需要 flow-deep 的 code-planning.md) |

**superpowers 技能依赖**（通过参数启用）:

| 依赖项 | 触发条件 | 用于阶段 | 调用方式 |
|--------|---------|---------|---------|
| `superpowers:brainstorming` | Stage 1.5 需求探索时（可选） | Stage 1.5: 需求探索 | 参考（不强制加载） |
| `superpowers:writing-plans` | `--code-plan` | Stage 3.6: 代码级细化 | Skill tool 加载 |
| `superpowers:test-driven-development` | `--tdd` | Stage 4: TDD 注入 | Agent 内 Skill tool 加载 |
| `superpowers:dispatching-parallel-agents` | `--deep` 或自动检测 | Stage 4: 并行分发 | Agent 内 Skill tool 加载 |
| `superpowers:requesting-code-review` | `--review` | Stage 4: 代码审查 | Agent 内 Skill tool 加载 |
| `superpowers:verification-before-completion` | 默认启用 | Stage 5: 完成验证 | Skill tool 加载完整规范 |

> **调用原则**: 标注 "Skill tool 加载" 的依赖，必须在对应 Stage 开始时通过 Skill tool 加载完整技能内容，而非使用简化版指令。Agent 内加载指在 Agent prompt 中要求 Agent 自行调用 Skill tool。

**迭代增强依赖**（参数控制）:

| 依赖项 | 触发条件 | 用于阶段 |
|--------|---------|---------|
| `auto-iterate` | `--iterate N` 参数 | Stage 5.5: 自主迭代优化 |
| `superpowers:systematic-debugging` | 遇到 bug 或测试失败 | Stage 5.5: 系统化调试 |
| `ralph-loop` 插件 | `--ralph` 参数 | Stage 5.7: Ralph Loop 强制持续 |

## 核心架构

```
用户输入 (任务表述)
    │
    ▼
┌─────────────────────┐
│ Stage 1: Prompt 优化  │  --no-prompt 跳过
│   调用 /prompt 技能    │
└─────────┬───────────┘
          │ 优化后的任务表述
          ▼
┌─────────────────────┐
│ Stage 1.5: 需求探索   │  条件触发（3+ 不确定项时）
│   AskUserQuestion    │  参考 superpowers:brainstorming
└─────────┬───────────┘
          │ 明确后的任务表述
          ▼
┌─────────────────────┐
│ Stage 2: 深度思考     │  --think / --think-hard / --mermaid / --discuss
│   (可选预处理)        │  默认跳过，按需开启
└─────────┬───────────┘
          │ 深度分析结论
          ▼
┌─────────────────────┐
│ Stage 3: 确定性规划    │  --no-plan 跳过
│   EnterPlanMode(默认) │  --strict-plan 默认启用
│   + plan-quality 标准 │  --precise-plan 强制精确
│   planning-with-files │  --plan-dir 自定义目录
└─────────┬───────────┘
          │ task_plan.md / findings.md / progress.md
          ▼
┌─────────────────────┐
│ Stage 3.5: Plan Review│  --plan-review 启用（半自动）
│   独立 Agent 审查     │  --deep 时建议启用
│   (两个 Claude 模式)  │
└─────────┬───────────┘
          │ 审查报告 + 用户确认
          ▼
┌─────────────────────┐
│ Stage 3.6: 代码级细化 │  --code-plan 启用
│   superpowers:       │  需 flow-deep 依赖
│   writing-plans      │
└─────────┬───────────┘
          │ TDD 细化后的 plan
          ▼
┌─────────────────────┐
│ Stage 4: 并发执行     │  --no-multi 跳过(改为串行)
│   /multi-agent       │  含退回 Plan 协议
│   (异常→退回Stage3)  │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Stage 4.5: Agent 清理│  IN_TMUX 时执行
│   tmux + TeamDelete  │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Stage 5: 完成验证     │  --no-verify 跳过
│   verification       │  默认启用
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Stage 5.5: 迭代优化   │  --iterate N 启用
│   auto-iterate       │  验证失败时触发
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Stage 5.7: Ralph Loop│  --ralph 启用（参数触发）
│   Stop Hook 强制持续  │  Stage 5.5 用完仍未达标时
└─────────┬───────────┘
          │
          ▼
      执行结果
```

**Mermaid 输出规范**: 输出 Mermaid 代码块后，应紧接着输出 ASCII 字符画版本。

> 轻量编排引擎。如需全量深度管道（含 superpowers 前置检查 + 强制深度思考），请使用 `/flow-deep`。

## 参数速查

```
/flow [options] <任务表述>

阶段控制:                          思考增强:
  --no-prompt   跳过 Stage 1         --think         Sequential Thinking (4K)
  --no-plan     跳过 Stage 3         --think-hard    Sequential Thinking (10K)
  --no-multi    跳过 Stage 4(串行)    --mermaid       Mermaid 图可视化
                                    --discuss       三角色讨论
Plan 质量:                          superpowers 技能:
  --strict-plan  Stage 3 进入       --code-plan   Stage 3.6 代码级细化
                 Plan Mode (默认开)  --tdd         Agent 注入 TDD
  --no-strict-plan 禁用 Plan Mode   --review      代码审查
  --precise-plan 强制精确 Plan       --compact     上下文 >60% 压缩
  --plan-review  Stage 3.5 审查
                 (两个 Claude 模式)
迭代增强:                           配置:
  --iterate N     Stage 5.5 迭代     --plan-dir <dir>  规划目录（多 feature 用 .plan-feat-<name>/）
  --guard <cmd>   迭代防回归         --agents <types>  Agent 类型
  --ralph         Stage 5.7 Ralph    --lang <zh|en>    输出语言
  --ralph-max N   Ralph 轮数(默认10) --dry-run         仅计划不执行
  --no-verify     跳过 Stage 5

预设 (互斥):
  --quick     ≡ --no-prompt --no-plan --no-multi
  --standard  完整三步流程（默认）
  --deep      ≡ --think --mermaid --discuss (+ 自动建议 --plan-review) (+ superpowers: dispatching-parallel-agents)
```

## 执行流程

### 前置处理

1. **解析参数**: 从用户输入中提取 `--` 参数和任务表述
2. **能力检测**: 检查 `~/.claude/skills/auto-iterate/SKILL.md` 是否存在，标记 `iterate_available: true/false`（影响 Stage 5.5 使用完整模式还是降级模式）
3. **确认任务**: 向用户展示解析结果，确认任务范围和参数配置

```
/flow --think --plan-dir docs/plan 重构支付系统，支持多币种

解析结果:
  任务: 重构支付系统，支持多币种
  启用阶段: prompt优化 → 深度思考 → 规划 → 并发执行
  规划目录: docs/plan/
  思考模式: Sequential Thinking (4K)
```

### Stage 1: Prompt 优化

**调用**: `/prompt <任务表述>`

**输入**: 用户的原始任务表述
**输出**: 优化后的任务表述（评分报告 + 优化版本）

**行为**:
- 使用 prompt 技能对任务表述进行评分和优化
- 将优化后的版本作为后续阶段的输入
- 如果评分 >= 8/10，提示用户原始表述已足够好，询问是否跳过

**跳过条件**: `--no-prompt`

### Stage 1.5: 需求探索（条件触发）

**触发条件**: Stage 1 完成后，优化后的任务表述中存在 3+ 不确定项或明确度 < 7 的关键决策点。

> 完整协议（含触发条件、行为步骤、AskUserQuestion 示例）见 `references/needs-exploration.md`

**核心行为**: 识别不确定项 → 评分明确度 → 主动追问 → 合并结果 → 记录到 findings.md

**追问要点**: 问题要具体（"支持哪些币种？" 而非 "还有其他需求？"），每个问题提供 3-4 选项含推荐默认值。

**跳过条件**: 不确定项 < 3 或所有不确定项明确度 >= 7

### Stage 2: 深度思考（可选）

**输入**: 优化后的任务表述

根据启用的参数执行不同的预处理：

#### --think / --think-hard

调用 Sequential Thinking MCP 进行结构化思考（6 个维度：任务分解、依赖分析、风险评估、资源需求、执行策略、Superpowers 技能匹配），完成后展示结论并记录到 findings.md。详见 `references/stage2-details.md`。

**技能匹配确认钩子**（第 6 维度完成后）:
- 如果第 6 维度匹配到 2+ 个 superpowers 技能，使用 AskUserQuestion 确认匹配结果
- 问题示例: "分析匹配到以下技能: TDD + 代码审查 + 并行分发。是否全部启用，还是选择性启用？"
- 用户可调整匹配结果后再进入 Stage 3

#### --mermaid

使用 mermaid 技能可视化任务结构（任务分解图 / 依赖关系图 / 执行流程图）。因终端无法渲染图形工具，输出遵循全局 CLAUDE.md Mermaid 图表规范（Mermaid 代码块 + ASCII 字符画双输出）。详见 `references/stage2-details.md`。

#### --discuss

三角色讨论模式，根据任务类型自动匹配角色，经两轮讨论后综合形成最佳方案，结果记录到 findings.md。详见 `references/stage2-details.md`。

### Stage 3: 确定性规划

**遵循**: `planning-with-files` 模板格式 + `references/plan-quality.md` 质量标准

> 注意: `--strict-plan` 模式下，Plan Mode 内部无法调用 Skill tool，因此手动遵循 planning-with-files 的模板格式组织 plan 内容，而非调用该 skill。

#### --strict-plan 模式（默认启用）

**核心理念**: 进入 Claude Code 的 Plan Mode（只读沙箱），强制"先想后做"纪律。Plan Mode 中只能探索代码库和写 plan 文件，不能编辑代码，确保设计质量。

**启用条件**: 默认启用（`--standard` 和 `--deep` 预设自动包含）
**跳过条件**: `--quick` 预设 或 `--no-plan`

**行为**:

**[Plan Mode 内部]** — 调用 `EnterPlanMode` 进入只读沙箱:
1. 用 Glob/Grep/Read 探索代码库，理解现有结构
2. 基于优化后的表述和深度思考结论，设计实现方案
3. 将方案写入系统指定的 plan 文件（遵循 planning-with-files 模板 + plan-quality.md Checklist）

**[Plan Mode 边界]** — 调用 `ExitPlanMode` 提交 plan 供用户审批

**[Plan Mode 外部]** — 用户审批通过后:
4. 将审批通过的 plan 形式化为:
   - `task_plan.md` — 分阶段任务计划（写入 `--plan-dir` 指定目录）
   - `findings.md` — 研究发现
   - `progress.md` — 执行进度追踪
5. 对生成的 plan 执行 plan-quality.md 中的 Quality Checklist 自检
6. 向用户展示质量评分，确认后进入 Stage 3.5

**Plan Mode 的约束**（系统级强制）:
- 可以: Read、Glob、Grep、AskUserQuestion、写 plan 文件
- 不可以: Edit、Write（项目文件）、Bash、修改代码库

**为什么默认启用**:
- Plan Mode 的审批环节（ExitPlanMode）确保 plan 质量，比单纯靠"自律"更可靠
- 只读沙箱防止"边想边改"的冲动，强制先完成设计再动手
- 用户可以在审批时直接修改 plan，比事后修正成本低得多

#### 非 strict-plan 模式（--quick 时）

不进入 Plan Mode，直接用 `planning-with-files` 生成 plan 文件。适用于简单任务或已明确方案的场景。

**规划要点**（两种模式通用）:
- 每个 Phase 应标注可否并行
- Phase 间的依赖关系要明确
- 每个 Phase 要有明确的完成标准
- **确定性要求**（`--precise-plan` 或 `--deep` 时强制）:
  - 精确文件路径（创建/修改的具体文件）
  - 行号范围或函数签名
  - 变更内容描述（禁止 placeholder）
  - 验证条件（命令 + 预期输出）
  - 详见 `references/plan-quality.md`

**质量评分**: 生成 plan 后按 plan-quality.md 的评分标准自检，>= 8/10 合格

**跳过条件**: `--no-plan`

### Stage 3.5: Plan Review — 两个 Claude 审查模式（可选）

**触发条件**: `--plan-review` 参数启用，或 `--deep` 时自动建议
**参考文档**: `references/plan-review.md`

**核心理念**: 用独立 Agent（全新上下文）审查 plan，消除"沉没成本偏差"——第一个 Claude 花了很多时间想方案，心理上不愿推翻，而审查 Agent 没有这个包袱。

**行为**（半自动模式）:
1. 读取 Stage 3 生成的 task_plan.md 全部内容
2. 启动一个独立 Agent（subagent_type: general-purpose, name: plan-reviewer）
3. Agent 以 Staff Engineer 角色审查 6 个维度:
   - 架构合理性 / 遗漏边界情况 / 安全风险 / 性能影响 / Plan 假设验证 / 可执行性
4. Agent 返回审查报告（APPROVED / APPROVED_WITH_NOTES / NEEDS_REVISION）
5. **暂停，向用户展示审查报告** ← 半自动: 等待用户确认
6. 用户决策:
   - APPROVED → 继续 Stage 3.6
   - APPROVED_WITH_NOTES → 选择性采纳建议，更新 plan 后继续
   - NEEDS_REVISION → 退回 Stage 3 修改 plan
7. 审查结果写入 findings.md 的 Plan Review 章节

**自动建议条件**（不自动执行，仅提示用户）:
- 改动影响 3+ 模块
- 涉及技术选型
- 有安全/数据风险
- plan 包含 5+ Phase

**跳过条件**: 不使用 `--plan-review` 参数且未接受建议

### Stage 3.6: 代码级细化（可选）

**触发条件**: `--code-plan` 参数启用时
**调用**: `superpowers:writing-plans`
**依赖声明**: 读取 `~/.claude/skills/flow-deep/references/code-planning.md`（agent_hint 格式、TDD 步骤模板）。需要用户已安装 `/flow-deep` skill，否则该功能不可用，应提示用户安装 flow-deep 后重试。

**行为**: 对每个含代码实现的 Phase 细化为 TDD 步骤（每步 2-5 分钟，含完整代码，无 placeholder）

**默认**: 跳过。仅 `--code-plan` 时启用。

### Stage 4: 并发执行

**调用**: `/multi-agent` 技能（可选注入 superpowers 技能指令）

**行为**:
1. 读取 task_plan.md 中的任务分解
2. 识别可并行的子任务组
3. 为每个子任务分配合适的 Agent 类型
4. **按需注入技能指令**（详细指令见 `references/skill-routing.md`）:
   - `--tdd`: 代码实现 Agent 注入 TDD 工作流
   - `--review`: 代码实现完成后触发审查
   - `--deep`: 启用 `dispatching-parallel-agents` 并行分发
5. 生成可执行的 Agent Teams 方案
6. 并发启动 Agent 执行

#### Agent 分发方式（tmux 分屏优先，全阶段通用）

> 完整规则（含 CRITICAL 检查清单、工具调用模板、Delegate 模式）见 `references/agent-dispatch.md`

核心约束: tmux-split 唯一模式 → TeamCreate + team_name → 禁止 run_in_background → 完成后即时清理

**串行替代**: 当 `--no-multi` 时，在当前会话中按 task_plan.md 顺序逐步执行，每完成一个 Phase 更新 progress.md。

#### 退回 Plan 协议（Stage 4 异常处理）

**核心理念**: 执行中遇到意外时，第一反应是"plan 哪里假设错了"，而不是"让我直接修"。

> 完整协议（含异常分类、Fallback 操作步骤、特殊情况处理）见 `references/fallback-protocol.md`

**关键规则**: 执行偏差 → 直接修复 | Plan 假设有误 → 触发 Plan Fallback（暂停→记录→分析→更新→确认→继续）| 同一 Phase 2 次 Fallback → 退回 Stage 2

**跳过条件**: `--no-multi`

### Stage 4.5: Agent 与 Pane 清理

> 完整清理脚本（即时清理 + 孤儿清理 + 全局清理）见 `references/cleanup-procedure.md`

Stage 4 完成后执行三层清理: 即时清理（Agent completed → shutdown → kill pane）→ 孤儿清理（残留 pane）→ 全局清理（倒序 kill + TeamDelete）

### Stage 5: 完成验证

**调用**: `superpowers:verification-before-completion`（通过 Skill tool 加载完整技能）

> 完整验证协议（含行为步骤、铁律、证据要求）见 `references/stage5-verification.md`

**铁律**: No completion claims without fresh verification evidence. 禁止 "should work"、"probably"。

**跳过条件**: `--no-verify`

### Stage 5.5: 迭代优化（条件触发）

**触发条件**（满足任一即触发）: `--iterate N` 参数 或 Stage 5 验证未达标（自动触发，默认 3 轮）

> 完整协议（含参数构造、渐进式 Guard、auto-iterate 集成、降级模式）见 `references/stage55-iteration.md`

**调用**: `auto-iterate` skill（如果可用）；否则使用内置降级模式（分析→变更→commit→验证→keep/revert）

**跳过条件**: 不使用 `--iterate` 参数且 Stage 5 全部达标

### Stage 5.7: Ralph Loop 强制持续（参数触发）

**触发条件**: `--ralph` 参数启用 + Stage 5.5 迭代用完仍未达标 + Ralph Loop 插件已安装
**调用**: Ralph Loop 插件（Stop Hook 机制）
**参考**: `~/.claude/skills/flow-deep/references/ralph-integration.md`

**核心理念**: Ralph Loop 通过 Stop Hook 拦截会话退出，注入一次性固定 prompt（含初始历史摘要 + 自主状态获取指令），在 auto-iterate 外层包裹"不达目的不罢休"的强制机制。

**行为**:
1. 检查 Ralph Loop 插件是否已安装（前置处理中已标记）
2. 不可用 → 提示用户安装 Ralph Loop 插件
3. 可用 → 构造一次性 prompt（含初始 TSV 历史 + "自行从 progress.md 读取最新状态"指令）
4. 调用 `/ralph-loop` 启动循环，使用 `--completion-promise "FLOW_COMPLETE"`
5. LLM 每轮自行读取 progress.md 获取最新迭代状态，执行 auto-iterate，运行 Stage 5 验证
6. 达标输出 `<promise>` 或到达 `--ralph-max` → 退出循环

**参数**:
- `--ralph`: 启用 Ralph Loop（flow 中为参数触发，非自动触发）
- `--ralph-max N`: Ralph 总轮数（默认 10）
- `--no-ralph`: 禁用（仅在与其他参数组合时有用）

**跳过条件**: 未使用 `--ralph` | Stage 5.5 全部达标 | Ralph Loop 插件未安装

1. **tmux 全局清理**（IN_TMUX 时）: shutdown 全部剩余 Agent → 倒序 kill 非 MAIN_PANE → TeamDelete
2. 汇总所有 Agent 的执行结果
3. 更新 progress.md 和 task_plan.md 状态
4. 向用户展示最终结果和总结
5. 如有未完成的任务，提示后续步骤
6. **触发 Stage 5 完成验证**（若 Stage 5 未执行则在此触发；`--no-verify` 可跳过）

## 使用示例

> 详细示例（标准流程 / 深度分析 / Plan Review 场景 / 常用参数组合）见 `references/usage-examples.md`

**快速参考**:
```
/flow --think --mermaid --plan-dir docs/plan 重构支付系统
→ Stage 1: 优化 → Stage 2: 思考+Mermaid → Stage 3: 规划 → Stage 4: 并发执行
```

### 通用参数行为

- **`--compact`**: 当上下文使用率 >60% 时，自动压缩中间结果（Sequential Thinking 输出摘要化、代码级计划保留 agent_hint 摘要）
- **`--agents <types>`**: 指定 Agent 类型（逗号分隔），覆盖 Stage 4 自动匹配的 subagent 类型。例如 `--agents backend-developer,security-auditor`
- **`--lang <zh|en>`**: 设置所有用户面向消息的输出语言。默认 `zh`
- **`--dry-run`**: 执行 Stage 1-3 后停止，不进入 Stage 4/5。用于预览计划输出
- **`--no-strict-plan`**: Stage 3 不进入 Plan Mode，直接用 planning-with-files 生成 plan（适用于简单任务或已明确方案的场景）

## 注意事项

- 每个阶段完成后，向用户展示简报并确认是否继续
- 如果某个阶段失败，不要自动跳过，而是报告错误并询问用户
- 三角色讨论中的角色选择应基于任务类型自动匹配，但允许用户调整
- Mermaid 图应聚焦于任务结构和依赖关系，不要过度美化
- 规划文件应使用 planning-with-files 的模板格式，保持兼容性
- **Plan 质量**: Stage 3 生成的 plan 应满足 `references/plan-quality.md` 的 Checklist，特别是 `--precise-plan` 或 `--deep` 时
- **退回 Plan 纪律**: Stage 4 中遇到 Plan 假设有误时，不要"硬推"就地修复，而应触发 Fallback 协议（详见 `references/fallback-protocol.md`）
- **Plan Review 半自动**: 审查 Agent 只输出报告，不自动修改 plan。用户确认后才继续