parallel-agent-delivery
Splits work across multiple agents or sessions running at once, keeping their surfaces disjoint so results merge cleanly. Use this when facing several independent tasks with no shared state, when a plan has parallelizable steps, when a broad search or audit would be faster fanned
Install
npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/technology/skills/parallel-agent-delivery
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart
git clone https://github.com/cbrock84/headcount.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Parallel agent delivery
Parallelism is a property of the work, not a preference. Establish it before dispatching.
When it is safe
All three must hold:
- Disjoint write surfaces — no two agents touch the same file. Not "unlikely to conflict"; provably disjoint.
- No sequential dependency — none needs another's output to start.
- Independently verifiable — each result can be judged on its own.
Fail any one and run sequentially. Two agents editing one file produces a merge conflict at best and a silent lost update at worst.
Dispatching
Each agent gets a self-contained brief: the goal, its exclusive surface, the context it cannot see for itself, and the shape of the answer expected. Agents share no memory — anything you leave out is gone.
Ask for a structured return, the same shape from each, so results can be compared rather than re-read.
Read-only fan-out is the easy case
Searching, auditing, and reviewing have no write surface at all, so they parallelize without risk. Reach for parallelism here first and freely.
Integrating
- Review each result against its brief before merging any of them.
- Where two disagree on a shared fact, neither is authoritative — resolve it yourself.
- One agent returning nothing useful is a normal outcome, not a failure to retry blindly.
Sources
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
Never
- Split work to look faster when the steps are actually sequential.
- Let two agents write to one surface because "they probably won't collide."
- Merge a result you have not read.
Files (headcount)
-
references
-
sources.md 827 B
# Sources — `technology:parallel-agent-delivery` <!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. --> Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce. ## Git reference manual Git project · global · **read and cite only — copyrighted, do not reproduce** <https://git-scm.com/docs> **Authoritative for:** What a Git operation actually does — what a worktree is, what rebase rewrites, what detached HEAD means. It settles behavior, not which workflow a team should adopt. --- Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.
-
-
SKILL.md 2.2 KB
--- name: parallel-agent-delivery description: Splits work across multiple agents or sessions running at once, keeping their surfaces disjoint so results merge cleanly. Use this when facing several independent tasks with no shared state, when a plan has parallelizable steps, when a broad search or audit would be faster fanned out, or when deciding whether work can safely be split at all. --- # Parallel agent delivery Parallelism is a property of the work, not a preference. Establish it before dispatching. ## When it is safe All three must hold: 1. **Disjoint write surfaces** — no two agents touch the same file. Not "unlikely to conflict"; provably disjoint. 2. **No sequential dependency** — none needs another's output to start. 3. **Independently verifiable** — each result can be judged on its own. Fail any one and run sequentially. Two agents editing one file produces a merge conflict at best and a silent lost update at worst. ## Dispatching Each agent gets a self-contained brief: the goal, its exclusive surface, the context it cannot see for itself, and the shape of the answer expected. Agents share no memory — anything you leave out is gone. Ask for a **structured return**, the same shape from each, so results can be compared rather than re-read. ## Read-only fan-out is the easy case Searching, auditing, and reviewing have no write surface at all, so they parallelize without risk. Reach for parallelism here first and freely. ## Integrating - Review each result against its brief before merging any of them. - Where two disagree on a shared fact, neither is authoritative — resolve it yourself. - One agent returning nothing useful is a normal outcome, not a failure to retry blindly. ## Sources `references/sources.md` in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding. ## Never - Split work to look faster when the steps are actually sequential. - Let two agents write to one surface because "they probably won't collide." - Merge a result you have not read.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.