parallel-build
Skill2 starsChanged 27 days agoMITView on GitHub
Orchestrate a parallel implementation run - split plans into file-disjoint tasks, dispatch parallel-implementer agents in isolated worktrees, merge their branches back one at a time and verify the integrated result. Use in the main session for work sized for 2 or more simultaneous implementers.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- ZachArticulateV/designer-pro-and-seotheir own version, first seen Oct 19, 2026
- Ultimate-Alchemy/claude-skillstheir own version, first seen Oct 15, 2026
- MatanelGordon/skillstheir own version, first seen Aug 21, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- ZachArticulateV/designer-pro-and-seo★ 10same name
- MatanelGordon/skills★ 0same name
- Ultimate-Alchemy/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository28 other files it gives its agents.
- claude/CLAUDE.mdCLAUDE.md
- agent-browserSkill
- animation-vocabularySkill
- apple-designSkill
- benchmark-checklistSkill
- codebase-designSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- emil-design-engSkill
- find-animation-opportunitiesSkill
- grillingSkill
- improve-animationsSkill
- improveSkill
- pick-ui-librarySkill
- plan-executionSkill
- plan-handoffSkill
- portlessSkill
- principle-attack-the-premiseSkill
- principle-fix-root-causesSkill
- prototypeSkill
- receiving-code-reviewSkill
- review-animationsSkill
- shadcnSkill
- supabase-postgres-best-practicesSkill
- testingSkill
- unslopSkill
- vercel-react-best-practicesSkill
- verification-before-completionSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 10 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 7
Run a parallel build for: $ARGUMENTS
- Distinctive: line 9
Run this in the main session.
- Distinctive: line 15
No two tasks in a wave touch the same file.
- Very specific: line 18
Remove only worktrees this run created, and inspect git -C <worktree> status before any forced removal.
- Distinctive: line 22
Every task needs a plan whose in-scope list is the files it owns.
- Very specific: line 24
Make sure .worktreeinclude exists at the repo root, listing untracked files the build needs (local env files, local certs, tool config), …
- Distinctive: line 26
Create it with a commented header even when nothing is needed, and commit it with the base.
- Very specific: line 27
Commit the base and record the branch and SHA.
- Distinctive: line 36
Do not edit the main checkout while they run.
- Distinctive: line 42
Create or check out the integration branch from the recorded base.
- Distinctive: line 44
After each merge run the typecheck or build only.
- Distinctive: line 46
If the conflict shows the plans overlap, stop and send them back to the planning advisor.
- Very specific: line 47
After all merges, run the build and type-check once.
- Very specific: line 52
Add legitimate .worktreeinclude suggestions from the reports and commit them.
- Distinctive: line 53
Delete merged branches and remove this run's worktrees.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run a parallel build for: $ARGUMENTS
Run this in the main session; it owns the worktrees and the merge.
Invariants
- One task, one agent, one worktree.
- Worktrees check out committed state only: commit the base before dispatch.
- No two tasks in a wave touch the same file.
- Merge one branch at a time and verify the integrated result; each worktree only verified itself.
- Dispatch from inside the target repo: the agent's worktree is created from the main session's shell directory.
- Remove only worktrees this run created, and inspect
git -C <worktree> statusbefore any forced removal.
1. Prepare
- Every task needs a plan whose in-scope list is the files it owns. Get plans from the planning advisor if they are missing, and send overlapping ownership back to it.
- Make sure
.worktreeincludeexists at the repo root, listing untracked files the build needs (local env files, local certs, tool config), never production secrets. Find them withgit status --ignored --shortagainst what the build references. Create it with a commented header even when nothing is needed, and commit it with the base. - Commit the base and record the branch and SHA.
An untracked
plans/stays uncommitted and does not block dispatch: you pass each plan's full text in the prompt. - In its own
Bashcall right before each dispatch,cdto the repo root and confirmgit rev-parse --show-toplevel. - At most 4 tasks per wave; finish steps 2-4 of this procedure for one wave before the next.
2. Dispatch
Spawn one parallel-implementer per task, in parallel.
Each prompt holds the plan verbatim, the owned-file list, the repo's install, build and type-check commands, and the reminder that it commits but never pushes or merges and that you maintain plans/README.md.
Do not edit the main checkout while they run.
3. Integrate
- Collect each report's branch, base SHA, tip SHA and completion line.
Hold back partial branches: re-dispatch the remaining work to a fresh
parallel-implementerwhose prompt names the partial branch and its SHAs and tells it togit cherry-pick <base>..<tip>first. - Create or check out the integration branch from the recorded base.
- Merge the branches one at a time, foundational ones first:
git merge --no-ff <branch>. After each merge run the typecheck or build only. - On a merge conflict, abort the merge (
git merge --abort) and dispatchfixerwith both task plans, the conflicting branch and the integration branch, to merge it on the integration branch by the plans' intent. If the conflict shows the plans overlap, stop and send them back to the planning advisor. - After all merges, run the build and type-check once.
Route failures to
fixerwith the output and the list of merged branches.
4. Clean up
- Add legitimate
.worktreeincludesuggestions from the reports and commit them. - Delete merged branches and remove this run's worktrees; list any others to the user.
- Report: tasks completed, merge order, conflicts and how they were resolved, verification results,
.worktreeincludelines added, unrelated failures the workers reported, and worktrees removed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

