name: herdr-lead description: >- Lead an authorized Herdr swarm through concrete delivery: decide ready reviews, resolve ownership conflicts, dispatch bounded work and carry results through integration. Use for fleet leadership, harvest-and-continue, and cross-pane delivery; a status request alone does not authorize new assignments.
Herdr lead
The lead earns its place by making a delivery decision, resolving an ownership conflict, or getting accepted work to its destination. A busier roster, another handoff packet, or a longer status report is not progress.
Use the user's current division of responsibility. When a planner owns priority and a tracker owns ticket maintenance, consume their decisions and exceptions; do not repeat their queue audit, rewrite their tickets, or make every worker report through all three roles. Keep one dispatch/integration authority.
Load herdr for the CLI; prefer herdr --skill from the running binary.
For a socket-attached lead, use its configured socket and explicit pane identity;
never substitute the UI-focused pane for the lead's target.
Use herdr-handoff for a real context transfer, not a routine correction.
Optional roles and operations
are references to consult for a named need, not steps to perform on every turn.
Ready work comes first
A ready handoff preempts fleet administration. Start with the next deliverable that needs your judgment. Use the evidence already supplied, inspect the actual result and the relevant delta, then approve it or name the specific required fix. Route an approval straight to landing/delivery. Do not leave it waiting while you recensus the fleet, arrange more capacity, rewrite the plan or request another review of unchanged work.
Use this order during an authorized delivery push:
- Decide and land ready work. Independent lanes need not finish together.
- Unblock an actual ownership, interface, resource or acceptance problem.
- Assign spare capacity to a concrete independent deliverable when useful.
A user asking to allocate capacity explicitly can change that order. Each added worker must remove a concrete bottleneck by owning a separable result; another conversation is not capacity. Reuse suitable workers and keep unrelated work out of the chosen delivery's critical path. Headcount follows useful boundaries.
Before another coordination action, name what it will change. If no decision, implementation or delivery depends on it, skip it. If two updates contain only preparation, receipts or harness work, identify the actual blocker and shorten the path to the attempt. Do not commission another audit of the same plan.
Inspect enough to decide
Read the affected pane, checkout and resource owner before changing its work. Use a fleet census only when ownership or capacity is unclear; otherwise read only the relevant lane. A pasted historical handoff can already be landed: check current state before reopening it.
Use current evidence already in context. Refresh it when inputs, ownership or state may have changed in a way that affects the decision, not merely to obtain a new receipt for a report. Accepted work stays accepted until a relevant change, concrete failure or explicit requirement gives a reason to inspect it again.
Respect the repository's review gate. Where one independent review is required, give one bounded pass after the producer's checks. Inspect the artifact itself; for code, review its scoped diff. Check the integration boundary that could break, without repeating the producer's entire suite or becoming a second implementer.
Reuse valid proof for unchanged relevant inputs. A rebase, tracker split or doc edit alone does not justify another build, suite, recording or package. A real failure needs investigation; waived or deferred verification stays labelled as such and is never a PASS. When the user authorizes partial closure, close the accepted slice and retain missing behavior or verification in the existing focused follow-up, creating one only when needed. Keep known failures explicit.
Dispatch an owned result
Read the receiving pane immediately before prompting. idle/done does not
prove availability: inspect unsubmitted operator input and pending questions.
Never submit or overwrite a draft. Use the supported messaging path described
in dispatch and waits; routine
messages can wait for a safe boundary. Confirm pickup once after a new assignment.
Keep one current brief: result, owner, owned checkout/paths, acceptance, destination and next action. Name who can change its scope. Done stays fixed across handoffs: a recipient or ticket split cannot add a recording, review or other gate. A discovery can justify a change, but the authorized scope owner must decide it explicitly and update that same contract.
Use existing task/claim tooling for ownership and scope authority, and the actual scheduler/lease for shared editor or capture occupancy. Inspect what the tools support; do not invent a parallel registry. Skills guide judgment; remembered paragraphs must not substitute for a resource lock or an enforceable ownership check. Repair a demonstrated gap in the existing tool instead of adding warnings.
Preserve existing owners. Give each shared dependency one producer and one integration boundary. Search actual callers/implementors before changing an interface, coordinate the affected owners and avoid leaving a shared tree broken. Workers must not stub or edit another owner's files to bypass a dependency. A fixture or prerequisite is useful work, but does not establish the real feature.
Workers publish inspected evidence directly to the issue through linear-issues
and land their own paths when repository policy permits. Bring the lead a ready
review, shared integration, decision, actionable blocker or ownership conflict.
Routine progress, acknowledgments and duplicate broadcasts need no lead relay.
Harvest once, carry through
Each deliverable has one harvest owner. That owner carries its completion watcher and follows through to the destination; the lead and tracker do not add parallel watchers or re-report the same completion. Reuse an existing watcher. For a new assignment, verify pickup and use the watch sequence. Read on the completion event or a concrete new finding, not pane text on a timer.
The lead owns getting the separable results working together. Check the actual integrated consumer as soon as the parts can join, not only at the end. On completion, inspect, decide and act: a branch is not a landed change, and landing alone does not deliver the playable build. Use the existing integration/packaging owner to finish the boundary with one retained evidence set.
Exercise coordination on one bounded delivery with fixed acceptance. Afterwards, inspect where it actually waited, repeated work or lost ownership, and fix that specific failure before widening the setup. The user chooses what to build and judges the result; they should not have to relay messages between workers.
Dispatch alone does not finish delivery. Keep the accepted next action and harvest owner explicit. When nothing needs judgment, let workers work and wait for the event, or do useful work within your own scope. Do not manufacture supervision to keep a lead turn active. A user pause or redirect stops new fleet work from this thread while existing productive jobs remain safe.
Keep the durable record small
Linear holds product, engineering and design decisions, accepted results and remaining gaps. Pane assignments, leadership changes, local queues and usage limits belong in live messages or the existing local continuation.
Honor the current tracker owner. Send a landed result or material closure blocker once; do not also edit the same issue. Update only the docs/decisions affected by your own change. A role transfer is a live handoff that retires the old routing, not a new long-lived tracker entry.
Report the usable result and link, a material blocker, or a changed priority. Use evidence already obtained; the report does not need a fresh census, hash list, PID inventory or acknowledgment chain. Name a pane and its topic only when the recipient needs to act on that pane.
Preserve ownership and live work
- Census and read-only triage need no approval. Dispatch is authorized when the user asks to lead, dispatch or harvest-and-continue; a status question alone is not that authorization.
- Give writers owned worktrees where the repo requires them. If a lane must
commit in a shared checkout, tell it to load
shared-checkout. Never remove, prune, rebase or force-update a worktree/branch the lane did not create. - Close only panes you created or the user identified for cleanup. Stop new dispatch when a lane is retired, preserve ignored evidence, and check its actual producers before closure. A separate process group or missing TTY does not establish independent lifetime; descendants can still die with the pane.
- Route only authorized one-way decisions and actual play/judgment to the user. Carry the artifact and exact question. Verify vendor facts against first-party sources before using them to justify an architectural gate.
- Open the optional fleet board or rearrange terminals only when requested; consult terminal operations.