do-in-parallel

Name: do-in-parallel
Author: NeoLabHQ

874installs132forks

How to install do-in-parallel?

neolabhq/context-engineering-kit/do-in-parallel

$npx -y skills add NeoLabHQ/context-engineering-kit --skill do-in-parallel

Installs into the current project.

Summary

Run independent tasks concurrently across multiple files or targets using parallel sub-agents, with per-task model selection and LLM-as-a-judge verification. Use when tasks do not depend on each other and can run side by side.

Files · 1

View on GitHub

SKILL.md

1	# do-in-parallel
2
3	<task>
4	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.
5	</task>
6
7	<context>
8	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.
9
10
11	Key benefits:
12	- Parallel execution - Multiple tasks run simultaneously
13	- Requirement grouping - Reduces meta-judges and judges by identifying repeatable and shared task patterns
14	- Fresh context - Each sub-agent works with clean context window
15	- Task-specific evaluation - Each meta-judge produces tailored rubrics and checklists for its specific task or group
16	- External verification - Judge applies target-specific meta-judge specification mechanically — catches blind spots self-critique misses
17	- Feedback loop - Retry with specific issues identified by judge
18	- Quality gate - Work doesn't ship until it meets threshold
19
20	Common use cases:
21	- Apply the same refactoring across multiple files
22	- Run code analysis on several modules simultaneously
23	- Generate documentation for multiple components
24	- Execute independent transformations in parallel
25	</context>
26
27	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:
28
29	1. Analyze the task, perform requirement grouping analysis, and select optimal model
30	2. Dispatch meta-judges in parallel based on grouping
31	3. After each meta-judge completes, dispatch the implementation sub-agent(s) for that group's targets with structured prompts
32	4. After implementors complete, dispatch judges based on grouping
33	5. Parse verdict and iterate if needed (max 3 retries per target; for shared groups, retry only failing tasks)
34	6. Collect results and report final summary
35
36	## RED FLAGS - Never Do These
37
38	NEVER:
39
40	- Read implementation files to understand code details (let sub-agents do this)
41	- Write code or make changes to source files directly
42	- Skip judge verification to "save time"
43	- Read judge reports in full (only parse structured headers)
44	- Proceed after max retries without user decision
45	- Wait for one agent to complete before starting another
46	- Re-run meta-judge on retries
47	- Wait to launch implementors until ALL meta-judges have completed
48	- Launch separate meta-judges for tasks that belong to the same repeatable or shared group
49	- Re-launch ALL implementation agents in a shared group when only some failed
50
51	ALWAYS:
52
53	- Use Task tool to dispatch sub-agents for ALL implementation work
54	- Perform requirement grouping analysis BEFORE dispatching any meta-judges
55	- Dispatch meta-judges based on grouping -- all in parallel in a SINGLE response
56	- Do not wait for ALL meta-judges to complete before dispatching implementors, launch them immediately after each meta-judge completes
57	- 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
58	- Pass each target's specific meta-judge evaluation specification to its judge agent
59	- For shared groups, dispatch ONE judge that reviews ALL related changes together
60	- Include `CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}` in prompts to meta-judge and judge agents
61	- Use Task tool to dispatch independent judges for verification
62	- Wait for each implementation to complete before dispatching its judge
63	- Parse only VERDICT/SCORE/ISSUES from judge output
64	- Iterate with feedback if verification fails (max 3 retries

People who liked this also viewed

6 picks

Type

do-in-parallel

874installs132forks

View on GitHub

How to install do-in-parallel?

neolabhq/context-engineering-kit/do-in-parallel

$npx -y skills add NeoLabHQ/context-engineering-kit --skill do-in-parallel

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# do-in-parallel
2
3	<task>
4	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.
5	</task>
6
7	<context>
8	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.
9
10
11	Key benefits:
12	- Parallel execution - Multiple tasks run simultaneously
13	- Requirement grouping - Reduces meta-judges and judges by identifying repeatable and shared task patterns
14	- Fresh context - Each sub-agent works with clean context window
15	- Task-specific evaluation - Each meta-judge produces tailored rubrics and checklists for its specific task or group
16	- External verification - Judge applies target-specific meta-judge specification mechanically — catches blind spots self-critique misses
17	- Feedback loop - Retry with specific issues identified by judge
18	- Quality gate - Work doesn't ship until it meets threshold
19
20	Common use cases:
21	- Apply the same refactoring across multiple files
22	- Run code analysis on several modules simultaneously
23	- Generate documentation for multiple components
24	- Execute independent transformations in parallel
25	</context>
26
27	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:
28
29	1. Analyze the task, perform requirement grouping analysis, and select optimal model
30	2. Dispatch meta-judges in parallel based on grouping
31	3. After each meta-judge completes, dispatch the implementation sub-agent(s) for that group's targets with structured prompts
32	4. After implementors complete, dispatch judges based on grouping
33	5. Parse verdict and iterate if needed (max 3 retries per target; for shared groups, retry only failing tasks)
34	6. Collect results and report final summary
35
36	## RED FLAGS - Never Do These
37
38	NEVER:
39
40	- Read implementation files to understand code details (let sub-agents do this)
41	- Write code or make changes to source files directly
42	- Skip judge verification to "save time"
43	- Read judge reports in full (only parse structured headers)
44	- Proceed after max retries without user decision
45	- Wait for one agent to complete before starting another
46	- Re-run meta-judge on retries
47	- Wait to launch implementors until ALL meta-judges have completed
48	- Launch separate meta-judges for tasks that belong to the same repeatable or shared group
49	- Re-launch ALL implementation agents in a shared group when only some failed
50
51	ALWAYS:
52
53	- Use Task tool to dispatch sub-agents for ALL implementation work
54	- Perform requirement grouping analysis BEFORE dispatching any meta-judges
55	- Dispatch meta-judges based on grouping -- all in parallel in a SINGLE response
56	- Do not wait for ALL meta-judges to complete before dispatching implementors, launch them immediately after each meta-judge completes
57	- 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
58	- Pass each target's specific meta-judge evaluation specification to its judge agent
59	- For shared groups, dispatch ONE judge that reviews ALL related changes together
60	- Include `CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}` in prompts to meta-judge and judge agents
61	- Use Task tool to dispatch independent judges for verification
62	- Wait for each implementation to complete before dispatching its judge
63	- Parse only VERDICT/SCORE/ISSUES from judge output
64	- Iterate with feedback if verification fails (max 3 retries

People who liked this also viewed

6 picks

Type