orchestrate

Invoke the orchestrate skill with the plan name, for example "run the user-auth plan". It loads the plan's task files, builds a dependency graph, and spawns ready tasks as parallel tdd-worker subagents in batches until all tasks complete or block.

All run state lives in the plan files on disk, including task statuses, requirement checkboxes, and retry counts. Re-running the orchestrate command resumes exactly where the previous run stopped, treating in-progress tasks as pending.

No. Nothing is committed until the full test suite passes after post-implementation hooks. If tests fail, a git stash isolation step determines whether hook agents or TDD workers caused the breakage before committing or reporting TASKS_BLOCKED.

The plan must exist in the resolved plans directory with a _plan.md file, the project must have .farseer/testing.md configured, plan status must be ready or in_progress, and the current git branch must be feature/{plan-name}.

The run captures a fingerprint of enrolled hook agents at start and passes it to every hook discovery call. If enrollment changes mid-run, the script exits with code 4 and halts execution so the pipeline matches what was reviewed.

Avoid it when no structured plan exists yet, since it requires a plan created by the planner skill. It is also unsuitable when tasks need continuous human judgment, as execution is fully autonomous after invocation.