agentleFS
theishandubeytheishandubey/dotclaude/skills/parallel-build/SKILL.md

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

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
  1. Distinctive:

    Run a parallel build for: $ARGUMENTS

    line 7
  2. Distinctive:

    Run this in the main session.

    line 9
  3. Distinctive:

    No two tasks in a wave touch the same file.

    line 15
  4. Very specific:

    Remove only worktrees this run created, and inspect git -C <worktree> status before any forced removal.

    line 18
  5. Distinctive:

    Every task needs a plan whose in-scope list is the files it owns.

    line 22
  6. Very specific:

    Make sure .worktreeinclude exists at the repo root, listing untracked files the build needs (local env files, local certs, tool config), …

    line 24
  7. Distinctive:

    Create it with a commented header even when nothing is needed, and commit it with the base.

    line 26
  8. Very specific:

    Commit the base and record the branch and SHA.

    line 27
  9. Distinctive:

    Do not edit the main checkout while they run.

    line 36
  10. Distinctive:

    Create or check out the integration branch from the recorded base.

    line 42
  11. Distinctive:

    After each merge run the typecheck or build only.

    line 44
  12. Distinctive:

    If the conflict shows the plans overlap, stop and send them back to the planning advisor.

    line 46
  13. Very specific:

    After all merges, run the build and type-check once.

    line 47
  14. Very specific:

    Add legitimate .worktreeinclude suggestions from the reports and commit them.

    line 52
  15. Distinctive:

    Delete merged branches and remove this run's worktrees.

    line 53

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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> status before any forced removal.

1. Prepare

  1. 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.
  2. Make sure .worktreeinclude exists at the repo root, listing untracked files the build needs (local env files, local certs, tool config), never production secrets. Find them with git status --ignored --short against what the build references. Create it with a commented header even when nothing is needed, and commit it with the base.
  3. 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.
  4. In its own Bash call right before each dispatch, cd to the repo root and confirm git rev-parse --show-toplevel.
  5. 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

  1. 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-implementer whose prompt names the partial branch and its SHAs and tells it to git cherry-pick <base>..<tip> first.
  2. Create or check out the integration branch from the recorded base.
  3. Merge the branches one at a time, foundational ones first: git merge --no-ff <branch>. After each merge run the typecheck or build only.
  4. On a merge conflict, abort the merge (git merge --abort) and dispatch fixer with 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.
  5. After all merges, run the build and type-check once. Route failures to fixer with the output and the list of merged branches.

4. Clean up

  1. Add legitimate .worktreeinclude suggestions from the reports and commit them.
  2. Delete merged branches and remove this run's worktrees; list any others to the user.
  3. Report: tasks completed, merge order, conflicts and how they were resolved, verification results, .worktreeinclude lines added, unrelated failures the workers reported, and worktrees removed.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.