/do-in-parallel

Execute tasks in parallel across multiple targets with intelligent model selection, independence validation, requirement grouping analysis, meta-judge evaluation specification, LLM-as-a-judge verification, and quality-focused prompting.

• Purpose - Execute tasks across multiple independent targets in parallel
• Pattern - Supervisor/Orchestrator with parallel dispatch, requirement grouping, context isolation, and meta-judge + judge verification
• Output - Multiple solutions, one per target, with aggregated summary
• Efficiency - Dramatic time savings through concurrent execution of independent work

Quality Assurance

Enhanced verification with Zero-shot CoT, Constitutional AI self-critique, requirement grouping analysis, meta-judge evaluation specification, LLM-as-a-judge verification, and intelligent model selection

Pattern: Parallel Orchestration with Judge Verification

This command implements a seven-phase parallel orchestration pattern:

Phase 1: Parse Input and Identify Targets
                     │
Phase 2: Task Analysis with Zero-shot CoT
         ┌─ Task Type Identification ─────────────────┐
         │ (transformation, analysis, documentation)  │
         ├─ Per-Target Complexity Assessment ─────────┤
         │ (high/medium/low)                          │
         ├─ Independence Validation ──────────────────┤
         │ CRITICAL: Must pass before proceeding      │
         ├─ Requirement Grouping Analysis ────────────┤
         │ (repeatable / shared / independent)        │
         └────────────────────────────────────────────┘
                     │
Phase 3: Model and Agent Selection
         Is task COMPLEX? → Opus
         Is task SIMPLE/MECHANICAL? → Haiku
         Is output LARGE but task not complex? → Sonnet
         Otherwise → Opus (default for balanced work)
                     │
Phase 3.5: Dispatch Meta-Judges (Grouped, All in Parallel)
         One per repeatable group (reusable spec)
         One per shared group (combined spec)
         One per independent task (task-specific spec)
         (Specs reused for ALL retries — never re-run)
                     │
Phase 4: Construct Per-Target Prompts
         [CoT Prefix] + [Task Body] + [Self-Critique Suffix]
         (Same structure for ALL agents, customized per target)
                     │
Phase 5: Parallel Dispatch and Judge Verification
         ┌─ Agent 1 (target A) ─→ Judge 1 (+meta-spec) ─┐
         ├─ Agent 2 (target B) ─→ Judge 2 (+meta-spec) ─┼─→ Concurrent
         └─ Agent 3 (target C) ─→ Judge 3 (+meta-spec) ─┘
                     │
         Each target: Implement → Judge (with meta-spec) → Retry (max 3)
         Shared groups: ONE judge reviews ALL related changes together
                     │
Phase 6: Collect and Summarize Results
         Aggregate outcomes, report failures, suggest remediation

Execution Flow

Independent / Repeatable Flow (one judge per task)

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge Dispatch (ALL in parallel)                      │
│                                                                         │
│   Independent:            Repeatable Group:                             │
│   ┌──────────────┐        ┌─────────────────────┐                       │
│   │ Meta-Judge A  │        │ Meta-Judge (shared)  │                       │
│   │ (Opus)        │        │ (Opus)               │                       │
│   │ → Spec YAML A │        │ → Reusable Spec YAML │                       │
│   └──────┬───────┘        └──────────┬──────────┘                       │
│          │                     ┌─────┴─────┐                            │
│          ▼                     ▼           ▼                            │
│   Phase 5: Implementation (ALL in parallel, one per task)               │
│                                                                         │
│   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐               │
│   │ Implementer A │   │ Implementer B │   │ Implementer C │              │
│   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘               │
│          │                  │                  │                        │
│          ▼                  ▼                  ▼                        │
│   Phase 5.2: Judge per task (after ALL implementors complete)           │
│                                                                         │
│   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐               │
│   │  Judge A      │   │  Judge B      │   │  Judge C      │              │
│   │ +Spec YAML A  │   │ +Reusable Spec│   │ +Reusable Spec│              │
│   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘               │
│          ▼                  ▼                  ▼                        │
│   Parse Verdict (per target)                                            │
│   ├─ PASS (≥4)? → Complete                                              │
│   ├─ Soft PASS (≥3 + low priority issues)? → Done                       │
│   └─ FAIL (<4)? → Retry (max 3 per target)                              │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Shared Flow (one judge for the group)

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge for Shared Group                                │
│   ┌──────────────────────┐                                              │
│   │ Meta-Judge (combined) │                                              │
│   │ (Opus)                │                                              │
│   │ → Combined Spec YAML  │                                              │
│   └──────────┬───────────┘                                              │
│         ┌────┴────┐                                                     │
│         ▼         ▼                                                     │
│   Phase 5: Implementation (one per task, in parallel)                   │
│   ┌──────────────┐   ┌──────────────┐                                   │
│   │ Implementer X │   │ Implementer Y │                                  │
│   └──────┬───────┘   └──────┬───────┘                                   │
│          │                  │                                           │
│          └────────┬─────────┘                                           │
│                   ▼                                                     │
│   Phase 5.2: ONE Judge for entire group                                 │
│   ┌────────────────────────────────┐                                    │
│   │  Judge (shared)                 │                                    │
│   │ +Combined Spec YAML             │                                    │
│   │ +ALL implementation outputs     │                                    │
│   └──────────────┬─────────────────┘                                    │
│                  ▼                                                      │
│   Parse per-task verdicts → Retry ONLY failing task(s) if needed        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Usage

# Inferred targets from task description
/do-in-parallel "Apply consistent logging format to src/handlers/user.ts, src/handlers/order.ts, and src/handlers/product.ts"

Advanced Options

# Basic usage with file targets
/do-in-parallel "Simplify error handling to use early returns" \\
  --files "src/services/user.ts,src/services/order.ts,src/services/payment.ts"

# With named targets
/do-in-parallel "Generate unit tests achieving 80% coverage" \\
  --targets "UserService,OrderService,PaymentService"

# With model override
/do-in-parallel "Security audit for injection vulnerabilities" \\
  --files "src/db/queries.ts,src/api/search.ts" \\
  --model opus

When to Use

Good use cases:

• Same operation across multiple files (refactoring, formatting)
• Independent transformations (each file stands alone)
• Batch documentation generation (API docs per module)
• Parallel analysis tasks (security audit per component)
• Multi-file code generation (tests per service)

Do NOT use when:

• Only one target → use /do-and-judge instead
• Targets have dependencies → use /do-in-steps instead
• Tasks require sequential ordering → use /do-in-steps instead
• Shared state needed between executions → use /do-in-steps instead
• Quality-critical tasks needing comparison → use /do-competitively instead

Meta-Judge and Judge Verification

Meta-judges are dispatched based on a requirement grouping analysis performed before any implementation begins. The number and type of meta-judges depends on how tasks are grouped:

Each meta-judge generates a tailored evaluation specification (rubrics, checklists, scoring criteria). Specifications are reused for all retries of their associated tasks -- they are never re-run per target or on retries. All meta-judges are launched in parallel regardless of grouping type.

Each implementation agent is then verified by an independent sadd:judge agent that applies the appropriate meta-judge specification mechanically.

Scoring Scale

Quality Enhancement Techniques

Context Isolation Best Practices

• Minimal context: Each sub-agent receives only what it needs for its target
• No cross-references: Don't tell Agent A about Agent B's target
• Let them discover: Sub-agents read files to understand local patterns
• File system as truth: Changes are coordinated through the filesystem
• Track pre-existing changes: Pass context about prior modifications to each agent's judge to prevent attribution confusion between pre-existing and current changes

Error Handling

Critical Rules:

• Each target is isolated - failures don't affect other targets
• NEVER continue past max retries without user input
• NEVER try to "fix forward" without addressing judge issues
• NEVER skip judge verification
• STOP and report if context is missing (don't guess)
• Continue with successful targets even if some fail
• Report all failures clearly in final summary
• For shared groups, only retry the specific failing implementation agent(s), not the entire group

Token Optimisation via Requirement Grouping

Requirement grouping analysis reduces the total number of agents dispatched by sharing meta-judges and judges across related tasks. The key insight is that tasks sharing the same pattern (repeatable) or requiring joint review (shared) do not each need their own meta-judge.

How It Works

1. A single meta-judge is dispatched per group (not per target) before implementation begins
2. Its evaluation specification YAML is reused across ALL targets in that group
3. The meta-judge spec is also reused on retries -- it is never re-generated

Agent Count Formula

For repeatable groups (the most common case): G meta-judges + N implementers + N judges = G + 2N agents.

Concrete Savings Examples