agents/skills/orchestrator

Coordinate parallel agents in separate git worktrees by using an orchestrator that delegates implementation to isolated worktree subagents, tracks bead lifecycle status centrally, and enforces deterministic merge-close-commit-remove cleanup flows for each branch.

The safest way to merge worktree subagent branches is through a deterministic merge-close-commit-remove flow that applies safety checks before merging, closes associated beads, commits bead state, and then removes temporary branches and worktrees.

Git worktree subagents handle bead lifecycle tracking by assigning bead ownership to the orchestrator, which creates beads, updates their status during parallel work, and closes or commits bead state only after a successful merge completes.

If a subagent loses its working directory anchor during worktree orchestration, the orchestrator applies explicit cwd re-anchoring failure-mode guardrails to re-establish the correct working directory before proceeding with merges or branch cleanup.

Worktree subagents can be used for cross-repo dispatch, but the orchestrator includes explicit failure-mode guardrails to handle cross-repo worktree placement issues, ensuring dispatch targets the correct repository and branch context.

You should not use parallel worktree subagent orchestration for single-bead coding workflows or when your project lacks a worktree subagent pattern, as the orchestrator requires multi-bead parallel work and bead lifecycle ownership to function correctly.