Herdr Parallel Development

Act as the orchestrator session inside Herdr: run N repo tasks across N git worktrees and N named hc agent terminals, monitor and dynamically schedule reviews and landings as tasks settle, sync remaining branches when prerequisites or early merges advance the target branch, and restore the machine to its starting state.

Trigger Rule

Count deliverables and check the repo's branching model, not keywords. A deliverable is anything that ships on its own: a PR, a feature branch that merges into the integration branch before release, a self-contained fix, refactor, or docs pass. Two or more deliverables without a hard linear dependency mean this skill, always.

• Multi-goal + Git Flow auto-detection: Before writing code on any multi-goal request ("implement X and Y", "fix A, update B, add C"), check whether the repo follows Git Flow or a multi-branch integration model (origin/develop, origin/integration, origin/release/*, .gitflow, or branch rules in AGENTS.md / CONTRIBUTING.md). When it does, each goal is a separate feature/fix branch into $INTEGRATION — switch into orchestrator mode and fan out Herdr agents instead of working in a single process.
• The user need not say "parallel", "herdr", or "worktree". Even small tasks qualify when each needs its own branch or PR.
• Load at planning time, before writing code. If task 1 of N is already underway in a shared checkout, turn that work into row 1's branch and fan out the rest.
• Never serialize execution through one agent or branch; serial per-merge landing (Step 7) is fine, serial execution is not.

When to Use / When NOT to Use