Do In Parallel
Batch independent file or target edits by launching parallel sub-agents with grouped meta-judges and LLM-as-a-judge verification.
Overview
Do-in-parallel is an agent skill most often used in Build (also Ship review, Operate iterate) that orchestrates parallel sub-agents with meta-judge and LLM-as-a-judge verification.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill do-in-parallelWhat is this skill?
- Supervisor/orchestrator pattern with parallel sub-agent dispatch across files or targets
- Requirement grouping: repeatable, shared, and independent tasks to reduce redundant judges
- Quality-focused prompts with zero-shot chain-of-thought and mandatory self-critique
- Meta-judge per group or independent task, then parallel implementors with post-task LLM-as-a-judge
- CLI-style arguments for files, targets, model tier (opus/sonnet/haiku), and output path
Adoption & trust: 531 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have dozens of similar agent tasks across files and sequential runs waste time without consistent quality gates.
Who is it for?
Power users running batch codegen, refactors, or audits across many paths who already trust multi-agent tooling in their IDE agent.
Skip if: Single-file one-shot edits or workflows that cannot tolerate parallel writes and merge risk without human review.
When should I use this skill?
You need many independent agent tasks across files or targets and want parallel execution with meta-judge and LLM-as-a-judge verification.
What do I get? / Deliverables
Parallel implementors finish grouped work faster while meta-judges and per-task judges enforce specs aligned to repeatable, shared, or independent requirements.
- Parallel task results at chosen output path
- Judge-verified implementations per grouped requirement
- Documented grouping (repeatable/shared/independent)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build agent-tooling because the skill defines orchestration, prompting, and verification for multi-agent coding runs. Agent-tooling is where supervisor patterns, model selection, and parallel dispatch belong in Prism’s taxonomy.
Where it fits
Apply the same API migration across fifteen route files with one meta-judge spec for shared contracts.
Generate unit test stubs per module in parallel after grouping repeatable test patterns.
Run parallel implementor passes for independent review fixes then judge each diff against criteria.
Patch logging consistency across services concurrently instead of one sequential agent loop.
How it compares
Orchestration workflow for parallel agent batches—not a single-purpose linter or a static code template.
Common Questions / FAQ
Who is do-in-parallel for?
Solo builders and small teams orchestrating Claude/Cursor-style sub-agents across multiple files or targets with structured verification.
When should I use do-in-parallel?
In Build when batching refactors or generated changes; in Ship when parallel review-style passes help; in Operate when iterating fixes across many modules—always when tasks are largely independent.
Is do-in-parallel safe to install?
Check the Security Audits panel on this page; parallel agents can touch many files and run shell—use branches, limits, and manual review.
SKILL.md
READMESKILL.md - Do In Parallel
# do-in-parallel <task> Launch multiple sub-agents in parallel to execute tasks across different files or targets. Analyze the task to intelligently select the optimal model, perform requirement grouping analysis (repeatable, shared, or independent), generate quality-focused prompts with Zero-shot Chain-of-Thought reasoning and mandatory self-critique, then dispatch meta-judges based on grouping (one per group or per independent task, all in parallel), followed by implementors for each task in parallel, with LLM-as-a-judge verification using grouping-appropriate evaluation specs after each completes. </task> <context> This command implements the **Supervisor/Orchestrator pattern** with parallel dispatch, **requirement grouping**, and **meta-judge → LLM-as-a-judge verification**. The primary benefit is **parallel execution** - multiple independent tasks run concurrently rather than sequentially, dramatically reducing total execution time for batch operations. Requirement grouping analysis reduces total agents by sharing meta-judges and judges across related tasks: repeatable groups (same task across targets) share one meta-judge spec, shared groups (interdependent tasks) use one combined judge. 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 </context> **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: 1. Analyze the task, perform requirement grouping analysis, and select optimal model 2. Dispatch meta-judges in parallel based on grouping 3. After each meta-judge completes, dispatch the implementation sub-agent(s) for that group's targets with structured prompts 4. After implementors complete, dispatch judges based on grouping 5. Parse verdict and iterate if needed (max 3 retries per target; for shared groups, retry only failing tasks) 6. 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 r