chore: remove dev-workflow skill and related GSD files
The dev-workflow multi-agent orchestration skill is no longer needed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,86 +0,0 @@
|
||||
# dev-workflow
|
||||
|
||||
## What This Is
|
||||
|
||||
一个多代理协作开发编排技能，解决单Agent开发时的两大痛点：对话上下文卡住、开发不完整。通过9阶段流程编排多个子代理并行工作，实现高质量、完整的软件开发。
|
||||
|
||||
主Agent作为编排者，不参与实际开发，而是协调多个专业子代理完成：需求澄清 → 方案设计 → 交叉审核 → 用户决策 → Spec编排 → 并行开发 → 测试验证 → 代码审查 → 修复验证。
|
||||
|
||||
## Core Value
|
||||
|
||||
**通过多代理协作和分阶段编排，确保开发任务完整、高质量地完成。**
|
||||
|
||||
如果其他都失败，只要最终交付的代码是完整、可用的，这个技能就成功了。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Validated
|
||||
|
||||
(None yet — ship to validate)
|
||||
|
||||
### Active
|
||||
|
||||
- [ ] DW-01: 头脑风暴阶段 - 通过问答了解需求到足够进行完整开发
|
||||
- [ ] DW-02: 方案设计阶段 - 安排3个子代理并行进行方案设计
|
||||
- [ ] DW-03: 方案审核阶段 - 每个子代理审核其他两个方案，达成共识
|
||||
- [ ] DW-04: 方案汇报阶段 - 主代理汇报最终方案，用户决策
|
||||
- [ ] DW-05: Spec编排阶段 - 基于确认方案自动生成开发规格，编排并行任务
|
||||
- [ ] DW-06: 并行开发阶段 - 多个子代理根据Spec并行开发
|
||||
- [ ] DW-07: 测试阶段 - 运行现有测试 + 开发生成的新测试
|
||||
- [ ] DW-08: 代码审查阶段 - 3个子代理独立完整审查代码
|
||||
- [ ] DW-09: 修复验证阶段 - 汇总问题、安排修复、验证完成
|
||||
- [ ] DW-10: 状态持久化 - 每阶段保存进度，支持跨会话继续
|
||||
- [ ] DW-11: 每阶段汇报 - 每个阶段完成后向用户汇报进度
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- 单Agent开发模式 — 本技能必须使用多代理协作
|
||||
- 跳过用户决策 — 方案必须经过用户确认才能进入开发
|
||||
- 无限制重试 — 最多自动重试3次，超过必须汇报用户
|
||||
|
||||
## Context
|
||||
|
||||
### 问题背景
|
||||
|
||||
当前单Agent开发存在两大问题：
|
||||
1. **对话卡住** — 长时间开发会填满上下文窗口，导致质量下降
|
||||
2. **开发不完整** — 缺乏系统性流程，容易遗漏边界情况或测试
|
||||
|
||||
### 解决思路
|
||||
|
||||
- 主Agent作为轻量编排者，保持上下文清爽
|
||||
- 每个子代理独立上下文，专注单一任务
|
||||
- 多代理交叉审核，提高方案和代码质量
|
||||
- 分阶段保存状态，支持中断恢复
|
||||
|
||||
### 技术环境
|
||||
|
||||
- 技能框架：OpenClaw skills（SKILL.md 规范）
|
||||
- 子代理：OpenClaw sessions_spawn（subagent runtime）
|
||||
- 适用范围：通用软件项目 + kb-skills 技能开发
|
||||
- 触发方式：关键词"开始开发..."
|
||||
|
||||
## Constraints
|
||||
|
||||
- **子代理数量**: 方案设计3个 + 代码审查3个 + 开发N个（按任务数）
|
||||
- **重试上限**: 最多3次自动重试，超过后汇报用户
|
||||
- **上下文管理**: 主Agent不参与实际开发，避免上下文膨胀
|
||||
- **用户决策**: 方案必须经用户确认，不能自动进入开发
|
||||
|
||||
## Key Decisions
|
||||
|
||||
| Decision | Rationale | Outcome |
|
||||
|----------|-----------|---------|
|
||||
| 主Agent作为编排者 | 避免主Agent上下文膨胀，保持编排能力 | — Pending |
|
||||
| 3个子代理方案设计 | 多样化方案，避免单一思路局限 | — Pending |
|
||||
| 交叉审核方案 | 子代理互相审核，发现盲点 | — Pending |
|
||||
| 自动生成Spec | 减少用户负担，基于确认方案自动编排 | — Pending |
|
||||
| 现有测试+生成测试 | 双重保障，既有回归也有新增覆盖 | — Pending |
|
||||
| 3个子代理独立审查 | 独立审查比分工审查发现更多问题 | — Pending |
|
||||
| 依赖分析分波执行 | 自动处理任务依赖，最大化并行效率 | — Pending |
|
||||
| 有限自动修复(3次) | 平衡自动化效率和用户控制 | — Pending |
|
||||
| 每阶段保存状态 | 支持跨会话继续，不丢失进度 | — Pending |
|
||||
| 每阶段汇报 | 用户始终了解进度，有干预机会 | — Pending |
|
||||
|
||||
---
|
||||
*Last updated: 2026-03-09 after initialization*
|
||||
Reference in New Issue
Block a user