parallel
npx machina-cli add skill mrsknetwork/supernova/parallel --openclawParallel Execution Skill
Purpose
Parallel execution is a force multiplier, but only when applied correctly. The danger is attempting to parallelize tasks that share state or sequenced dependencies, which produces race conditions, merge conflicts, and corrupted outputs. This skill defines an exact protocol for identifying which tasks are safe to parallelize and how to safely aggregate their results.
SOP: Parallel Execution Workflow
Step 1 - Parallelizability Assessment
Before fanning out, evaluate each candidate task pair:
Safe to parallelize (shared-nothing):
- Two migration files for unrelated tables (e.g.,
productsmigration andreviewsmigration that don't FK to each other). - Two separate UI components with no shared state (e.g.,
<Header />and<Footer />). - Two separate API routes that don't call each other's services.
- Documentation for different modules.
Not safe to parallelize (shared-state risk):
- A migration AND the model/repository that depends on it (must be sequential: schema first).
- Two routes that write to the same table without row-level locking awareness.
- A service that creates a record AND a second service that immediately reads that same record.
- Any two tasks that modify the same file.
Apply the file intersection test: list the files each task will touch. If any files appear in both lists, the tasks cannot run in parallel.
Step 2 - Fan-Out Dispatch
Once safe tasks are identified, dispatch them simultaneously. Track each as a named unit:
Format:
Parallel Batch [N]:
- Unit A: [Task description] -> Owns: [file list]
- Unit B: [Task description] -> Owns: [file list]
- Unit C: [Task description] -> Owns: [file list]
(No file overlap confirmed)
Each unit is independent and must apply the executor skill's standards internally.
Step 3 - Partial Failure Handling
Do not allow one failed unit to silently block aggregation. When any unit fails:
- Mark it as failed in the batch summary.
- Complete all other units that did not depend on the failed one.
- Report the failure clearly before attempting a fix.
- Re-run only the failed unit, not the entire batch.
Never drop a failed task and move on. The system is only as strong as its weakest completed task.
Step 4 - Aggregation and Merge
After all units complete, perform a merge validation:
- No two units created the same import/export name in the same namespace.
- If both units added entries to a shared config file (e.g.,
tailwind.config.ts,alembic/env.py), merge them manually and validate the combined file. - Run a single integration validation after all parallel outputs are merged:
npx tsc --noEmitfor TypeScript,pytestfor Python. Fix any cross-unit conflicts.
Step 5 - Results Matrix Output
Produce a structured summary after the batch completes:
Format:
Parallel Batch [N] Results:
| Unit | Task | Status | Files Created/Modified | Validation |
|------|------|--------|------------------------|------------|
| A | Create <Header /> component | Done | src/components/Header.tsx | tsc: 0 errors |
| B | Create <Footer /> component | Done | src/components/Footer.tsx | tsc: 0 errors |
| C | Create <Sidebar /> component | Failed | - | Missing Shadcn dependency |
Action Required: Unit C - run `npx shadcn@latest add sheet` then re-execute.
Source
git clone https://github.com/mrsknetwork/supernova/blob/main/skills/parallel/SKILL.mdView on GitHub Overview
Parallel execution coordinates independent tasks to reduce total build time. It guards against race conditions by applying a file intersection test to ensure tasks touch disjoint files. The workflow defines how to safely identify, dispatch, and merge results from parallel units.
How This Skill Works
Identify safe tasks that touch disjoint files (shared-nothing) using the file intersection test. Dispatch safe tasks as named units in a Parallel Batch, each owning a specific set of files. After execution, perform a merge validation and a final integration check to ensure cross-unit consistency.
When to Use It
- Plan has tasks in the same phase that do not share data or files and can be safely run concurrently.
- Two migration files for unrelated tables or two separate UI components with no shared state.
- Two API routes that do not call each other's services or modify the same data.
- Documentation or configuration work for different modules that touch different files.
- Performance sensitive builds where reducing total time matters and the tasks are independent.
Quick Start
- Step 1: Parallelizability Assessment - identify candidate task pairs and apply the file intersection test.
- Step 2: Fan-Out Dispatch - group safe tasks into a Parallel Batch with named units and ownership lists.
- Step 3: Partial Failure Handling - monitor units, re-run only failed units after fixes, then merge results.
Best Practices
- Run the file intersection test to confirm shared-nothing tasks before fan-out.
- Identify and lock safe-to-parallelize tasks, then dispatch as independent units.
- Give each unit a clear name and own its touched file list.
- Do not let a single failure block the entire batch; complete other units and re-run the failed one.
- After all units finish, run a merge validation and a single integration check (npx tsc --noEmit or pytest) to verify consistency.
Example Use Cases
- Parallelize two unrelated migrations that touch different tables, so they can run at the same time.
- Run Header and Footer UI component builds in parallel since they do not share state.
- Parallelize two API routes that don’t call one another’s services or write to the same table.
- Parallelize documentation builds for modules A and B that live in separate files.
- Parallelize separate asset pipelines, such as CSS generation and image optimization, when they touch different files.
