Guides identification of independent work streams and parallel specialist execution for tasks with multiple separable dimensions (research + implementation + docs). Synthesizes results with integration validation. Use when a more specialized team does not already exist.
When invoked, this skill provides instructions for identifying independent work streams, spawning parallel specialists, synthesizing their results, and validating integration.
When to use: Tasks with 2+ independent work dimensions that can execute simultaneously with minimal interdependencies. Examples: research + implementation + documentation in parallel, frontend + backend + testing concurrently.
When NOT to use: Sequential dependencies prevent parallelization, single-dimensional work, or integration complexity exceeds parallelization value.
Pattern: Sectioning - breaking work into independent subtasks that execute simultaneously.
Key Characteristics:
Use parallel-execution when ALL of these conditions are true:
Multiple Independent Dimensions: Task has 2+ separable work streams (e.g., research one topic while implementing another, document existing code while writing new features)
Minimal Blocking Dependencies: Work streams can progress independently without constant cross-coordination. Some integration at the end is expected, but streams don't block each other during execution.
Clear Specialist Boundaries: Each work stream maps to distinct specialist capabilities (deep-researcher for domain research, code-monkey for implementation, documentation-specialist for docs).
Substantial Scope: Combined work effort > 30 minutes where parallel execution provides meaningful time savings.
Integration Feasibility: Results from parallel streams can be combined with a clear approach (merge implementations, synthesize research findings, integrate documentation).
Do NOT use when:
Follow this process to identify independent work streams:
Ask: "What are the separable dimensions of this work?"
Common Patterns:
For each potential work stream, verify:
Independence Test: Can this stream progress for > 50% of its duration without blocking on other streams?
Specialist Boundary Test: Does this stream require distinct expertise?
Integration Feasibility Test: Can results be combined with a clear approach?
Identify any hard dependencies between streams:
If yes, consider sequential execution or adjust work stream boundaries.
If work stream boundaries are ambiguous or dependencies are unclear, STOP and prompt Addison:
"Bobert has identified potential parallel work streams:
However, [specific uncertainty: unclear dependencies, integration concerns, boundary ambiguity].
Should Bobert proceed with parallel execution, or would sequential execution be more appropriate?"
After identifying work streams, select specialists for each stream:
| Work Stream Type | Specialist Agent(s) |
|---|---|
| Domain research | deep-researcher (with Learning Packets) |
| Codebase exploration | Explore agent (with thoroughness level) |
| Architecture design | Plan agent or adr-maintainer |
| Implementation | code-monkey or domain-specific impl agent |
| Documentation | technical-breakdown-maintainer or doc specialist |
| Testing | Test agent or QA specialist |
| Infrastructure | DevOps agent or platform engineer |
Some streams may require multiple specialists:
Create agent roster with explicit responsibilities:
Agent Roster:
1. [specialist-1]: [Specific work stream responsibility]
- Input: [What they need to start]
- Output: [What they will produce]
- Independence: [Why they can work without blocking others]
2. [specialist-2]: [Specific work stream responsibility]
- Input: [What they need to start]
- Output: [What they will produce]
- Independence: [Why they can work without blocking others]
After parallel specialists complete their work, synthesize results:
Gather completed work from each specialist:
Define how results combine:
Common Integration Patterns:
Check that parallel work aligns:
Record how parallel work was combined:
Validate that synthesized results achieve the original goal:
If validation passes: Proceed to commit phase (delegate to git-historian).
If validation fails: Identify which stream needs remediation:
No external dependencies - This is an instruction-only skill.
Agent Ecosystem Requirements:
Scenario: Build new authentication system requiring domain research, implementation, and documentation.
Work Stream Identification:
Independence: Research can complete independently, implementation can proceed with existing patterns, documentation captures concurrent decisions.
Integration: Research findings validate implementation approach; ADRs document both research conclusions and implementation decisions.
Scenario: New user dashboard feature.
Work Stream Identification:
Sequential Dependency Check: Frontend needs API contract defined before making progress → NOT suitable for full parallelization. Consider: Define API contract first, THEN parallelize implementation.
Adjusted Approach: Sequential design phase, then parallel implementation.
Scenario: Investigate three independent architecture patterns.
Work Stream Identification:
Independence: Three separate research domains with no blocking dependencies.
Integration: Synthesize findings into comparative analysis of architecture options.
When Bobert identifies parallel work:
/parallel-execution
This loads instructions for:
Install the skill:
nix develop .#building --command rebuild <hostname>
ls ~/.claude/skills/parallel-execution/
Test invocation:
When coordinating parallel work, invoke /parallel-execution to load guidance on work stream identification, specialist selection, and result synthesis.
Validation: Skill provides clear decision frameworks for identifying independent work streams and actionable guidance for integration validation.