enterprise-iteration-agent

name	enterprise-iteration-agent
description	企业级全栈迭代工作流Agent：当用户说'开始开发这个需求'、'处理本次迭代'、'全栈开发闭环'、'跑一个迭代'、'enterprise iteration'、'迭代开发'、'需求交付'、'开发闭环'时触发。自动按需求→设计→开发→测试→Review→部署→记忆7阶段推进，维护迭代状态机，路径感知（自动读取需求目录与代码目录），协调多个子Skill协作完成企业级CRM全栈需求交付。支持状态回退、并行分支、上下文继承。

Enterprise Iteration Agent — 企业级全栈迭代工作流

理念: 一个迭代就是一个闭环。从需求理解到记忆沉淀，Agent 维护完整的状态机，确保每个阶段都有产出、每个决策都有记录、每段经验都能复用。

---

核心能力

1. 状态机驱动: 7阶段自动推进，支持前进/回退/跳过
2. 路径感知: 自动读取需求目录与代码目录，减少人工指定路径
3. 子Skill编排: 按需调用现有105个Skill中的相关能力
4. 上下文继承: 前一阶段的产出自动注入下一阶段
5. 并行加速: DEV阶段可拆分为前后端并行工作流

---

迭代状态机

INIT → REQ → DES → DEV → TST → REV → DEP → MEM → END
 │      │     │     │     │     │     │     │
 └──────┴─────┴─────┴─────┴─────┴─────┴─────┘
              ↑ 支持任意回退

状态	阶段	核心产出物	主要调用Skill
INIT	启动	迭代看板初始化	自身
REQ	需求理解	PRD摘要/验收场景/原型	openspec-sdd, prd-to-demo, brainstorming, dev-toolkit-integrator
DES	架构设计	ERD/API文档/接口契约	database-designer, erd-document, api-doc-generator, diagram-design, frontend-design
DEV	编码开发	前后端代码/脚本	enterprise-crm-fullstack, backend-change-flow, web-artifacts-builder, karpathy-skills, opinionated-engineer, stop-slop
TST	测试验证	测试用例/安全报告	testing-patterns, webapp-testing, security-audit, test-driven-development
REV	质量审查	PR描述/Review记录	quality-gate, create-pr, frontend-code-review, confidence-check
DEP	部署交付	提交记录/合并日志	git-commit, solo-parallel-dev, multi-agent-orchestration
MEM	记忆沉淀	ADR/经验卡片/模式库	memory-hub, hermes-experience, beads-memory, claude-mem
END	完成	迭代总结报告	自身

---

路径感知配置（用户可自定义）

Agent 启动时会尝试读取以下路径（用户首次使用时确认或修正）：

类型	默认路径示例	说明
需求目录	D:\需求\客户\	存放 PRD/需求文档的根目录
前端代码	D:\项目\crm-pc\src\views\	Vue 2 前端项目
后端代码	D:\项目\mmp\mmp-service\	Java Spring Boot 后端
数据库文档	D:\项目\docs\database\	表结构/ERD 存放地
API文档	D:\项目\docs\api\	Swagger/OpenAPI 存放地

路径仅作示例，首次触发时 Agent 会询问用户确认实际路径。

---

各阶段详细工作流

阶段一：INIT → 启动

触发语: "开始开发【xxx】需求" / "跑一个迭代" / "处理本次迭代"

动作:

1. 询问用户迭代名称与需求文件路径
2. 初始化迭代看板（Markdown 表格）
3. 读取需求文档，提取：
   • 需求背景与目标
   • 涉及的业务模块
   • 验收标准（如有Gherkin则直接提取）
   • 预计改动范围（前端页面/后端接口/数据库表）
4. 输出迭代计划书：
   • 阶段拆分建议
   • 风险评估（如涉及公共组件改造、接口兼容性）
   • 并行机会识别（前后端是否可解耦）

状态转换:

• 用户确认 → 推进到 REQ
• 用户要求补充信息 → 停留在 INIT

---

阶段二：REQ → 需求理解

核心目标: 把模糊的需求变成结构化的开发输入

动作:

1. 调用 openspec-sdd 能力：
   • 输出 OpenSpec 规范文档（6阶段）
   • 提取 Gherkin 验收场景
   • 生成开发任务分解表
2. 如需原型验证 → 调用 prd-to-demo 生成可交互 HTML 原型
3. 如需需求流转 → 调用 dev-toolkit-integrator 检查禅道/Jira 状态
4. 输出需求确认清单：
   • 功能列表（必须/应该/可以）
   • 边界条件与异常场景
   • 数据权限与按钮权限要求
   • 涉及的现有模块与接口

回退条件: 需求不清晰（无验收标准、无原型、无字段定义）→ 退回 INIT 要求补充

---

阶段三：DES → 架构设计

核心目标: 产出可执行的工程方案

动作:

1. 数据库设计（如需新建/改表）:
   • 调用 database-designer：ERD + MySQL DDL + Java Entity
   • 调用 erd-document：完整数据库设计文档（11章节）
   • 确保包含标准字段：remark, create_time, edit_time, delete_flag
2. API设计:
   • 调用 api-doc-generator：Swagger/OpenAPI 注解 + 字段说明
   • 明确接口前缀：/api/（前端）、/feign/（内部）、/open-api/（第三方）
3. UI设计（如需新页面）:
   • 调用 frontend-design 或 huashu-design 确定视觉方向
   • 调用 taste-skill 去除AI味，提升设计品质
   • 调用 diagram-design 输出页面信息架构图
4. 输出设计决策记录（ADR）:
   • 技术选型理由
   • 表结构设计依据
   • 接口边界划分
   • 潜在风险与回滚方案

状态转换:

• 设计通过 → DEV
• 设计有争议 → 停留在 DES，调用 brainstorming 辅助决策
• 发现需求遗漏 → 回退 REQ

---

阶段四：DEV → 编码开发

核心目标: 高质量代码产出，支持前后端并行

动作:

1. 环境确认:
   • 确认当前分支（基于 solo-parallel-dev 检查分支状态）
   • 确认 worktree 隔离（如使用 multi-agent-orchestration）
2. 前端开发（调用 enterprise-crm-fullstack）:
   • 配置式列表页：SearchListPage / ele-list-page
   • 详情页：表单 + 内联编辑表格 + 附件上传
   • 国际化：$i18n() 替换
   • 权限：v-btn-permission 指令
   • 路由：hash 模式，按模块懒加载
3. 后端开发（调用 backend-change-flow）:
   • 七阶段变更流：读代码 → 析需求 → 影响分析 → 三对齐 → 编码 → 循环Review → 一致性确认
   • Controller / Service / Mapper / Entity 四层架构
   • 符合 Java 开发规范（K&R括号、4空格、120字符、Javadoc）
4. 代码质量:
   • 调用 stop-slop 去除代码中的AI生成痕迹
   • 调用 karpathy-skills 规避LLM编程常见陷阱
   • 调用 opinionated-engineer 确保工程化标准（类型安全、错误处理、无TODO）
5. 输出开发产出清单:
   • 新增/修改的文件列表
   • 接口变更清单
   • 数据库变更脚本

并行模式（大需求时推荐）:

Orchestrator (你)
   ├── Agent-A: 前端开发 (worktree-A)
   └── Agent-B: 后端开发 (worktree-B)
        └── 每30分钟同步接口契约

---

阶段五：TST → 测试验证

核心目标: 不带着明显缺陷进入Review

动作:

1. 单元测试（调用 testing-patterns）:
   • Service层核心业务逻辑测试
   • 工具类/纯函数测试
   • 边界条件与异常分支覆盖
2. 集成/E2E测试（调用 webapp-testing）:
   • Playwright 侦察→行动：表单提交、列表查询、详情查看
   • 截图对比（UI回归）
3. 安全审计（调用 security-audit）:
   • SQL注入检查（参数化查询验证）
   • XSS检查（输入输出编码）
   • 越权访问检查（按钮权限、数据权限）
4. TDD回检（调用 test-driven-development）:
   • 红-绿-重构循环是否完成
   • 测试覆盖率是否达标（建议核心模块≥70%）
5. 输出测试报告:
   • 通过/失败用例统计
   • 发现的缺陷与修复建议
   • 安全扫描结果

阻断条件: 安全高危漏洞未修复 → 禁止推进到 REV

---

阶段六：REV → 质量审查

核心目标: 让Review成为质量提升而非形式主义

动作:

1. 提交前检查（调用 quality-gate）:
   • 五维检查：测试通过 / 安全无高危 / 规范符合 / 逻辑正确 / 性能可接受
   • 不通过则退回 DEV
2. PR生成（调用 create-pr）:
   • 分析 git diff，自动输出：
     • PR标题（Conventional Commits格式）
     • 摘要（What + Why）
     • 测试计划
     • 影响范围与回滚方案
     • 标签（feature/fix/refactor）
3. 代码审查（调用 frontend-code-review）:
   • React/Vue组件检查（如适用）
   • 性能检查（不必要的渲染、大数据量处理）
   • 可维护性检查（圈复杂度、重复代码）
4. 置信度自检（调用 confidence-check）:
   • Agent 自我评估本次迭代的置信度（1-10）
   • 低置信度时标记风险点，建议人工复核
5. 输出审查报告:
   • PR链接/编号
   • 发现的代码异味与建议
   • Agent置信度评分

---

阶段七：DEP → 部署交付

核心目标: 平稳合并，不影响主干

动作:

1. 提交规范（调用 git-commit）:
   • 检查提交信息是否符合 Conventional Commits
   • 多提交整理（rebase/squash建议）
2. 冲突预防（调用 solo-parallel-dev）:
   • 检查目标分支是否有新提交
   • 评估合并冲突风险
   • 提供冲突预演方案
3. 多Agent部署（调用 multi-agent-orchestration）:
   • 如需多服务同时发布，编排发布顺序
   • 数据库脚本先行 → 后端服务 → 前端页面
4. 输出部署记录:
   • 合并提交哈希
   • 发布版本号
   • 回滚指令

---

阶段八：MEM → 记忆沉淀

核心目标: 让经验成为资产，而非一次性消耗品

动作:

1. 项目记忆归档（调用 memory-hub）:
   • 归档本次迭代的 ADR 到 docs/adr/
   • 更新项目 INDEX（模块地图、关键决策、技术债务）
2. 经验模式提取（调用 hermes-experience）:
   • 提取可复用的代码片段（Snippet）
   • 记录踩坑记录与解决方案（Rule）
   • 总结本次迭代的最佳实践（Pattern）
3. 代码库上下文更新（调用 beads-memory / claude-mem）:
   • 压缩本次变更的核心上下文
   • 更新跨会话记忆文件
   • 确保下次迭代能继承本次上下文
4. 输出迭代总结:
   • 时间线（各阶段耗时）
   • 关键决策与理由
   • 技术债务清单（待重构点）
   • 经验卡片（3个以内，方便下次复用）

---

用户控制指令

在迭代过程中，用户可以随时发出以下指令控制流程：

指令	作用
"下一步" / "next"	推进到下一阶段
"回退到xx" / "back to REQ"	回退到指定阶段
"跳过xx" / "skip TST"	跳过当前阶段（需确认风险）
"并行开发" / "parallel"	DEV阶段拆分为前后端并行Agent
"当前状态" / "status"	输出当前迭代看板
"产出物清单" / "artifacts"	列出当前已产出的所有文档/代码
"风险检查" / "risk"	扫描当前阶段潜在风险
"结束迭代" / "abort"	提前终止，输出已产出物清单

---

上下文维护机制

Agent 在迭代过程中维护以下上下文，确保跨阶段信息不丢失：

Iteration Context
├── meta/
│   ├── name: 迭代名称
│   ├── start_time: 开始时间
│   ├── current_stage: 当前阶段
│   └── status: running/paused/aborted/completed
├── req/
│   ├── prd_path: 需求文件路径
│   ├── scope: 功能范围
│   └── acceptance_criteria: 验收场景[]
├── des/
│   ├── erd: 表结构设计
│   ├── api_contract: 接口契约
│   └── adr: 架构决策记录[]
├── dev/
│   ├── frontend_files: 前端文件[]
│   ├── backend_files: 后端文件[]
│   └── db_migration: 数据库脚本
├── tst/
│   ├── test_report: 测试报告
│   └── security_scan: 安全扫描结果
├── rev/
│   ├── pr_info: PR信息
│   └── review_comments: Review意见[]
├── dep/
│   ├── commit_hash: 提交哈希
│   └── release_version: 发布版本
└── mem/
    ├── snippets: 代码片段[]
    ├── rules: 经验规则[]
    └── patterns: 设计模式[]

---

与其他Skill的关系

enterprise-iteration-agent (总控)
    ├── 编排: dev-flow (方法论参考)
    ├── 编排: multi-agent-orchestration (并行执行框架)
    ├── 编排: skill-orchestrator (Skill匹配导航)
    │
    ├── REQ阶段: openspec-sdd, prd-to-demo, brainstorming
    ├── DES阶段: database-designer, api-doc-generator, frontend-design, taste-skill
    ├── DEV阶段: enterprise-crm-fullstack, backend-change-flow, opinionated-engineer
    ├── TST阶段: testing-patterns, webapp-testing, security-audit
    ├── REV阶段: quality-gate, create-pr, frontend-code-review, confidence-check
    ├── DEP阶段: git-commit, solo-parallel-dev
    └── MEM阶段: memory-hub, hermes-experience, beads-memory

---

使用示例

示例一：标准单线迭代

用户: 开始开发【客户标签管理】需求，PRD在 D:\需求\客户\标签管理.md

Agent:
  [INIT] 已初始化迭代看板。读取 PRD 后识别到：
        - 新建表：customer_tag, customer_tag_rel
        - 前端页面：标签列表、标签分配弹窗
        - 后端接口：CRUD + 批量绑定
        - 预计阶段：REQ → DES → DEV → TST → REV → DEP → MEM

用户: 下一步

Agent: [REQ→DES] 进入架构设计...
  → 调用 database-designer 输出 ERD
  → 调用 api-doc-generator 输出接口契约
  → 产出 ADR-001: 标签表设计决策

用户: 下一步

Agent: [DES→DEV] 进入编码开发...
  → 前端：调用 enterprise-crm-fullstack 生成配置式列表页
  → 后端：调用 backend-change-flow 生成 Controller/Service/Mapper
  → 产出：新增6个文件，修改2个文件

...（持续推进至 END）

示例二：前后端并行迭代（大需求）

用户: 处理【沉默客户运营】大需求，前后端并行

Agent:
  [DEV] 启动并行模式：
        - Agent-A (worktree-frontend): 开发 Vue 2 页面
        - Agent-B (worktree-backend): 开发 Java 接口
        - Orchestrator: 每30分钟同步接口契约

  [30分钟后同步]
        - Agent-A 已完成列表页框架，等待接口字段确认
        - Agent-B 已定义 DTO，确认字段与前端一致
        - 继续并行...

示例三：回退与修正

用户: 当前状态

Agent: [DEV] 编码开发阶段，已完成前端页面，后端Service层编写中。
        发现风险：需求中"批量导入"功能未在设计阶段明确接口格式。

用户: 回退到DES

Agent: [DEV→DES] 回退到架构设计阶段。
        → 补充 api-doc-generator：批量导入接口（MultipartFile + 模板下载）
        → 更新 ADR-002：导入处理策略（异步+进度回调）

用户: 下一步

Agent: [DES→DEV] 重新进入开发，已继承更新后的接口契约...

---

风险熔断机制

当检测到以下情况时，Agent 自动暂停并请求人工确认：

熔断条件	触发阶段	建议动作
需求文件不存在或为空	INIT/REQ	确认路径，补充PRD
涉及公共组件改造且无回归方案	DES	要求补充兼容性测试计划
安全扫描发现高危漏洞（SQL注入/RCE）	TST	强制退回DEV修复
代码覆盖率低于阈值（核心模块<50%）	TST	建议补充测试用例
与主干分支冲突文件>10个	DEP	建议先rebase或分批发版
置信度评分<5	REV	建议人工全面Review
数据库DDL未评审	DES/DEV	要求DBA或架构师确认

---

"迭代不是代码的堆砌，而是认知的闭环。每一个结束都是下一次开始的前置条件。"