dispatching-parallel-agents

Name: dispatching-parallel-agents
Author: krzysztofsurdy

18installs1forks

How to install dispatching-parallel-agents?

krzysztofsurdy/code-virtuoso/dispatching-parallel-agents

$npx -y skills add krzysztofsurdy/code-virtuoso --skill dispatching-parallel-agents

Installs into the current project.

Summary

Patterns for effective subagent delegation and parallel execution. Use when a task decomposes into independent subtasks, when research spans multiple areas, when building features that require coordinated specialist work, or when sequential execution is wasting time. Covers work

Files · 1

View on GitHub

SKILL.md

1	# Dispatching Parallel Agents
2
3	Effective orchestration means knowing when to do work yourself and when to delegate it to focused subagents working in parallel. The core insight is simple: independent work should happen concurrently, not sequentially. But "independent" is the load-bearing word - getting decomposition wrong turns parallel execution into a coordination nightmare.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| Independence over coordination \| If two tasks share state, they are one task. Only dispatch work that can complete without cross-agent communication. \|
10	\| Precision over hope \| A subagent brief must be specific enough that the agent cannot misinterpret its scope. Vague briefs produce vague results. \|
11	\| Isolation over sharing \| Each subagent starts with a clean context. It receives exactly what it needs - nothing inherited, nothing ambient. \|
12	\| Synthesis over concatenation \| The orchestrator's job is not to paste outputs together. It is to resolve conflicts, deduplicate, and produce a coherent whole. \|
13	\| Fail fast over fail silent \| Every dispatch includes a failure mode. Subagents report blockers immediately rather than guessing past them. \|
14
15	---
16
17	## When to Parallelize
18
19	\| Signal \| Example \|
20	\|---\|---\|
21	\| Multiple independent areas of investigation \| "How does auth work?" + "How does billing work?" - no shared code path \|
22	\| Research spanning distinct topics \| Investigating a framework upgrade requires checking breaking changes, dependency compatibility, and test coverage separately \|
23	\| Implementation across non-overlapping files \| Backend API + frontend component + database migration touching different file sets \|
24	\| Review of independent subsystems \| Running a reviewer on module A while running a refactor scout on module B \|
25	\| Repetitive tasks with different inputs \| Auditing 5 services for security vulnerabilities - same process, different targets \|
26
27	## When NOT to Parallelize
28
29	\| Signal \| Why Sequential Is Better \|
30	\|---\|---\|
31	\| Output of task A is input to task B \| Pipeline dependency - parallelize within stages, not across them \|
32	\| Tasks modify overlapping files \| Merge conflicts are inevitable and expensive to resolve \|
33	\| Understanding requires full context \| Splitting a single complex investigation loses the thread \|
34	\| The problem is not yet understood \| Parallelize execution, not exploration of unknowns \|
35	\| Fewer than 3 independent units \| Dispatch overhead exceeds time saved \|
36	\| Results must be strictly ordered \| Sequential execution preserves natural ordering without post-processing \|
37
38	---
39
40	## The Dispatch Cycle
41
42	### Phase 1: Identify Independent Work
43
44	Examine the task and list every subtask. For each pair, ask: "Can subtask A complete without knowing the result of subtask B?" If yes for all pairs in a group, that group is parallelizable.
45
46	Actions: Break the task into candidate subtasks. Draw dependency arrows between them. Groups with no inbound arrows from other groups are independent.
47
48	Output: A dependency map showing which subtasks are independent and which form pipelines.
49
50	### Phase 2: Decompose into Dispatch Units
51
52	Each dispatch unit is one subagent's complete assignment. A dispatch unit has a single objective, a bounded scope, and a defined output format. If a unit requires the agent to make judgment calls about scope, it is too vague.
53
54	Actions: For each independent group, define the dispatch unit. Choose the right decomposition pattern (see [Decomposition Patterns](references/decomposition-patterns.md)).
55
56	Output: A list of dispatch units, each with objective, scope boundary, and expected output.
57
58	### Phase 3: Brief Each Agent
59
60	Write a precise brief for each subagent. The brief is the contract between orchestrator and worker. See [Briefing Template](references/briefing-template.md) for the full format.
61
62	Minimum brief contents:
63	- Task objective (one sentence)
64	- Input data or file paths
65	- Expected output format
66	- Explicit out-of-scope boundaries
67	- Failure handling instructions
68
69	### Phase 4: Execute with Isolation
70
71	Launch subagents with clean context. Agents that modify files operate in isolated workt

People who liked this also viewed

6 picks

Type

dispatching-parallel-agents

18installs1forks

View on GitHub

How to install dispatching-parallel-agents?

krzysztofsurdy/code-virtuoso/dispatching-parallel-agents

$npx -y skills add krzysztofsurdy/code-virtuoso --skill dispatching-parallel-agents

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Dispatching Parallel Agents
2
3	Effective orchestration means knowing when to do work yourself and when to delegate it to focused subagents working in parallel. The core insight is simple: independent work should happen concurrently, not sequentially. But "independent" is the load-bearing word - getting decomposition wrong turns parallel execution into a coordination nightmare.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| Independence over coordination \| If two tasks share state, they are one task. Only dispatch work that can complete without cross-agent communication. \|
10	\| Precision over hope \| A subagent brief must be specific enough that the agent cannot misinterpret its scope. Vague briefs produce vague results. \|
11	\| Isolation over sharing \| Each subagent starts with a clean context. It receives exactly what it needs - nothing inherited, nothing ambient. \|
12	\| Synthesis over concatenation \| The orchestrator's job is not to paste outputs together. It is to resolve conflicts, deduplicate, and produce a coherent whole. \|
13	\| Fail fast over fail silent \| Every dispatch includes a failure mode. Subagents report blockers immediately rather than guessing past them. \|
14
15	---
16
17	## When to Parallelize
18
19	\| Signal \| Example \|
20	\|---\|---\|
21	\| Multiple independent areas of investigation \| "How does auth work?" + "How does billing work?" - no shared code path \|
22	\| Research spanning distinct topics \| Investigating a framework upgrade requires checking breaking changes, dependency compatibility, and test coverage separately \|
23	\| Implementation across non-overlapping files \| Backend API + frontend component + database migration touching different file sets \|
24	\| Review of independent subsystems \| Running a reviewer on module A while running a refactor scout on module B \|
25	\| Repetitive tasks with different inputs \| Auditing 5 services for security vulnerabilities - same process, different targets \|
26
27	## When NOT to Parallelize
28
29	\| Signal \| Why Sequential Is Better \|
30	\|---\|---\|
31	\| Output of task A is input to task B \| Pipeline dependency - parallelize within stages, not across them \|
32	\| Tasks modify overlapping files \| Merge conflicts are inevitable and expensive to resolve \|
33	\| Understanding requires full context \| Splitting a single complex investigation loses the thread \|
34	\| The problem is not yet understood \| Parallelize execution, not exploration of unknowns \|
35	\| Fewer than 3 independent units \| Dispatch overhead exceeds time saved \|
36	\| Results must be strictly ordered \| Sequential execution preserves natural ordering without post-processing \|
37
38	---
39
40	## The Dispatch Cycle
41
42	### Phase 1: Identify Independent Work
43
44	Examine the task and list every subtask. For each pair, ask: "Can subtask A complete without knowing the result of subtask B?" If yes for all pairs in a group, that group is parallelizable.
45
46	Actions: Break the task into candidate subtasks. Draw dependency arrows between them. Groups with no inbound arrows from other groups are independent.
47
48	Output: A dependency map showing which subtasks are independent and which form pipelines.
49
50	### Phase 2: Decompose into Dispatch Units
51
52	Each dispatch unit is one subagent's complete assignment. A dispatch unit has a single objective, a bounded scope, and a defined output format. If a unit requires the agent to make judgment calls about scope, it is too vague.
53
54	Actions: For each independent group, define the dispatch unit. Choose the right decomposition pattern (see [Decomposition Patterns](references/decomposition-patterns.md)).
55
56	Output: A list of dispatch units, each with objective, scope boundary, and expected output.
57
58	### Phase 3: Brief Each Agent
59
60	Write a precise brief for each subagent. The brief is the contract between orchestrator and worker. See [Briefing Template](references/briefing-template.md) for the full format.
61
62	Minimum brief contents:
63	- Task objective (one sentence)
64	- Input data or file paths
65	- Expected output format
66	- Explicit out-of-scope boundaries
67	- Failure handling instructions
68
69	### Phase 4: Execute with Isolation
70
71	Launch subagents with clean context. Agents that modify files operate in isolated workt

People who liked this also viewed

6 picks

Type