メニュー
Dispatch multiple independent tasks to parallel subagents when no shared file conflicts exist. Use when: a confirmed plan has independent tasks that can run concurrently without touching shared files.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.
Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.
After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.
Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.
Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.
Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.
| name | loom-dispatching-parallel-agents |
| description | Dispatch multiple independent tasks to parallel subagents when no shared file conflicts exist. Use when: a confirmed plan has independent tasks that can run concurrently without touching shared files. |
| when_to_use | Dispatch independent plan tasks in parallel only when dependency and file-conflict checks pass. |
| argument-hint | <spec_dir or task list> |
| user-invocable | true |
当多个任务之间没有依赖关系时，可以并行执行以提高效率。
限制条件： 仅当多个 task 之间无依赖、无共享文件修改时才可并行。若 task 间有文件冲突，必须退回到 loom-subagent-driven-development 的串行模式。
模型选择： 并行任务通常使用便宜模型（cheap model），因为它们大多是机械实现任务。
会话边界： 每个并行任务必须使用独立 fresh subagent。派发前必须有确认过的 task 边界和必要 handoff；不要把主会话原始上下文复制给所有 subagent。
specs/<date+feature>/plan.md 中的 Task 概览，读取 specs/<date+feature>/tasks/ 目录下的各 task 文件## 依赖关系分析
| Task | 依赖 | 可并行组 | 复杂度 |
| -------------------- | --------- | -------- | ------ |
| Task 1 (Module A) | 无 | 组 1 | 简单 |
| Task 2 (Module B) | 无 | 组 1 | 简单 |
| Task 3 (Module C) | Task 1 | 组 2 | 中等 |
| Task 4 (Module D) | Task 2 | 组 2 | 中等 |
| Task 5 (Integration) | Task 3, 4 | 组 3 | 复杂 |
将可并行的任务分组：
组 1: [Task 1, Task 2] → 并行执行（使用 cheap model）
组 2: [Task 3, Task 4] → 等组 1 完成后并行执行（使用 standard model）
组 3: [Task 5] → 等组 2 完成后执行（使用 capable model）
对同一组的任务，同时派发 subagent：
派发 Task 1 subagent (cheap) ──→ ┐
├→ 全部完成后进入组 2
派发 Task 2 subagent (cheap) ──→ ┘
模型选择：并行任务通常使用便宜模型（机械实现），集成/复杂任务使用标准/强模型。
并行派发以下独立任务（使用 cheap model）：
## Task N: <任务名>
<完整 task 内容>
## Task M: <任务名>
<完整 task 内容>
## 约束
- 每个 subagent 独立工作，互不干扰
- 如发现与其他任务有冲突，立即报告
- 完成后输出创建/修改的文件列表
- 使用 cheap model（除非任务复杂）