ParcelRound — Development skill for Claude Code

Parcel rounds

A method for splitting one body of work across several coding agents at once, without the pieces failing to meet.

It exists because the obvious approach fails in a specific, repeatable way. Give four agents four well-scoped parcels of one feature and you can get four green gates and a feature that does not work — because the work *between* the parcels belonged to nobody, and nothing was looking there. That happened, on a real codebase, and most of what follows is a defence against it.

What's here

METHOD.md	The method. Start here.
CASE-STUDY.md	One round, measured: what it caught, what it cost, what went wrong.
templates/brief.md	A parcel brief. Every section earns its place.
templates/verifier.md	A verifier brief — the agent whose job is to disconfirm.
templates/ledger.md	Drop-in README for the cross-agent ledger.
templates/checklists.md	Dispatch and per-merge checklists.

Is this for you?

**Use it when** there are three or more pieces of work that are each session-sized, mostly independent, and all land in one codebase, and the codebase has a test suite you actually trust.

**Don't** for a single task, for exploratory work where the split isn't obvious yet, or where the pieces can't be tested separately. Two agents on a two-way split is usually slower than doing it yourself, because the brief costs more than the work.

**The bottleneck is not agent count.** It's the lead's capacity to merge and verify, and in practice it's the suite run after each merge. Four parcels is comfortable. Eight is a queue.

The five-minute version

1. List every file each parcel would touch. Anything appearing in three or more columns isn't a conflict to manage — it's the first parcel, and it's yours. Do that refactor first, prove it changed no behaviour, and land it