名称: 启动-adw 描述: 启动一个带有可组合步骤的AI开发者工作流。在执行plan_build、plan_build_review或plan_build_review_fix工作流时使用。 参数提示: <工作流类型> <任务描述> 允许的工具: Read, Write, Glob, Grep, Task, Bash
启动ADW
启动一个带有可组合计划/构建/审查/修复步骤的AI开发者工作流。
参数
$ARGUMENTS:<工作流类型> <任务描述>工作流类型: 可选plan_build,plan_build_review,plan_build_review_fix任务描述: ADW应该完成的任务
工作流类型
| 类型 | 步骤 | 使用场景 |
|---|---|---|
plan_build |
计划 → 构建 | 高置信度，简单任务 |
plan_build_review |
计划 → 构建 → 审查 | 注重质量的任务 |
plan_build_review_fix |
计划 → 构建 → 审查 → [修复循环] | 完全自主，ZTE目标 |
指令
步骤1: 解析参数
提取工作流类型和任务描述:
示例: "plan_build_review 为认证端点添加限流"
→ workflow_type: plan_build_review
→ task: "为认证端点添加限流"
步骤2: 生成ADW ID
创建一个8字符的唯一标识符:
# 生成唯一ADW ID
head -c 4 /dev/urandom | xxd -p
步骤3: 创建规格路径
确定规格文件位置:
specs/{type}-{adw_id}-{slugified-description}.md
示例: specs/feature-a1b2c3d4-add-rate-limiting.md
步骤4: 执行计划步骤
使用/plan命令或启动计划代理:
预期输出:
- 规格文件在已知路径创建
- 总结部分存在
- 需求列举
- 验收标准定义
- 技术方法概述
步骤5: 执行构建步骤
读取规格并实施:
预期输出:
- 代码变更完成
- 提交带有
build:前缀 - 测试通过（如果存在）
步骤6: 执行审查步骤（如果包含）
对于plan_build_review和plan_build_review_fix:
预期输出:
- 结构化审查报告
- 状态: 通过或失败
- 问题按严重性分类
步骤7: 执行修复循环（如果包含）
仅针对plan_build_review_fix:
循环约束:
- 最大修复尝试次数 = 3
- 通过或达到最大尝试次数时退出
- 达到最大尝试次数时升级
预期输出:
- 问题解决
- 提交带有
fix:前缀 - 修复后审查通过
输出
## ADW执行报告
**ADW ID:** {adw_id}
**工作流:** {workflow_type}
**任务:** {task_description}
**开始时间:** {timestamp}
### 步骤结果
| 步骤 | 状态 | 持续时间 | 详情 |
| --- | --- | --- | --- |
| 计划 | ✅ | {time} | 规格: {path} |
| 构建 | ✅ | {time} | 提交: {count} |
| 审查 | ✅/❌ | {time} | 状态: {通过/失败} |
| 修复 | ✅/⚠️ | {time} | 尝试: {n}/{max} |
### 规格文件
`{spec_path}`
### 提交记录
- `{commit_hash}`: {message}
- `{commit_hash}`: {message}
### 最终状态
**结果:** 成功 | 失败 | 升级
**总结:** {简要总结}
### 指标
- 总持续时间: {time}
- 令牌使用量: {estimate}
- 修复尝试: {n} (如果适用)
SDK说明
实现说明: 完整的ADW编排（包括修复循环）需要Claude Agent SDK以进行适当的步骤隔离。此命令提供设计模式；SDK实现支持生产执行。
错误恢复
| 步骤 | 失败 | 恢复 |
|---|---|---|
| 计划 | 无法生成规格 | 重试，增加上下文 |
| 构建 | 构建错误 | 返回计划，附带反馈 |
| 审查 | 关键问题 | 进入修复（如果启用） |
| 修复 | 无法解决 | 达到最大尝试次数后升级 |
交叉引用
- @adw-framework.md - ADW架构
- @composable-steps.md - 步骤合同
composable-step-design技能 - 步骤设计模式adw-orchestrator代理 - 编排计划