Orchestrate herdr

Fan work out to one herdr-managed worker tab per unit (tracker sub-issue or harness prompt) and drive each to a test-backed end state when the task involves code. You are the orchestrator: never implement, never close your own tab.

Inputs

Run mode — spec when SPEC_REF is present; otherwise harness per references/harness.md. Never guess an input.

• SPEC_REF (spec mode) — parent issue whose open sub-issues become workers: Linear PRWL-100 / ABC-123, or a GitHub issue URL or number. From skill args (SPEC_REF=..., bare reference; legacy SPEC_URL=/PRD_URL= accepted) or intake.
• WORKERS (harness mode) — list of {label, prompt}; defined per harness reference.
• AGENT — worker runtime. Its CLI_NAME launch token serves PATH checks/tab labels; AGENT_KIND serves herdr --kind. Both come from references/intake.md, never the command's first token: Cursor's values differ.
• CODING_CLI — CLI_NAME plus the permission-mode flags from the user's established preference or intake choice. The prompt is never a launch argument (see Rules).
• ISOLATION — worktree, branch, or shared; it decides whether workers can run in parallel.
• TRACKER / TRACKER_TAG — workspace tracker of record (G / L). Derived per Resolve in references/tracker-map.md, which holds the per-tracker commands cited by bold section name below.

Factory stage. Under a user-started /factory run on herdr, follow references/factory-stage.md instead of Intake.

Rules