Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
日本語の概要は準備中です。原文の説明を表示しています。
Analyzes large tasks for independent subtasks that can be safely parallelized. Produces a DAG-based dispatch plan with dependency ordering and maximum parallelism. Use when a task has 5+ subtasks touching independent files, or the user asks to speed up or parallelize the work.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Large tasks are often collections of independent subtasks hiding behind a sequential mental model. Find the parallelism.
vibe-workstream-orchestration)List all subtasks from the plan or requirements
Build dependency graph — For each pair of tasks, ask:
Group into batches:
Set parallelism limit — Use the harness's native parallelism (subagents, background tasks, workflows, or cloud tasks) and respect its concurrency limits. Past a handful of concurrent streams, the integration and review cost usually outweighs the speedup, so 3–5 is a sensible default unless the tasks are trivially independent.
Isolate — Give each parallel stream its own worktree or branch if the harness supports isolation, so streams can't overwrite each other's files. Integrate afterwards with vibe-cherry-pick-integration.
Create dispatch plan:
Total Tasks: X Batches: Y Max Parallelism: Z agents Estimated Speedup: ~Nx vs sequential
Task A ──→ Task D
Task B ──→ Task D
Task C (independent)
Task D ──→ Task F
Task E (independent)
| Batch | Tasks | Parallelism | Dependencies |
|---|---|---|---|
| 0 | A, B, C, E | 4 | None |
| 1 | D | 1 | A, B |
| 2 | F | 1 | D |
After all batches complete, integrate in order: [A, B, C, E] → D → F
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
日本語の概要は準備中です。原文の説明を表示しています。
Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.
日本語の概要は準備中です。原文の説明を表示しています。
Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.
日本語の概要は準備中です。原文の説明を表示しています。
Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.
日本語の概要は準備中です。原文の説明を表示しています。
Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.
日本語の概要は準備中です。原文の説明を表示しています。
Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.
日本語の概要は準備中です。原文の説明を表示しています。