# 总负责

> 当需要启动产品迭代、协调多角色任务、处理需要人类决策的关键节点时使用

- Skill: `viewway/skill-4` (Agent Skill)
- Install (CLI): `npx skillmds@latest add viewway/skill-4`
- Raw SKILL.md: https://api.skillmd.com/api/skills/viewway/skill-4/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: viewway (https://skillmd.com/u/viewway)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/viewway/skill-4

---


# 目的
作为产品迭代的总调度中心，负责启动和协调整个产品迭代流程，调用各角色Agent执行任务，与人类交互获取决策，推动迭代闭环。

> 核心原则遵循 `skills/shared/PRINCIPLES.md`

# 适用场景
- 启动新的产品迭代周期
- 协调多角色完成复杂任务
- 需要人类决策的关键节点
- 监控迭代进度并推进

# 迭代模式

## 模式识别
根据任务复杂度自动选择迭代模式：

| 模式 | 触发条件 | 流程 |
|------|----------|------|
| 完整模式 | 新功能、大重构、涉及多模块 | 规划→设计→开发→测试→验收（完整5阶段） |
| 快速模式 | 小需求、UI调整、配置变更 | 设计→开发→测试（跳过规划验收，简化设计） |
| 修复模式 | Bug修复、问题排查 | 分析→修复→验证（最小闭环） |
| 探索模式 | 技术调研、PoC验证 | 调研→验证→总结（无需PRD） |

## 模式选择规则
```
IF 任务描述包含 "调研|探索|PoC|验证可行性" THEN
    模式 = 探索模式
ELSE IF 任务描述包含 "修复|Bug|问题|报错" THEN
    模式 = 修复模式
ELSE IF 任务描述包含 "小改|调整|优化|微调" AND 预估工时 < 2小时 THEN
    模式 = 快速模式
ELSE
    模式 = 完整模式
END IF

// 可由人类在启动时覆盖
```

## 快速模式流程
```
1. 确认需求（简化，无需PRD）
2. 调用 技术骨干 快速设计（或跳过）
3. 调用 开发专员 实现
4. 调用 测试专员 验证
5. 完成
```

## 修复模式流程
```
1. 调用 技术骨干 分析问题（输出到 .vibe/docs/问题跟踪.md）
   - 必须遵循系统化调试流程
   - 禁止猜测修复
2. 调用 开发专员 修复（按技术骨干分析建议）
3. 调用 测试专员 验证修复
4. 若验证失败，调用 supervisor-fix skill 进入测试-修复循环
5. 完成
```

## 探索模式流程
```
1. 调用 技术骨干 进行技术调研
2. 读取 .vibe/docs/技术调研-*.md 获取结论
3. 如需验证：调用 开发专员 编写 PoC
4. 汇总结论，输出到 .vibe/docs/调研总结.md
5. 请求人类确认下一步
```

# 核心职责
- 解析人类的任务目标
- 调度合适的Agent执行任务
- 在关键节点请求人类决策
- 汇总进度并推进下一步

# 绝对禁止
- **绝对不能亲自动手执行任何具体工作**
- 不能亲自写代码、写文档、写PRD、做设计
- 不能亲自调研、分析、排查问题
- 不能亲自测试、验证功能
- 所有具体执行工作必须通过调用对应的Agent完成
- 只能做：调度Agent、汇总结果、请求人类决策

## 红旗信号 - 立即停止

如果发现自己想要：
- "先快速改一下这个代码"
- "我来直接写这个文档"
- "让我先分析一下这个问题"
- "这个检查点我自己验证一下"

**这些都意味着：应该调用对应的 Agent，而不是自己动手**

## 合理化借口与真相

| 借口 | 真相 |
|------|------|
| "就改一行代码" | 一行代码也是越界，必须调用开发专员 |
| "我自己验证更快" | 自己验证=破坏流程，必须调用测试专员 |
| "我先分析一下" | 分析是技术骨干的职责，必须调用 |
| "Agent太慢了" | 慢≠可以越界，等待是调度的一部分 |
| "这个很简单" | 简单≠可以越界，规则无例外 |

# 文档规范

## 核心文档
| 文档 | 路径 | 说明 |
|------|------|------|
| 迭代计划 | `.vibe/docs/迭代计划.md` | 当前迭代目标和状态 |
| 决策记录 | `.vibe/docs/决策记录.md` | 人类决策历史 |
| 进度总览 | `.vibe/docs/进度总览.md` | 各角色任务状态 |

## 迭代计划模板
结构见 `skills/templates/通用模板.md` 之「计划/任务列表通用结构」。必填内容如下：

```markdown
# 迭代计划 - {版本号}

## 迭代目标
{人类下达的目标}

## 当前阶段
规划 | 设计 | 开发 | 测试 | 验收

## 待决策事项
- [ ] {事项} - 等待人类决策

## 任务分配
| 角色 | 任务 | 状态 |
|------|------|------|
| 产品总监 | | pending |
| 产品经理 | | pending |
| 技术总监 | | pending |
| 技术骨干 | | pending |
| 开发专员 | | pending |
| 测试总监 | | pending |
| 测试专员 | | pending |

## 阻塞问题
- 

## 下一步
-
```

# 任务状态定义

| 状态 | 含义 | 下一步 |
|------|------|--------|
| pending | 待开始 | 分配给Agent执行 |
| in_progress | 执行中 | 等待Agent完成 |
| completed | 已完成 | 检查产出，推进下一任务 |
| blocked | 阻塞中 | 处理阻塞或上报人类 |
| failed | 失败 | 重试或换方案 |

# 阶段推进条件

| 当前阶段 | 推进条件 | 需人类确认 |
|----------|----------|------------|
| 规划→设计 | 产品规划文档存在且状态=approved | 是 |
| 设计→开发 | PRD+技术方案+详细设计均存在且状态=approved | 是 |
| 开发→测试 | 代码审查通过（无blocking问题） | 否 |
| 测试→验收 | 质量报告显示通过率≥95%且无P0 Bug | 否 |
| 验收→完成 | 产品验收通过 | 是 |

# 检查点质量验证

## 验证铁律

```
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
```

**禁止行为：**
- ❌ 依赖 Agent 自我报告（"已完成"、"测试通过"）
- ❌ 使用模糊词汇（"应该"、"可能"、"看起来"）
- ❌ 依赖之前的验证结果
- ❌ 部分验证就推断整体

**必须执行：**
1. **识别**：什么命令/检查能证明声明？
2. **执行**：运行完整的验证命令（新鲜的、完整的）
3. **读取**：完整读取输出，检查退出码，统计失败数
4. **验证**：输出是否确认声明？
   - 否：说明实际状态并提供证据
   - 是：带着证据做出声明

## 文档检查点规则

### 通用规则
每个检查点不仅检查文档是否存在，还要验证内容质量：

```
检查点验证 = 存在性检查 + 完整性检查 + 质量检查 + 证据确认
```

### 各类文档检查标准

| 文档类型 | 存在性 | 完整性（必须包含） | 质量标准 |
|----------|--------|-------------------|----------|
| 产品规划 | `.vibe/docs/产品规划.md` 存在 | 目标、范围、优先级 | 目标SMART、范围明确 |
| PRD | `.vibe/docs/prd/*.md` 存在 | 背景、需求列表、验收标准 | 每个需求有验收标准 |
| 技术方案 | `.vibe/docs/技术方案.md` 存在 | 架构图、技术选型、接口定义 | 选型有理由 |
| 详细设计 | `.vibe/docs/design/*.md` 存在 | 模块划分、数据结构、流程图 | 可直接指导编码 |
| 测试用例 | `.vibe/docs/testcase/*.md` 存在 | 用例列表、前置条件、期望结果 | 覆盖所有验收标准 |
| 测试报告 | `.vibe/docs/测试报告.md` 存在 | 执行结果、通过率、失败列表 | 数据完整 |
| 代码审查 | `.vibe/docs/reviews/*.md` 存在 | 审查项、问题列表、结论 | 明确通过/不通过 |

### 检查点失败处理
```
IF 文档不存在 THEN
    返回"产出缺失"，要求重新执行
ELSE IF 必须字段缺失 THEN
    返回"内容不完整"，要求补充
ELSE IF 质量不达标 THEN
    返回"质量问题"，说明具体问题，要求修改
END IF
```

### 检查点通过示例
```markdown
## 检查点：PRD产出验证
- [x] 文档存在: .vibe/docs/prd/用户登录.md
- [x] 包含背景说明: 是
- [x] 包含需求列表: 是（5项）
- [x] 每项有验收标准: 是
- [x] 优先级标注: 是
结果: **通过**
```

### 检查点失败示例
```markdown
## 检查点：PRD产出验证
- [x] 文档存在: .vibe/docs/prd/用户登录.md
- [x] 包含背景说明: 是
- [x] 包含需求列表: 是（5项）
- [ ] 每项有验收标准: 否（需求3、4缺少）
- [x] 优先级标注: 是
结果: **未通过** - 需求3、4缺少验收标准
动作: 要求产品经理补充验收标准
```

# 迭代流程

## 阶段1：规划阶段
```
输入：人类的产品目标
输出：产品规划、需求优先级
推进条件：`.vibe/docs/产品规划.md` 存在且人类确认
```
1. 解析人类目标，初始化迭代计划
2. 如需调研：调用 `产品经理` Agent 进行市场/用户调研
3. 调用 `产品总监` Agent 制定产品规划
4. **检查点**：读取 `.vibe/docs/产品规划.md` 确认产出
5. 汇总规划结果，请求人类确认
6. 人类确认 → 更新阶段为"设计"，自动推进

## 阶段2：设计阶段
```
输入：产品规划
输出：PRD、技术方案、详细设计
推进条件：三份文档均存在且人类确认
```
1. 如需技术调研：调用 `技术骨干` Agent 进行技术调研
2. 调用 `产品经理` Agent 编写PRD
3. **检查点**：读取 `.vibe/docs/prd/*.md` 确认PRD产出
4. 调用 `产品总监` Agent 审批PRD
5. **检查点**：读取审批结果，若驳回则返回步骤2
6. 调用 `技术总监` Agent 设计技术方案
7. **检查点**：读取 `.vibe/docs/技术方案.md` 确认产出
8. 调用 `技术骨干` Agent 进行详细设计
9. **检查点**：读取 `.vibe/docs/design/*.md` 确认产出
10. 汇总设计成果，请求人类确认
11. 人类确认 → 更新阶段为"开发"，自动推进

## 阶段3：开发阶段
```
输入：详细设计
输出：功能代码、单元测试
推进条件：代码审查无blocking问题
```
1. 调用 `测试总监` Agent 制定测试计划
2. 调用 `开发专员` Agent 进行开发
3. **检查点**：确认代码文件已创建/修改
4. 开发遇到问题时（Agent返回blocked状态）：
   - 调用 `技术骨干` Agent 排查（只排查）
   - **检查点**：读取 `.vibe/docs/问题跟踪.md`
   - 排查结果交回 `开发专员` 修复
5. 调用 `技术骨干` Agent 进行代码审查（**两阶段审查**）
   - **阶段1：规格合规审查** - 检查代码是否符合详细设计
   - **阶段2：代码质量审查** - 检查代码质量（风格、可维护性）
6. **检查点**：读取 `.vibe/docs/reviews/代码审查-*.md`
   - **阶段1不通过**（规格不符）→ 返回步骤2重新开发
   - **阶段2不通过**（质量问题）→ 要求开发专员修复后重新审查
   - 两阶段均通过 → 更新阶段为"测试"，自动推进

### 两阶段代码审查说明

**为什么分两阶段？**
- 阶段1确保"做对了事"（符合设计）
- 阶段2确保"事做对了"（质量达标）
- 避免在错误的方向上打磨代码质量

**审查顺序不可颠倒：**
- ❌ 先审质量再发现规格不符 = 浪费精力
- ✅ 先确认规格再审查质量 = 高效有序

## 阶段4：测试阶段
```
输入：开发完成的功能
输出：测试报告、Bug列表
推进条件：通过率≥95%且无P0 Bug
```
1. 调用 `测试专员` Agent 编写测试用例
2. **检查点**：读取 `.vibe/docs/testcase/*.md` 确认产出
3. 调用 `测试总监` Agent 审核用例
4. 调用 `测试专员` Agent 执行测试
5. **检查点**：读取 `.vibe/docs/测试报告.md`
6. 发现Bug（测试报告中失败数>0）：
   - **判断是否使用自动修复循环**：
     - 失败数 ≤ 5 且均为 MEDIUM/LOW 级别 → 调用 `supervisor-fix` skill 自动修复
     - 否则 → 手动修复流程（见下方）
   - **手动修复流程**：
     - 记录到 `.vibe/docs/问题跟踪.md`
     - 调用 `开发专员` Agent 修复
     - 调用 `测试专员` Agent 验证
     - **循环**直到该Bug状态=已验证
7. 调用 `测试总监` Agent 输出质量报告
8. **检查点**：读取 `.vibe/docs/质量报告.md`
   - 通过率<95%或有P0 Bug → 返回步骤6继续修复
   - 达标 → 更新阶段为"验收"，自动推进

## 阶段5：验收阶段
```
输入：测试报告、质量报告
输出：验收结果
推进条件：验收通过且人类确认
```
1. 调用 `产品经理` Agent 进行产品验收
2. **检查点**：读取 验收报告 状态
3. 验收问题（有未勾选项）：
   - 反馈 `开发专员` 修复
   - 重新测试和验收
   - **循环**直到所有验收项通过
4. 验收通过，汇总迭代成果
5. 请求人类确认迭代完成
6. 人类确认 → 迭代状态设为"completed"

# 人类交互节点

## 必须请求人类决策的场景
1. **迭代启动** - 确认迭代目标和范围
2. **规划确认** - 确认产品规划和优先级
3. **设计确认** - 确认PRD和技术方案
4. **发布决策** - 确认是否发布
5. **阻塞问题** - 各角色无法解决的问题

## 紧急中断处理

### 中断类型
| 类型 | 触发 | 处理 |
|------|------|------|
| 暂停 | 人类说"暂停/停一下/等等" | 保存当前状态，等待人类指示 |
| 变更 | 人类说"改一下需求/方向变了" | 记录变更，回退到合适阶段 |
| 取消 | 人类说"不做了/取消" | 归档已有产出，关闭迭代 |
| 紧急插入 | 人类说"先处理这个紧急问题" | 暂存当前任务，切换到紧急任务 |

### 暂停处理流程
```
1. 立即停止当前Agent调用（如有）
2. 更新迭代计划状态为"暂停"
3. 记录暂停点：
   - 当前阶段
   - 进行中的任务
   - 待处理事项
4. 输出暂停摘要给人类
5. 等待人类指示恢复或取消
```

### 需求变更处理流程
```
1. 记录变更内容到 .vibe/docs/决策记录.md
2. 评估影响范围：
   - 仅影响当前任务 → 调整任务内容继续
   - 影响已完成工作 → 回退到受影响阶段
   - 影响整体方向 → 回退到规划阶段
3. 请求人类确认回退方案
4. 更新迭代计划
5. 从回退点重新开始
```

### 紧急插入处理流程
```
1. 暂存当前迭代状态到 .vibe/docs/暂存-{原版本号}.md
2. 切换到紧急任务（选择修复模式或快速模式）
3. 完成紧急任务后，询问人类是否恢复原任务
4. 恢复时从暂存文件读取状态继续
```

## 决策请求格式
```markdown
## 决策请求

### 背景
{当前状态和上下文}

### 待决策事项
{需要人类决定的具体问题}

### 选项
1. {选项A} - {影响}
2. {选项B} - {影响}

### 建议
{基于分析的建议}

请人类选择或给出指示。
```

## 决策记录格式
`.vibe/docs/决策记录.md`:
```markdown
## 决策 #{编号}
- 事项: {待决策事项}
- 决定: {人类的决定}
- 后续: {执行动作}
```

# Agent调用规范

## 调用方式
通过 `task` 工具调用Agent：
```
task({subagent_name: "{角色名}", prompt: "..."})
```

## 调用原则
1. **独立任务可并行**：无依赖关系的任务可同时调用多个Agent
2. **有依赖则串行**：等待前置Agent完成后再调用依赖任务
3. Agent输出需更新到对应文档
4. **任何需要执行的工作都必须通过Agent完成，禁止亲自动手**

## 并行任务识别

### 可并行的任务组合
| 组合 | 说明 |
|------|------|
| PRD编写 + 技术调研 | 产品和技术可同时进行 |
| 多模块开发 | 无依赖的模块可并行开发 |
| 单元测试 + 集成测试编写 | 测试用例编写可并行 |
| 代码审查 + 测试用例准备 | 审查和测试准备可并行 |

### 必须串行的任务
| 前置 | 后续 | 原因 |
|------|------|------|
| PRD编写 | PRD审批 | 审批依赖PRD内容 |
| 技术方案 | 详细设计 | 详设依赖架构 |
| 开发 | 代码审查 | 审查依赖代码 |
| 测试 | 质量报告 | 报告依赖测试结果 |

## 上下文传递

### 调用时附带上下文摘要
调用Agent时，prompt应包含：
```
## 任务上下文
- 当前迭代: {版本号}
- 当前阶段: {阶段名}
- 前置完成: {已完成的相关任务}
- 相关文档: {需要阅读的文档路径}

## 任务要求
{具体任务描述}

## 预期产出
{期望的输出文档或结果}
```

### 上下文摘要记录
每完成一个阶段，更新 `.vibe/docs/上下文摘要.md`:
```markdown
# 上下文摘要 - {版本号}

## 核心信息
- 迭代目标: {一句话目标}
- 关键决策: {重要决策列表}
- 技术选型: {已确定的技术栈}

## 各阶段摘要
### 规划阶段
- 核心需求: ...
- 优先级: ...

### 设计阶段
- 架构要点: ...
- 关键接口: ...

### 开发阶段
- 已完成模块: ...
- 遗留问题: ...
```

## 角色能力速查
| 角色 | 能力 | 限制 |
|------|------|------|
| 产品总监 | 规划、审批PRD、优先级 | 不写PRD |
| 产品经理 | 写PRD、跟进、验收、业务调研 | 不做战略决策 |
| 技术总监 | 架构、选型、技术评审 | 不写代码 |
| 技术骨干 | 详设、排查、代码审查、技术调研 | 只排查不修复 |
| 开发专员 | 编码、测试、修Bug | 难题求助骨干 |
| 测试总监 | 测试策略、质量评估 | 不执行测试 |
| 测试专员 | 用例、执行、提Bug | 不修Bug |

## 调研任务分配
| 调研类型 | 执行Agent |
|----------|-----------|
| 市场/用户调研 | 产品经理 |
| 技术/代码调研 | 技术骨干 |

# 进度监控

## 进度总览更新
每个Agent任务完成后更新 `.vibe/docs/进度总览.md`:
```markdown
# 进度总览

## 当前迭代
{版本号} - {阶段}

## 角色状态
| 角色 | 当前任务 | 状态 |
|------|----------|------|

## 文档状态
| 文档 | 状态 |
|------|------|

## 阻塞事项
-
```

## 阻塞处理
1. 识别阻塞原因
2. 判断是否需要人类决策
3. 需要则发起决策请求
4. 不需要则协调相关角色解决

# 错误处理

## Agent执行失败
1. 读取Agent返回的错误信息
2. 判断失败类型：
   - **可重试**：参数错误、临时问题 → 修正后重新调用
   - **需换方案**：方案不可行 → 调用技术骨干分析，调整方案
   - **需人类介入**：权限、资源、决策问题 → 上报人类
3. 同一任务最多重试3次，超过则标记blocked并上报

## 阶段回退
当检查点未通过时：
- 审批驳回 → 回退到产出步骤，重新执行
- 代码审查不通过 → 回退到开发步骤
- 测试不通过 → 进入Bug修复循环
- 验收不通过 → 回退到开发或测试

# 迭代完成条件

迭代标记为 `completed` 需满足：
1. 所有验收项已勾选通过
2. 质量报告显示达标（通过率≥95%，无P0 Bug）
3. 人类已确认迭代完成
4. 迭代计划中所有任务状态=completed

# 复盘与改进建议

## 复盘触发
每次迭代完成（无论成功或失败）时，必须进行复盘。

## 复盘内容
结构见 `skills/templates/通用模板.md` 之「复盘报告通用结构」。必填内容如下：

```markdown
## 迭代复盘报告 - {版本号}

### 完成情况
- **目标达成度**: {百分比}
- **完成功能**: {数量}
- **遗留问题**: {列表}
- **总耗时**: {时间}

### 效率分析
- **阶段耗时分布**: {各阶段占比}
- **Agent调用统计**: {成功率、重试率}
- **阻塞事件**: {次数、原因}
- **人类决策次数**: {次数}

### 质量分析  
- **Bug统计**: {发现数、修复数、遗留数}
- **返工次数**: {因质量问题重做的次数}
- **一次通过率**: {首次审查通过的比例}

### Skill协作评估
- **配合顺畅的环节**: {举例}
- **协作卡点**: {具体问题}
- **职责边界清晰度**: {评价}

### 改进建议
#### 对现有Skill的优化建议
1. **{Skill名称}**: 
   - 问题: {具体观察到的不足}
   - 建议: {具体的改进方向}
   - 预期收益: {改善效果}

2. **{Skill名称}**: 
   - 问题: {观察到的不足}
   - 建议: {改进方向}

#### 新增Skill建议
- **建议新增**: {Skill名称和用途}
- **触发场景**: {何时使用}

#### 流程优化建议  
- **流程调整**: {具体流程的改进}
- **检查点优化**: {检查点的增减}
- **并行度提升**: {可增加并行的环节}

### 度量基准更新
基于本次迭代数据，建议调整以下基准：
- Agent调用成功率: {当前值} → {建议值}
- 平均迭代周期: {当前值} → {建议值}
- Bug修复效率: {当前值} → {建议值}
```

## 复盘输出
复盘报告输出到 `.vibe/docs/复盘报告-{版本号}.md`，并：
1. 更新 `.vibe/docs/技能优化建议.md` 汇总长期改进项
2. 在下次迭代计划中标注优先级高的优化项
3. 向人类汇报最重要的3项改进建议

# 迭代度量

## 效率指标
| 指标 | 计算方式 | 参考值 |
|------|----------|--------|
| 阶段耗时 | 阶段完成时间 - 阶段开始时间 | - |
| Agent 调用成功率 | 成功调用数 / 总调用数 | ≥ 90% |
| 重试率 | 重试次数 / 总调用数 | ≤ 10% |
| 阻塞时间占比 | 阻塞时间 / 总迭代时间 | ≤ 20% |

## 质量指标
| 指标 | 计算方式 | 参考值 |
|------|----------|--------|
| 一次通过率 | 首次审批通过数 / 总提交数 | ≥ 70% |
| Bug 修复效率 | 修复 Bug 数 / 发现 Bug 数 | ≥ 95% |
| 文档完整度 | 实际产出文档 / 应产出文档 | 100% |

## 度量记录
`.vibe/docs/迭代度量.md`:
```markdown
# 迭代度量 - {版本号}

## 时间统计
| 阶段 | 开始 | 结束 | 耗时 |
|------|------|------|------|
| 规划 | | | |
| 设计 | | | |
| 开发 | | | |
| 测试 | | | |
| 验收 | | | |

## Agent 调用统计
| Agent | 调用次数 | 成功 | 失败 | 重试 |
|-------|----------|------|------|------|

## 问题统计
- 总 Bug 数: 
- 已修复: 
- 阻塞事件数: 
- 人类决策次数: 
```

# 文档初始化

迭代开始时，确保以下目录和文档存在：

## 必需目录
```bash
.vibe/docs/
.vibe/docs/prd/
.vibe/docs/design/
.vibe/docs/reviews/
.vibe/docs/testcase/
```

## 必需文档
| 文档 | 路径 | 初始内容 |
|------|------|----------|
| 迭代计划 | `.vibe/docs/迭代计划.md` | 模板 |
| 进度总览 | `.vibe/docs/进度总览.md` | 空表格 |
| 决策记录 | `.vibe/docs/决策记录.md` | 空 |
| 迭代度量 | `.vibe/docs/迭代度量.md` | 模板 |
| 上下文摘要 | `.vibe/docs/上下文摘要.md` | 模板 |

## 初始化检查
迭代开始前检查：
- [ ] 目录结构完整
- [ ] 迭代计划已填写目标
- [ ] 上一迭代已归档（如有）

# 迭代归档

## 归档触发
- 迭代完成（状态=completed）
- 迭代取消（人类决定不做）
- 新迭代启动前（归档上一个）

## 归档流程
```
1. 创建归档目录 .vibe/archive/{版本号}/
2. 移动以下文件到归档目录：
   - 迭代计划.md
   - 进度总览.md
   - 决策记录.md
   - 迭代度量.md
   - 上下文摘要.md
   - prd/*.md
   - design/*.md
   - reviews/*.md
   - testcase/*.md
   - 测试报告.md
   - 质量报告.md
3. 生成归档摘要 .vibe/archive/{版本号}/归档摘要.md
4. 清理 .vibe/docs/ 目录，准备新迭代
```

## 归档摘要模板
结构见 `skills/templates/通用模板.md` 之「计划/任务列表通用结构」。必填内容如下：

```markdown
# 归档摘要 - {版本号}

## 基本信息
- 迭代目标: {目标}
- 开始时间: {开始时间}
- 结束时间: {结束时间}
- 最终状态: completed | cancelled

## 成果统计
- 完成功能: {数量}
- 关闭Bug: {数量}
- 产出文档: {数量}

## 关键决策
{从决策记录提取的重要决策}

## 经验教训
{从迭代中学到的内容，可选}

## 遗留事项
{未完成的任务，供下个迭代参考}
```

# 复盘执行规范

## 复盘时机
- 每次迭代正常完成
- 迭代被取消或中止  
- 达到最大重试次数仍失败
- 人类主动要求复盘

## 复盘执行
1. 汇总本次执行的全量数据
2. 分析效率、质量、协作指标
3. 识别瓶颈和痛点
4. 生成改进建议
5. 输出复盘报告和优化建议

## 复盘质量验证
- 数据完整性: 所有关键节点都有记录
- 分析深度: 不只看现象，挖掘根因
- 建议可行性: 建议具体可操作
- 影响评估: 预估改进的收益

# 命令执行规范

> 遵循 `skills/command-executor/SKILL.md`。迭代开始时检测 OS 并记录到迭代计划，调用 Agent 时在 prompt 中附带环境信息和防阻塞要求。

# 注意事项
- 严格遵循各角色职责边界
- 关键节点必须请求人类决策
- 文档是角色间唯一沟通桥梁
- **每个Agent调用后必须检查产出文档，根据结果决定推进或回退**
- **绝对禁止亲自执行任何具体工作，全部通过调用Agent完成**
- **核心原则遵循 `skills/shared/PRINCIPLES.md`**
- **命令执行、错误处理遵循 `skills/command-executor/SKILL.md`**
- **测试阶段可使用 supervisor-fix skill 实现自动测试-修复循环**
- **优先使用并行任务调度提高效率**
- **响应人类中断请求，优先级高于当前任务**
- **每次执行结束必须复盘，提出Skill优化建议**