跳到主要内容
知仓学习社ZHICANG

wave-execution

>

不碰外部(只输出文字)无严重或高危命中hashgraph-online/awesome-codex-plugins

它会碰到什么

扫了多少1 个文本文件,2 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

Wave Execution

用途

  • 把"按列表顺序逐个执行"改成"按依赖图分波次并行执行"。
  • 适合 /team-plan 拆解出多个独立任务、且部分任务间存在依赖关系的场景。
  • parallel-execution(Git worktree 并行)互补:wave-execution 负责"什么可以并行",parallel-execution 负责"如何物理并行"。

核心概念

波次(Wave)

将所有任务按依赖关系分组:

  • Wave 0:没有前置依赖的任务,可以最先执行
  • Wave 1:仅依赖 Wave 0 产出的任务
  • Wave N:仅依赖 Wave 0 ~ N-1 产出的任务

同一波次内的任务之间没有依赖关系,可以安全并行执行。

依赖图构建规则

  1. 显式依赖:任务 A 的输入来自任务 B 的输出(接口契约、数据模型、共享模块)。
  2. 文件依赖:任务 A 和任务 B 修改同一文件或同一模块。
  3. 测试依赖:任务 A 的测试需要任务 B 的 mock 或 fixture。
  4. 部署依赖:任务 A 的部署要求任务 B 先上线。

默认做法

1. 解析任务列表

/team-plan 的 delivery plan 中提取任务列表,每个任务需包含:

  • 任务 ID
  • 影响的文件/模块
  • 输入依赖(其他任务的产出)
  • 预计工作量

2. 构建依赖图

任务 A (API 契约定义)
  ↓
任务 B (后端实现)    任务 C (前端骨架)
  ↓                    ↓
任务 D (联调)  ←←←←←←←┘
  ↓
任务 E (E2E 测试)

3. 分配波次

  • Wave 0: [A]
  • Wave 1: [B, C](B 和 C 无互相依赖,可并行)
  • Wave 2: [D](依赖 B 和 C)
  • Wave 3: [E](依赖 D)

4. 执行波次

每个波次遵循:

  1. 启动:并行触发本波次所有任务
  2. 监控:跟踪每个任务的完成状态
  3. 门禁:本波次所有任务完成且通过 Pre-flight Gate 后,才启动下一波次
  4. 异常处理
  • 某任务失败但不阻塞其他任务 → 标记失败,继续其他任务
  • 某任务失败且下游依赖它 → 暂停下游波次中依赖该任务的子集
  • 关键路径任务失败 → 触发 Escalation Gate

5. 产出

波次执行完成后输出:

## 波次执行报告
- 总波次数:{N}
- 并行度峰值:Wave {X} = {Y} 个并行任务
- 关键路径:{任务序列}
- 完成状态:{成功/部分成功/失败}
- 失败任务:{列表}

与现有能力的关系

| 能力 | 职责 |

|------|------|

| wave-execution | 确定"什么可以并行"(逻辑编排层) |

| parallel-execution | 确定"如何物理并行"(Git worktree / tmux 层) |

| /team-plan | 产出任务列表和依赖关系 |

| /team-execute | 消费波次计划,按波次驱动执行 |

触发信号

  • /team-plan 产出超过 5 个任务且存在可并行子集。
  • 用户要求"加快交付节奏"或"并行推进"。
  • 多个前后端任务可以在接口契约锁定后同时启动。

配套约束

  1. 依赖必须显式:不允许"应该没有依赖"的默认假设,必须逐任务确认。
  2. 冲突检测:同一波次内的任务如果修改同一文件,自动升级为顺序执行或拆分更细粒度。
  3. 回退到顺序:当并行执行引入额外协调成本(频繁 merge conflict、上下文切换过多)时,主动建议回退到顺序执行。

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。