---
name: ai-dev-team
description: Use when user mentions "完整开发流程", "从需求到交付", "端到端开发", "ai-dev-team", "五阶段流水线", "快速开发", "全流程", "全套流程", "正规流程", "按规范来", "好好做", "认真做", "完整做一遍", "开发一个", "做个", "写一个", "实现一个", "帮我做", "帮我开发", "帮我写", or needs full-stack development orchestration from requirements to delivery. Triggers on end-to-end feature development, multi-phase project planning, or when user wants AI to manage the complete development lifecycle. Also triggers on casual development requests like "做个XX功能", "写个XX系统" when the task is non-trivial.
---

# AI Dev Team - 五阶段流水线编排

## Overview
自动编排 **OpenSpec + Superpowers + OMO 多智能体** 的五阶段开发流水线。从需求澄清到质量交付，AI 作为项目经理调度各组件协同工作。

**核心原则**：
- 按阶段推进，产出驱动流转
- 复杂度自适应：小功能跳过冗余阶段
- 每个阶段明确：输入 → 处理 → 输出

## 触发条件

| 触发词 | 模式 |
|--------|------|
| 完整开发流程、从需求到交付、端到端开发 | 完整五阶段 |
| ai-dev-team、五阶段流水线 | 完整五阶段 |
| 快速开发、快速实现 | 快捷模式（跳过 Phase 1） |

## 五阶段流水线

```dot
digraph pipeline {
    rankdir=LR;
    node [shape=box, style=rounded];
    
    P1 [label="Phase 1\n需求澄清", fillcolor="#e1f5fe", style="filled"];
    P2 [label="Phase 2\n技术设计", fillcolor="#f3e5f5", style="filled"];
    P3 [label="Phase 3\n任务编排", fillcolor="#fff3e0", style="filled"];
    P4 [label="Phase 4\n并行开发", fillcolor="#e8f5e9", style="filled"];
    P5 [label="Phase 5\n质量交付", fillcolor="#fce4ec", style="filled"];
    
    P1 -> P2 [label="需求文档"];
    P2 -> P3 [label="设计+计划"];
    P3 -> P4 [label="任务分配"];
    P4 -> P5 [label="代码+测试"];
    
    FAST [label="快捷模式\n跳过 Phase 1", shape=diamond, fillcolor="#fff9c4", style="filled"];
    FAST -> P2 [label="直接进入", style=dashed];
}
```

### Phase 1: 需求澄清

**输入**：用户的原始需求描述
**输出**：结构化的需求文档（OpenSpec proposal）

| 步骤 | 操作 | 调用 |
|------|------|------|
| 1.1 | 理解用户意图，识别模糊点 | 自主分析 |
| 1.2 | 与用户确认需求边界、验收标准 | 对话交互 |
| 1.3 | 调用 brainstorming 探索边界情况 | `skill("brainstorming")` |
| 1.4 | 生成 OpenSpec proposal | `/opsx:propose` 或手动创建 `openspec/changes/<name>/proposal.md` |

**产出文档**：
- `openspec/changes/<name>/proposal.md` - 需求提案
- 包含：问题描述、用户故事、验收标准、边界情况

**跳过条件**：
- 需求已非常明确（用户已提供详细规格）
- 快捷模式触发

---

### Phase 2: 技术设计

**输入**：Phase 1 产出的需求文档
**输出**：技术设计文档 + 任务拆解清单

| 步骤 | 操作 | 调用 |
|------|------|------|
| 2.1 | 基于 proposal 设计技术方案 | 创建 `openspec/changes/<name>/design.md` |
| 2.2 | 明确架构决策、技术选型、接口定义 | design.md 内容 |
| 2.3 | 使用 writing-plans 拆解为可执行任务 | `skill("writing-plans")` |
| 2.4 | 产出任务清单（含依赖关系、优先级） | 计划文档 |

**产出文档**：
- `openspec/changes/<name>/design.md` - 技术设计
- 任务拆解清单（含：任务描述、文件范围、依赖、预估复杂度）

**依赖**：Phase 1 的 proposal.md（或用户已提供的明确需求）

---

### Phase 3: 任务编排

**输入**：Phase 2 产出的任务清单
**输出**：并行任务分配 + 隔离工作区

| 步骤 | 操作 | 调用 |
|------|------|------|
| 3.1 | 识别可并行化的独立任务 | 依赖分析 |
| 3.2 | 为每个独立任务创建 git worktree | `skill("using-git-worktrees")` |
| 3.3 | 使用 OMO 分发子 Agent 执行 | `call_omo_agent()` 或 `task()` |
| 3.4 | 建立审查检查点 | 记录每个任务的验收标准 |

**产出**：
- 多个 git worktree（每个任务隔离）
- 子 Agent 分配映射表
- 审查检查点清单

**依赖**：Phase 2 的任务拆解清单

---

### Phase 4: 并行开发

**输入**：Phase 3 分配的任务 + 隔离工作区
**输出**：功能代码 + 测试用例

| 步骤 | 操作 | 调用 |
|------|------|------|
| 4.1 | 每个子 Agent 按 TDD 纪律开发 | `skill("test-driven-development")` |
| 4.2 | 独立任务并行执行 | `skill("subagent-driven-development")` |
| 4.3 | 完成后标记任务状态 | 更新任务清单 |
| 4.4 | 所有任务完成后合并 | 等待全部完成 |

**产出**：
- 功能代码（各 worktree 中）
- 对应的测试用例
- 更新的任务状态清单

**依赖**：Phase 3 的工作区 + 任务分配

---

### Phase 5: 质量交付

**输入**：Phase 4 产出的代码 + 测试
**输出**：通过审查的代码 + 交付总结

| 步骤 | 操作 | 调用 |
|------|------|------|
| 5.1 | 代码审查（功能正确性 + 代码质量） | `skill("requesting-code-review")` |
| 5.2 | 验证所有验收标准已满足 | `skill("verification-before-completion")` |
| 5.3 | 合并 worktree 到主分支 | git merge / PR |
| 5.4 | 完成分支清理或 PR 创建 | `skill("finishing-a-development-branch")` |
| 5.5 | 归档 OpenSpec change | `/opsx:archive` |

**产出**：
- 合并到主分支的代码
- 审查报告
- 交付总结（完成了什么、如何验证）

**依赖**：Phase 4 的所有任务完成

---

## 快捷模式

当用户说 **"快速开发"**、**"快速实现"**、**"直接做"** 时：

```
跳过 Phase 1 → 从 Phase 2 开始
```

**适用场景**：
- 需求已明确（用户提供了详细规格）
- 小型功能/修复（< 2 小时工作量）
- 用户明确要求跳过讨论

**快捷模式流程**：
1. 快速确认需求理解（1-2 句话）
2. 直接进入 Phase 2 技术设计
3. 后续阶段正常执行

---

## 复杂度自适应

AI 根据任务复杂度自动调整阶段深度：

| 复杂度 | Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 |
|--------|---------|---------|---------|---------|---------|
| 🟢 简单（单文件修改） | 跳过 | 简化 | 跳过 | 直接开发 | 简化验证 |
| 🟡 中等（多文件/单功能） | 快速 | 标准 | 简化 | 顺序开发 | 标准审查 |
| 🔴 复杂（多模块/新功能） | 完整 | 完整 | 完整 | 并行开发 | 完整审查 |

**判断标准**：
- 🟢 简单：修改 < 3 个文件，逻辑明确，无架构影响
- 🟡 中等：修改 3-10 个文件，涉及接口变更，需要设计
- 🔴 复杂：新增模块、跨服务调用、架构级变更

---

## 执行命令参考

| 阶段 | 关键命令/技能 |
|------|--------------|
| Phase 1 | `skill("brainstorming")`, `/opsx:propose` |
| Phase 2 | `skill("writing-plans")`, 创建 design.md |
| Phase 3 | `skill("using-git-worktrees")`, `call_omo_agent()` |
| Phase 4 | `skill("subagent-driven-development")`, `skill("test-driven-development")` |
| Phase 5 | `skill("requesting-code-review")`, `skill("verification-before-completion")`, `skill("finishing-a-development-branch")`, `/opsx:archive` |

---

## 常见错误

| 错误 | 修正 |
|------|------|
| 跳过需求确认导致理解偏差 | Phase 1 至少用 1-2 句话确认需求边界 |
| 任务拆分过粗导致并行冲突 | Phase 2 确保任务间无共享文件修改 |
| worktree 创建失败时继续 | 检查 git 状态，fallback 到分支模式 |
| 审查流于形式 | Phase 5 必须运行实际验证命令，不只是看代码 |
| 小功能也走完整流程 | 使用复杂度自适应表，简单任务简化流程 |

---

## 依赖关系总结

```
Phase 1 (proposal.md)
    ↓
Phase 2 (design.md + 任务清单)
    ↓
Phase 3 (worktrees + Agent 分配)
    ↓
Phase 4 (代码 + 测试)
    ↓
Phase 5 (审查 + 合并 + 归档)
```

**关键规则**：
- 下游阶段依赖上游产出物，不可跳跃（快捷模式除外）
- 每个阶段完成后，向用户简报进度
- 遇到阻塞时暂停流水线，先解决问题