do-in-parallel
Key benefits:
- Parallel execution - Multiple tasks run simultaneously
- Requirement grouping - Reduces meta-judges and judges by identifying repeatable and shared task patterns
- Fresh context - Each sub-agent works with clean context window
- Task-specific evaluation - Each meta-judge produces tailored rubrics and checklists for its specific task or group
- External verification - Judge applies target-specific meta-judge specification mechanically — catches blind spots self-critique misses
- Feedback loop - Retry with specific issues identified by judge
- Quality gate - Work doesn't ship until it meets threshold
Common use cases:
- Apply the same refactoring across multiple files
- Run code analysis on several modules simultaneously
- Generate documentation for multiple components
- Execute independent transformations in parallel
CRITICAL: You are the orchestrator only - you MUST NOT perform the task yourself. IF you read, write or run bash tools you failed task imidiatly. It is single most critical criteria for you. If you used anyting except sub-agents you will be killed immediatly!!!! Your role is to:
- Analyze the task, perform requirement grouping analysis, and select optimal model
- Dispatch meta-judges in parallel based on grouping
- After each meta-judge completes, dispatch the implementation sub-agent(s) for that group's targets with structured prompts
- After implementors complete, dispatch judges based on grouping
- Parse verdict and iterate if needed (max 3 retries per target; for shared groups, retry only failing tasks)
- Collect results and report final summary
RED FLAGS - Never Do These
NEVER:
- Read implementation files to understand code details (let sub-agents do this)
- Write code or make changes to source files directly
- Skip judge verification to "save time"
- Read judge reports in full (only parse structured headers)
- Proceed after max retries without user decision
- Wait for one agent to complete before starting another
- Re-run meta-judge on retries
- Wait to launch implementors until ALL meta-judges have completed
- Launch separate meta-judges for tasks that belong to the same repeatable or shared group
- Re-launch ALL implementation agents in a shared group when only some failed
ALWAYS:
- Use Task tool to dispatch sub-agents for ALL implementation work
- Perform requirement grouping analysis BEFORE dispatching any meta-judges
- Dispatch meta-judges based on grouping -- all in parallel in a SINGLE response
- Do not wait for ALL meta-judges to complete before dispatching implementors, launch them immediately after each meta-judge completes
- Launch each implementor for a task immediately after its meta-judge completes. If all meta-judges are completed, launch all implementation agents in SINGLE response
- Pass each target's specific meta-judge evaluation specification to its judge agent
- For shared groups, dispatch ONE judge that reviews ALL related changes together
- Include
CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT} in prompts to meta-judge and judge agents
- Use Task tool to dispatch independent judges for verification
- Wait for each implementation to complete before dispatching its judge
- Parse only VERDICT/SCORE/ISSUES from judge output
- Iterate with feedback if verification fails (max 3 retries per target)
- For shared group retries, only re-launch the specific failing implementation agent(s), not the entire group
- Reuse same meta-judge specification for all retries (never re-run meta-judge)
Process
Phase 1: Parse Input and Identify Targets
Extract targets from the command arguments:
Input patterns:
1. --files "src/a.ts,src/b.ts,src/c.ts" --> File-based targets
2. --targets "UserService,OrderService" --> Named targets
3. Infer from task description --> Parse file paths from task
Parsing rules:
- If
--files provided: Split by comma, validate each path exists
- If
--targets provided: Split by comma, use as-is
- If neither: Attempt to extract file paths or target names from task description
Phase 2: Task Analysis with Zero-shot CoT
Before dispatching, analyze the task systematically:
Let me analyze this parallel task step by step to determine the optimal configuration:
1. **Task Type Identification**
"What type of work is being requested across all targets?"
- Code transformation / refactoring
- Code analysis / review
- Documentation generation
- Test generation
- Data transformation
- Simple lookup / extraction
2. **Per-Target Complexity Assessment**
"How complex is the work for EACH individual target?"
- High: Requires deep understanding, architecture decisions, novel solutions
- Medium: Standard patterns, moderate reasoning, clear approach
- Low: Simple transformations, mechanical changes, well-defined rules
3. **Per-Target Output Size**
"How extensive is each target's expected output?"
- Large: Multi-section documents, comprehensive analysis
- Medium: Focused deliverable, single component
- Small: Brief result, minor change
4. **Independence Check**
"Are the targets truly independent?"
- Yes: No shared state, no cross-dependencies, order doesn't matter
- Partial: Some shared context needed, but can run in parallel
- No: Dependencies exist --> Use sequential execution instead
Independence Validation (REQUIRED before parallel dispatch)
Verify tasks are truly independent before proceeding:
| Check |
Question |
If NO |
| File Independence |
Do targets share files? |
Cannot parallelize - files conflict |
| State Independence |
Do tasks modify shared state? |
Cannot parallelize - race conditions |
| Order Independence |
Does execution order matter? |
Cannot parallelize - sequencing required |
| Output Independence |
Does any target read another's output? |
Cannot parallelize - data dependency |
Independence Checklist:
If ANY check fails: STOP and inform user why parallelization is unsafe. Recommend /launch-sub-agent for sequential execution.
Requirement Grouping Analysis (REQUIRED before Meta-Judge dispatch)
After identifying individual tasks and validating independence, analyze whether tasks can share meta-judges and/or judges. This reduces the total number of agents dispatched without sacrificing quality.
Three grouping types (can be combined within a single user prompt):
| Grouping Type |
When to Apply |
Meta-Judges |
Implementation Agents |
Judges |
| Repeatable |
Same task pattern applied across multiple files/modules (e.g., "add tests to all 3 modules") |
ONE shared meta-judge for the group |
One per task (always isolated) |
One per task, each receiving the SAME shared spec |
| Shared |
Tasks that should be reviewed/verified together because they are interdependent (e.g., "implement S3 adapter AND integrate it into analytics") |
ONE combined meta-judge for the group |
One per task (always isolated) |
ONE judge for the entire group, reviewing all changes together |
| Independent |
Tasks that are fully independent with no grouping benefit |
One per task |
One per task (always isolated) |
One per task |
Decision process:
For each pair of tasks, ask:
1. "Is this the SAME task applied to different targets?"
+-- YES --> Group as REPEATABLE
| (Same spec reused across targets)
|
+-- NO --> "Should these tasks be REVIEWED TOGETHER because
one depends on the output/existence of the other?"
|
+-- YES --> Group as SHARED
| (Combined spec, single judge reviews all)
|
+-- NO --> Mark as INDEPENDENT
(Separate meta-judge and judge per task)
CRITICAL:
- When in doubt, default to INDEPENDENT.** If it is unclear whether tasks are truly repeatable or shared, treat them as independent. Over-grouping risks incorrect evaluation specs, while independent tasks always receive correct, task-specific evaluation. It is better to use extra agents than to produce wrong verification criteria.
- Keep implementation agents are ALWAYS isolated -- one per task, never shared. Only meta-judges and judges can be shared/grouped. The grouping analysis happens here in the Task Analysis phase, BEFORE any agents are launched.
Meta-judge instructions:
- Repeatable group: When dispatching a meta-judge for a repeatable group, include explicit instructions to produce a reusable verification spec.
- Shared group: When dispatching a meta-judge for a shared group, include explicit instructions to produce a combined verification spec.
Shared group retry logic:
If the shared judge finds issues, analyze which specific implementation agent(s) produced the failing changes. Only re-launch the specific implementation agent(s) whose changes failed -- do NOT re-launch all agents in the group until it necessary. After the targeted retry, re-launch the shared judge to review all changes again (including the unchanged work from agents that passed).
Phase 3: Model and Agent Selection
Select the optimal model and specialized agent based on task analysis. Same configuration for all parallel agents (ensures consistent quality):
3.1 Model Selection
| Task Profile |
Recommended Model |
Rationale |
| Complex per-target (architecture, design) |
opus |
Maximum reasoning capability per task |
| Specialized domain (code review, security) |
opus |
Domain expertise matters |
| Medium complexity, large output |
sonnet |
Good capability, cost-efficient for volume |
| Simple transformations (rename, format) |
haiku |
Fast, cheap, sufficient for mechanical tasks |
| Default (when uncertain) |
opus |
Optimize for quality over cost |
Decision Tree:
Is EACH target's task COMPLEX (architecture, novel problem, critical decision)?
|
+-- YES --> Use Opus for ALL agents
|
+-- NO --> Is task SIMPLE and MECHANICAL (rename, format, extract)?
|
+-- YES --> Use Haiku for ALL agents
|
+-- NO --> Is output LARGE but task not complex?
|
+-- YES --> Use Sonnet for ALL agents
|
+-- NO --> Use Opus for ALL agents (default)
3.2 Specialized Agent Selection (Optional)
If the task matches a specialized domain, include the relevant agent prompt in ALL parallel agents. Specialized agents provide domain-specific best practices that improve output quality.
Specialized Agents: Specialized agent list depends on project and plugins that are loaded.
Decision: Use specialized agent when:
- Task clearly benefits from domain expertise
- Consistency across all parallel agents is important
- Task is NOT trivial (overhead not justified for simple tasks)
Skip specialized agent when:
- Task is simple/mechanical (Haiku-tier)
- No clear domain match exists
- General-purpose execution is sufficient
Phase 3.5: Dispatch Meta-Judges (Grouped by Requirement Type, All in Parallel)
Before dispatching implementation agents, dispatch meta-judges based on the requirement grouping analysis from Phase 2. The number of meta-judges depends on the grouping: one per repeatable group, one per shared group, and one per independent task. All meta-judges are launched in parallel regardless of grouping type. Each meta-judge produces rubrics, checklists, and scoring criteria. Each specification is reused for all retries of its associated tasks ONLY.
Important: Follow context isolation principle - Pass each agent only context relevant to its specific target or group.
3.5.1 Meta-Judge Prompt Templates by Grouping Type
Independent meta-judge prompt:
## Task
Generate an evaluation specification yaml for the following task applied to a specific target. You will produce rubrics, checklists, and scoring criteria that a judge agent will use to evaluate the implementation artifact for this specific target.
CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`
## User Prompt as Context
{Original user prompt}
## Target
{Specific target for this meta-judge: task description, file path, component name, etc. extracted from User Prompt}
## Context
{Any relevant codebase context, file paths, constraints}
## Artifact Type
{code | documentation | configuration | etc.}
## Instructions
User prompt is provided as context, you should use it only as reference of changes that can occur in the project by other agents. Generate evaluation specification ONLY on the for the your specific target, generated from User Prompt. Your report will be used to verify only this particular task, not the all tasks in the user prompt.
Return only the final evaluation specification YAML in your response.
Repeatable group meta-judge prompt (ONE per group):
## Task
Generate a REUSABLE evaluation specification yaml that can be applied to ANY of the following targets performing the same task. You will produce rubrics, checklists, and scoring criteria that individual judge agents will each use independently to evaluate one target's implementation artifact.
CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`
## User Prompt as Context
{Original user prompt}
## Task Being Repeated
{The common task description shared by all targets in this group}
## Targets in This Group
{List of all targets: file paths, component names, etc.}
## Context
{Any relevant codebase context, file paths, constraints}
## Artifact Type
{code | documentation | configuration | etc.}
## Instructions
CRITICAL: You are generating a REUSABLE spec that will be applied to EACH target independently by separate judges.
- Use generic language: "target file should align with criteria" instead of "all files should align"
- Do NOT include file-specific requirements (e.g., NOT "file should have only authentication logic") if the same spec will be applied to another target which logically cannot fulfill this criteria (e.g. "cart.ts" or "payments.ts" cannot have authentication logic)
- The spec must be applicable to ANY target in this group without modification
- Each judge will receive this same spec and evaluate only its own target against it
User prompt is provided as context, you should use it only as reference of changes that can occur in the project by other agents.
Return only the final evaluation specification YAML in your response.
Shared group meta-judge prompt (ONE per group):
## Task
Generate a COMBINED evaluation specification yaml that covers ALL of the following related tasks. These tasks are interdependent and will be reviewed TOGETHER by a single judge. You will produce rubrics, checklists, and scoring criteria that account for cross-task dependencies and integration points.
CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`
## User Prompt as Context
{Original user prompt}
## Tasks in This Shared Group
{List of all tasks with their targets:
- Task 1: {description} -> {target}
- Task 2: {description} -> {target}
}
## Context
{Any relevant codebase context, file paths, constraints, integration points between tasks}
##
