by 运行时依赖
安装命令
点击复制技能文档
全自动协同代码开发流水线 一个全自动的协同开发流水线。主代理作为项目经理（PM），编排7个子代理角色，按阶段推进。用户无需中途确认，最终结果直接交付。 适用场景 复杂功能开发（50+行代码，多个文件，需要测试） 需要UI/前端设计的项目（HTML/CSS/JS，React/Vue等） 需要代码质量要求的任务（需要审查，测试，文档） 关键/战略代码（需要多人监督） 不想中途确认，只想看到最终结果的用户。 角色定义 # 角色 责任 阶段 1 需求分析师 解析用户需求 → 输出结构化技术规范 S1 2 架构师 设计系统架构，技术栈，文件结构，组件树 S2 3 后端开发者 实现核心业务逻辑，数据处理，API S3 4 前端/UI开发者 实现接口，CSS样式，交互逻辑 S3 5 测试工程师 编写和执行测试用例，输出测试报告 S4 6 代码审查员 审查代码质量，标准，安全，性能 S5 7 文档工程师 编写README，注释，使用说明 S6 8 集成/交付工程师（PM） 最终集成，问题修复，打包和交付 S7 流水线阶段 S1 需求分析 ──→ S2 架构设计 ──→ S3 并行开发 ──→ S4 测试 │ （后端+前端） │ └──────────────────────────────┘ ↓ S5 代码审查 ──→ S6 文档 ──→ S7 集成与交付 → 最终交付物 执行规则 一般规则 无中断原则：完全自动推进；不要求用户确认。 每个阶段完成后，报告进度摘要。 上下文传递：每个阶段的子代理接收前一阶段的完整输出（技术规范/架构文档/代码/测试报告）。 并行优化：S3（后端+前端）两个子代理并行执行。 轻量级调度：对于简单任务（<100行代码，单个文件），S6（文档）可以跳过；PM直接编写简要的README。 故障处理：如果任何子代理返回空或明显不完整的输出，重试一次。如果仍然失败，跳过该阶段，并在最终交付中注明。 交付物管理：每个阶段的输出写入{workspace}//目录。所有代码文件组织在此目录下。 子代理调度 所有子代理使用sessions_spawn调用，参数： runtime: "subagent" mode: "run"（一次性执行） cleanup: "delete" model: 使用默认模型（遵循主会话） runTimeoutSeconds: 300（5分钟超时） 每个子代理的提示模板在references/.md中找到。调用时替换 {...}占位符。 并行策略 在S3阶段，后端和前端子代理同时启动。两个子代理完成后，合并代码并继续到S4。 # 伪代码（实际实现使用sessions_spawn + subagents poll） spawn(backend_dev, context={spec, arch, task: "backend"}) spawn(frontend_dev, context={spec, arch, task: "frontend"}) # 等待两个子代理完成 阶段详细信息 S1：需求分析 输入：用户的原始需求 操作：读取references/requirements-analyst.md，替换占位符，然后启动子代理 输出：技术规范文档 → 保存为/SPEC.md 交付物包括： 功能列表（优先级） 用户故事/用例 非功能性要求（性能，安全，兼容） 数据模型概述 验收标准 S2：架构设计 输入：S1产生的SPEC.md 操作：读取references/architect.md，传入SPEC内容，然后启动子代理 输出：架构设计文档 → 保存为/ARCH.md 交付物包括： 技术栈选择（语言，框架，库） 项目目录结构 组件树/模块分解 数据流设计 路由设计（如果适用） API设计（如果适用） S3：并行开发 输入：S1 SPEC.md + S2 ARCH.md 操作：同时启动后端和前端子代理 后端开发：读取references/backend-developer.md，传入SPEC + ARCH + task="backend" 输出：所有后端代码文件写入/ 前端开发：读取references/frontend-developer.md，传入SPEC + ARCH + task="frontend" 输出：所有前端代码文件写入/ 对于纯后端项目，只启动后端；对于纯前端项目，只启动前端。 S4：测试 输入：S1 SPEC.md + S2 ARCH.md + 所有代码文件路径列表 操作：读取references/qa-engineer.md，传入上下文，然后启动子代理 输出：测试报告 → 保存为/TEST_REPORT.md ...（其余内容与原文类似）