The Parallel Dispatch Skill.

Most of the productivity gains from Claude Code don't come from the model getting smarter. They come from running more of it at once. The parallel-dispatch skill is a small piece of glue that makes that practical.

You can download this skill from github.com/bogdanbaciu21/skills.

The problem

When a task is big — a migration, a refactor across 40 files, a feature that touches four layers — the natural instinct is to open one chat and start chipping at it. That works, but it leaves a lot of throughput on the table. Claude can easily run five instances in parallel if the work is decomposed cleanly. The bottleneck isn't compute. It's the human decomposition, the file-scope conflicts, and the fact that the agents will forget to close their GitHub issues when they're done.

What the skill does

The skill does not decompose work — that judgment lives with the human, because the trade-offs (what can run in parallel, what must stay serial, where the integration seams go) depend on taste and context the skill doesn't have. What the skill does is take an already-decomposed plan — a list of tracks, each with a handover doc, soldiers (sub-tasks), file scope, and GitHub issues — and emit:

1. Copy-pasteable agent prompts, one per track, formatted as markdown code blocks
2. A coordinator playbook with launch order and post-merge verification
3. A dispatch summary table

Each agent prompt includes hard rules the agent tends to forget:

• Read CLAUDE.md and AGENTS.md before touching anything else.
• Honor the explicit CAN touch and CANNOT touch file lists for this track.
• Do not exit the session until the gated (prerequisite) issue-closure step is complete (do not end the session until you have done BOTH...).

Why the gating matters

On one of my migrations, sixteen issues across two tracks were left open after merge: the code was in, but the issues dangled. The root cause was simple — agents treat "commit and push" as the exit signal, and any instruction after that gets dropped. The prompt template moves closure above the exit signal and bolds it. The coordinator playbook adds a second verification pass. You need both.

File-scope validation

Before generating prompts, the skill cross-references the CAN touch lists across all tracks. If two tracks claim the same file, it stops and flags it. This catches the most expensive class of parallel-dispatch bug — merge conflicts that only appear at integration time — before any agent starts working.

A worked example

Say the task is "add audit logging across API, database, and admin UI."

• Track 1 — API surface
• CAN touch: api/routes/*, api/middleware/audit.ts
• CANNOT touch: db/*, ui/*
• Track 2 — persistence
• CAN touch: db/migrations/*, db/models/audit_log.ts
• CANNOT touch: api/*, ui/*
• Track 3 — admin UI
• CAN touch: ui/admin/audit/*
• CANNOT touch: api/*, db/*

That is parallelizable because the write scopes are disjoint and the integration points are named up front.

How I reconcile the outputs

The coordinator pass at the end does three things:

1. confirm each track respected its file scope
2. pull the changed branches back into one integration pass
3. run one verification checklist against the combined behavior, not just the individual sub-tasks

Parallel work only counts if the merged result is coherent.

What it's not

This skill is formatting and hygiene, not decomposition. If your work plan has overlapping scopes or missing handover docs, the skill will surface that, but it won't fix it. The decomposition is where the judgment lives.

A quick parallelizability checklist

• Are the write scopes disjoint?
• Is there one owner per integration boundary?
• Can each track define success without waiting for another track's code?
• Is the coordinator verification pass obvious before launch?

If any of those answers is "no," it probably should not be parallel-dispatched yet.