| name | agent-workflow |
| description | Unified Agent product development workflow (AIO solo + FTM team): wolai docs, review gates, code/tests, defect doc sync, pre-merge audit. Use when starting features or bugfixes, 按工作流开发, AIO, FTM, 独自开发, 团队协作, 需求评审, 回流文档, 合并前复核, or wolai Agent workflow. |
Agent 产品开发工作流
单一 Skill，内含 AIO 独自版、FTM 团队版与全部子流程。加载本 Skill 后按「模块路由」读取对应章节执行，无需再 @ 其他 skill。
核心原则
先文档、后代码；先评审、后构建；缺陷不只改代码，还要反向更新文档。
docs/task.md 是每个需求的核心维护文档（本地、单一事实来源）：当前阶段、进度、待办、需要人反馈/确认的问题、已确认结论摘要、实现摘要、变更记录都实时写在这里。每轮会话先读它、随时更新它。- wolai 需求/技术/测试页是定稿沉淀：仅当①需求发生变动，或②某些内容（评审结论、技术方案、用例、设计决策）已明确/经人确认时，由 Agent 把对应内容回写 wolai（追加或更新已有段落，不注入固定填空模板、不覆盖人已确认内容）。
- 代码在 workspace。task.md 与 wolai 的关系：task.md 记「正在进行/待定」，wolai 记「已定稿/共享」。
会话启动（每轮必做）
- 读
docs/task.md → 确认当前阶段、进度、待反馈项、文档链接（以 task.md 为状态来源）
- 需要已确认的需求/技术/用例细节时，再按 task.md 中链接读对应 wolai 页
- 若无
docs/task.md，或无开工信息（无页面 ID / 无分支）→ 执行 modules/create-kit.md（同时建立 docs/task.md）
- 确认模式：
solo（AIO）或 team（FTM）
- 声明本步阶段 ID、是否允许写业务代码
硬性约束
三文档 S8 评审未全通过 → 禁止改 src/ 等业务代码
缺陷类型 design|requirement → 先走 modules/defect-sync.md，人确认后再改代码
需求正文禁止 AI 0-1 生产，仅审查与补充
一个需求 = 一条 Agent 会话
密钥/内网/客户数据禁止进 prompt
阶段与 Gate
| ID | 名称 | 主导 | 写代码 |
|---|
| S0 | 开工登记 | 🤖 | ❌ |
| S1 | 需求输入 | 👤 | ❌ |
| S2 | 工程背景 | 👤 | ❌ |
| S3 | AI 需求评审 | 🤖 | ❌ |
| S4 | 人工纠偏 | 👤 | ❌ |
| S5 | 技术+测试起草 | 🤖 | ❌ |
| S6 | 审核技术 | 👤 | ❌ |
| S7 | 测试补全 | 🤖 | ❌ |
| S8 | 评审闸门 | 👤 | ❌ |
| S9 | 并行构建 | 🤖 | ✅ |
| S10 | 人工测试 | 👤 | ✅ 修 bug |
| S11 | AI 复核 | 🤖 | ✅ 修缺口 |
| S12 | 使用说明 | 🔀 | ❌ |
| S13 | 合并基线 | 👤 | ❌ |
S8 闸门（全满足才可 S9）：P0 有验收标准；技术含错误码与边界；测试覆盖 P0；开放问题已决议；评审记录已回写。
Bugfix 快速路径：人填复现与范围 → 可选 AI 简评 → 人确认 → 直进 S9（至少 1 条测试用例）→ S10–S13 同 feature。
阶段推进：关键 Gate 需人回复「确认进入 S{n}」后 Agent 才更新阶段；禁止跳阶段（bugfix 可走 B 路径）。
模块路由
阶段 → 模块自动映射（用户未明说时按需求页当前阶段）：
| 阶段 | 执行模块 |
|---|
| S0, B0 | create-kit |
| S1–S2, S4, S6, S8, S10, S12–S13 | solo 或 team 工作流（按 MODE） |
| S3 | requirement-review |
| S5, S7, S9 | solo/team 工作流 |
| S11 | pre-merge-audit |
| 测试失败且类型未定 | 先分流 → defect-sync 或直改代码 |
模式选择
未说明时默认 solo；用户提 FTM/团队/四人团队 → team。
文档分工（无固定模板）
| 文档 | 人写 | Agent 写 | 人审 |
|---|
| 需求 | 背景、范围、功能点、验收标准 | 评审意见（S3） | S4、S8 |
| 技术 | 工程背景（S2） | 方案、接口、数据流（S5） | S6、S8 |
| 测试 | 探索性结论（S10） | 用例起草与补全（S5/S7） | S8 |
Agent 写入 wolai 时追加章节或更新已有段落，不覆盖人已确认内容；变更已确认内容须走 defect-sync。
task.md 维护约定（核心）
docs/task.md 由 Agent 实时维护，分为两大部分：
一、任务信息（初始化头部，相对稳定） — 开工/初始化阶段填写：
- 基本信息：需求 ID、标题、类型、模式、开发分支、基线
- 文档链接：wolai 需求页 / 技术页 / 测试页
- 关联工程项目：workspace 下各仓库的用途、是否本次涉及
- 涉及模块：仓库内子模块/目录
- 架构与规范要求：语言/框架、DI、MVVM、日志、本地化、注释与格式规范等
二、进度与共创记录（动态） — 开发过程中随时更新：
- 当前阶段 + 阶段清单（S0–S13 勾选）
- 待反馈 / 开放问题：需要人确认或决策的事项（含选项与建议），人答复后清理或归档
- 已确认结论摘要：指向 wolai 定稿，避免本地长篇复制
- 变更记录：需求/技术变更条目（日期、内容、是否已回写 wolai）
- 实现摘要 / 行动记录：本轮改了哪些文件 / 关键决策
回写 wolai 的触发：当待反馈项被人确认、需求发生变动、或技术/测试内容定稿时，把对应内容回写 wolai，并在变更记录中标注「已同步 wolai」。
新任务重置
新需求开工时复制本结构：重填「一、任务信息」、清空「二、进度与共创记录」（阶段清单回到全未勾、记录区清空）即为初始状态。
多任务并行
- 单任务：直接用
docs/task.md。
- 多任务并行：每个任务一份
docs/tasks/<需求ID>.md（如 docs/tasks/DGCS-387.md）。
- 会话开始时若存在多个任务文件，由用户指定要接续的任务（如「接续 DGCS-387」）；未指定且仅一个时默认它。
Agent 行为协议
- 需求正文：👤 专属，Agent 只读 + 评审，拒绝代写
- 技术/测试：🤖 可起草，人审核后视为定稿
- 写之后：更新
docs/task.md（当前阶段、进度、待反馈项、实现摘要、行动记录）；内容明确或需求变动时再回写 wolai
- 人确认：回复「确认进入 S{n}」后才推进阶段（同步更新 task.md 阶段）
- 子流程完成：回到主工作流对应步骤
缺陷分流（全局）
测试未通过
├── implementation → 改代码 → 必要时补用例 → pre-merge-audit
└── design | requirement → defect-sync → 快速重评审 → 再改代码
前置条件
文件结构
docs/task.md # 每个需求的核心维护文档（状态/进度/待反馈/变更，本地事实来源）
AgentWorkflow/
├── SKILL.md
├── solo-workflow.md
├── team-workflow.md
└── modules/
├── create-kit.md
├── requirement-review.md
├── defect-sync.md
└── pre-merge-audit.md
