---
name: auto-flow
description: >
  自动模式全流程入口。跳过所有中间阶段确认，仅在最终验收时停止。
  所有 11 个阶段完整执行，只是不等待用户逐阶段确认。
  简化版：无 Agent 视角、无共识表、无质量门、无置信度、无反思点。
tools:
  - Bash
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Agent
---

# auto-flow

自动模式 L3 全流程。跳过中间确认，仅验收时停止。简化版执行。

## ⛔ 执行协议

> **以下规则不可违反。违反任何一条即为流程失败。**

### 规则 1: 必须通过 MCP 工具启动

**不得自行编排流程。必须调用 `reqflow_full_flow` 并传入 `auto_pilot=true` 启动。**

```
reqflow_full_flow(requirement="<需求描述>", auto_pilot=true)
```

**即使需求很小，也必须通过 MCP 启动并执行完整 L3 流程。不得因需求简单而缩减阶段。**

### 规则 2: 必须读取 Execution Skill

启动后**必须读取生成的 Execution Skill**，确认头部包含 `auto_pilot: true`。**不得修改 Execution Skill 本身。**

### 规则 3: 所有阶段完整执行，中间不确认

每个阶段仍需执行完整动作序列（自检 → 问题发现 → 对话展示 → reqflow_report），但**不等待用户确认**，直接进入下一阶段。

### 规则 4: 不得跳过任何阶段

11 个阶段必须全部执行。**不得提前结束，不得跳过中间阶段，不得因需求简单而缩减阶段。**

### 规则 5: P0 阻塞时必须停止

即使在自动模式下，遇到以下情况必须停止等待用户决策：
- 有 P0 级 BLOCKER
- spec delta 变更持久行为
- 场景检测有歧义
- 关键模块完成（数据库 schema、核心业务逻辑、安全代码、多服务接口）

### 规则 6: 必须等待用户验收

所有阶段完成后必须停止，等待用户调用 `reqflow_accept` 或 `reqflow_reject`。**不得自行调用 `reqflow_accept`。**

---

## ⛔ MCP 即时输出规则

每次调用 MCP 工具后，必须立即在对话中输出：

1. **工具名 + 输入参数摘要**（一行，📡 前缀）
2. **返回结果摘要**（一行，用 ✅/❌ 标记）
3. **失败时输出失败原因和修复计划**

格式：
```
📡 reqflow_report(stage="PRD理解") → ✅ 已记录 (阶段 2/11, 18%)
📡 reqflow_verify(gate="tdd-gate") → ❌ 未通过: failing_tests_count 缺失
🔧 修复计划: 编写失败测试后重新提交
```

⛔ **禁止静默调用 MCP 工具不输出。**

---

## ⛔ Agent 真实派遣规则

**核心原则：多 Agent 协作必须真实派遣独立执行单元，不得自己扮演多个角色。**

### 平台检测与适配

执行前必须检测当前平台的多 Agent 能力，按以下优先级使用：

| 平台 | 派遣方式 | 并行 | 说明 |
|------|----------|------|------|
| Claude Code | Agent tool (subagent) | ✅ | `.claude/agents/` 定义，同一消息多 Agent tool call 并行；实验性 Agent Teams 支持多实例协作 |
| Codex | Subagent workflows | ✅ | `.codex/agents/` TOML 定义，默认 max_threads=6，内置 default/worker/explorer，`/agent` 管理线程 |
| Cursor | Cloud agents | ✅ | Agents Window 管理，支持 fleets of parallelized agents，Jira 集成触发，automations 定时触发 |
| GitHub Copilot | Coding Agent | 有限 | VS Code agent mode + 自主 PR 创建，CLI 层面无 subagent |
| Gemini CLI | **无 subagent** | ❌ | 单 agent + MCP 工具扩展，无多 agent 能力 |
| 其他平台 | 检测可用能力 | ? | 有 subagent 就用，没有则记录限制 |

**检测规则：**
1. 检查当前工具是否支持 subagent / 子 agent / 多 agent 派遣
2. 如果支持 → **必须使用真实派遣**，不得跳过
3. 如果不支持（如 Gemini CLI）→ 记录 `[限制] 当前平台不支持多 Agent 派遣，使用单 Agent 顺序执行`，在对话中明确告知用户

### 派遣规范

- 同一阶段的 agents 必须**并行派遣**（平台支持时）或**顺序派遣**（平台不支持并行时）
- 每个 agent 的 prompt 必须包含：**角色定义、任务描述、上下文、输出格式**
- 主 agent 不得"代替"任何子 agent 回答
- 子 agent 超时或失败时，按降级策略处理
- **无论使用何种平台，都不得跳过多 Agent 协作步骤 — 即使需要手动顺序执行每个角色的分析，也必须分别输出各角色的独立结论**

---

## ⛔ 阶段报告结构

每个阶段完成后必须在对话中输出报告：

```
### 📋 阶段报告：{stage_name}

**状态:** ✅ 完成 | ⚠️ 有警告 | ❌ 失败

#### 产出清单
| 文件 | 操作 | 存在 | 状态 |
|------|------|------|------|
| xxx.java | 新增 | ✅ | 通过 |
产物完整性: 1/1 通过

#### MCP 执行追踪
| 工具 | 参数 | 结果 |
|------|------|------|
| reqflow_report | stage="PRD理解" | ✅ |

#### 问题与风险
- [自修复] xxx
- [需确认] xxx

#### 下一步
...
```

---

## 产物验证

每个修改文件的阶段结束后，必须验证产物：
- 检查文件是否存在
- 输出产物验证表：
  ```
  #### 产物验证
  | 文件 | 操作 | 存在 | 状态 |
  |------|------|------|------|
  | PlaceholderController.java | 修改 | ✅ | 通过 |
  产物完整性: 1/1 通过
  ```

---

## ⛔ 验收决策面板

所有阶段完成后必须展示完整验收决策面板：

```
### 🏁 验收决策面板

**当前状态:** 全部阶段完成（自动模式），等待你的验收决定。

#### 已交付产物清单
| 文件 | 变更类型 | 验证状态 |
|------|----------|----------|
| xxx.java | 新增 | 编译通过 |

#### 质量摘要
- 门禁通过: X/X
- P0 阻塞: 0
- 验收标准: X/X verified

#### 请做出决定
| 选项 | 操作 | 后续流程 |
|------|------|----------|
| ✅ 通过验收 | reqflow_accept | 归档、清理、流程结束 |
| ❌ 拒绝验收 | reqflow_reject | 修复循环（最多 3 轮） |
| 🔧 部分验收 | reqflow_accept + scope | 部分归档 |
| ⏸ 暂挂 | 不调用工具 | 保持状态 |
```

---

## 触发方式

**Slash 命令：**
```
/reqflow:auto-flow <需求描述>
```

**自然语言：**
- "自动跑完全流程：<需求>"
- "全自动执行这个需求"
- "auto pilot 执行：<需求>"

**MCP 直接调用：**
```
reqflow_full_flow(requirement="<需求描述>", auto_pilot=true)
```

---

## 执行流程

### 步骤 1: 启动自动模式

```
reqflow_full_flow(requirement="<需求描述>", auto_pilot=true)
```

返回值包含：
- `run_id` — 运行 ID
- `exec_skill_path` — Execution Skill 文件路径
- `auto_pilot: true` — 确认自动模式
- `mode` — 模式说明

### 步骤 2: 读取 Execution Skill

读取 exec_skill_path，确认头部 `auto_pilot: true`。

### 步骤 3: 逐阶段自动执行

按 Execution Skill 定义的阶段顺序执行。每个阶段：

```
┌─────────────────────────────────────────────────────────────┐
│  ① 执行阶段任务                                              │
│     ↓                                                       │
│  ② 自检（产出完整性、一致性、遗漏）                           │
│     ↓                                                       │
│  ③ 问题发现（主动识别问题，小问题自行修复）                    │
│     ↓                                                       │
│  ④ 产物验证（文件存在性检查）                                 │
│     ↓                                                       │
│  ⑤ 在对话中展示产出摘要（不是只写文件）                       │
│     ↓                                                       │
│  ⑥ 调用 reqflow_report 报告阶段状态                          │
│     ↓                                                       │
│  ⑦ 自动进入下一阶段（不等待用户确认）                         │
└─────────────────────────────────────────────────────────────┘
```

**例外：有 P0 阻塞时在 ⑥ 之后停止，等待用户决策。**

### 步骤 4: 验收（必须停止）

所有阶段完成后：

```
1. 在对话中汇总所有已完成阶段和产出物
2. 展示验收决策面板（4 选项）
3. ⛔ 停止，等待用户决定
```

- 用户通过: `reqflow_accept(run_id="...")`
- 用户拒绝: `reqflow_reject(run_id="...", reason="...")` → 修复循环

---

## 与标准模式的区别

| 维度 | 标准模式 (/reqflow:main-flow) | 自动模式 (/reqflow:auto-flow) |
|------|-------------------------------|-------------------------------|
| 阶段执行 | 全部 11 阶段 | 全部 11 阶段 |
| 多 Agent 协作 | 有 | 无（跳过） |
| 共识表 | 有 | 无（跳过） |
| 置信度评估 | 有 | 无（跳过） |
| 中间确认 | ⛔ 每阶段停止等待确认 | 自动继续 |
| P0 阻塞 | 停止 | 停止 |
| 关键模块 | 停止 | 停止 |
| 验收 | ⛔ 停止 | ⛔ 停止 |
| 适用场景 | 需要逐步确认的复杂需求 | 简单需求或信任 Agent 能力时 |

---

## 禁止事项

- **不得自行编排流程 — 必须通过 reqflow_full_flow(auto_pilot=true) 启动**
- **不得因需求简单而缩减阶段 — 必须执行全部 11 阶段**
- **不得跳过任何阶段**
- **不得跳过自检和问题发现**
- **不得跳过产物验证**
- **不得跳过在对话中展示摘要**
- **不得跳过 reqflow_report 调用**
- **不得在有 P0 阻塞时继续执行**
- **不得自行调用 reqflow_accept**
- **不得在未收到用户验收决定前结束会话**
- **不得静默调用 MCP 工具 — 每次调用后必须输出 📡 即时反馈**
- **技术方案不得只给一个方案 — 必须对比 2-3 个候选方案**

## 沟通语言

始终使用中文与用户沟通。技术术语和代码标识符保持原样。