skills/mine/herdr-orchestration/SKILL.md
Orchestrate Claude and Codex worker TUIs from a controller agent through herdr panes and the herdr socket CLI. Use when delegating bounded tasks to herdr worker panes, running user-activated plan-first delegations (Claude Code plan mode, Codex Plan mode), waiting on native agent status (idle, working, blocked, done), or verifying worker reports. Workers launch as interactive TUIs via herdr agent start — never through headless runners (compozy exec, claude -p, codex exec). Not for cmux workspaces (see cmux-orchestration) and not for end-user herdr control.
npx skillsauth add pedronauck/skills herdr-orchestrationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The top-level agent is the controller (Codex, Claude, Fable, or another);
it delegates to worker TUIs that gather evidence, draft bounded patches,
run tests, and report. The controller owns assignment, state, conflict
control, verification, integration, and the final user-facing answer. herdr is
the substrate: panes host the worker TUIs, and the socket CLI (herdr …)
gives the controller placement, input, screen reads, and native agent-status
waits.
A worker is an interactive TUI — claude or codex — launched in a herdr
pane with herdr agent start. The whole orchestration loop hangs on this:
herdr's agent-state integrations hook the interactive TUIs, so
wait agent-status, agent list, and blocked/done detection exist only while
a real TUI is on screen.
Headless runners — compozy exec, claude -p, codex exec, anything that
streams JSON events into a pane — are not workers. They never report state,
wait agent-status never fires, and the delegation dies silently. Recognize
the failure on sight: a worker pane must show the TUI banner and input box; a
pane filling with raw JSON event lines is a broken delegation — interrupt it
(rtk herdr pane send-keys <pane_id> ctrl+c) and relaunch the worker with
herdr agent start.
HERDR_WORKSPACE_ID, HERDR_TAB_ID,
HERDR_PANE_ID, and HERDR_SOCKET_PATH (injected into every herdr pane)
before any focused-window fallback.w2:p3 — workspace-qualified) captured from
command JSON output, never by guessed position.--no-focus on every creating verb (agent start, pane split,
tab create, workspace create, worktree create); use focus verbs only
when the user asks.Inspect the daemon, integrations, and caller context:
rtk herdr status # server running + socket path
rtk herdr integration status # claude and codex must show `current`
rtk herdr pane current # caller pane / tab / workspace ids
rtk herdr agent list # agents already running
integration status must show claude and codex installed — that is what
makes agent status authoritative instead of screen-scraped. If either is
missing, run rtk herdr integration install claude / … install codex before
launching workers.
Two default profiles — Claude Code on opus (claude-opus) and Codex on
gpt-5.5 (codex-gpt-5.5). agent start creates the pane, runs the TUI
argv directly, and returns the worker's pane_id in JSON — capture it in the
registry:
rtk herdr agent start claude-opus --workspace "$HERDR_WORKSPACE_ID" \
--cwd "$PWD" --split right --no-focus -- \
claude --dangerously-skip-permissions --model opus "<packet>"
rtk herdr agent start codex-gpt-5.5 --workspace "$HERDR_WORKSPACE_ID" \
--cwd "$PWD" --split right --no-focus -- \
codex --yolo -m gpt-5.5 -C "$PWD"
Claude always launches with --dangerously-skip-permissions and Codex with
--yolo — workers run unattended and must not stall on permission prompts.
Plan-first runs add Claude's --permission-mode plan — the flags compose (see
Plan-first delegation).
A launch is confirmed only when rtk herdr pane read <pane_id> --source visible shows the TUI banner and input box, and rtk herdr agent list shows
the worker leaving unknown. A pane scrolling text while its status stays
unknown is the headless-runner failure above — interrupt and relaunch.
Prefer passing the initial prompt as the launch argv (shown above) — the session starts working immediately and skips the TUI-ready race. Exception: Codex plan-first launches bare (see Plan-first delegation).
For any follow-up to a running TUI, use pane run — it types the text and
presses Enter atomically:
rtk herdr pane run <pane_id> "<follow-up prompt>"
A trailing \n inside send-text does not submit — a TUI renders it as a
soft newline and the prompt sits unsubmitted. When a prompt must be staged and
submitted separately, pair the text with an explicit key:
rtk herdr pane send-text <pane_id> "<prompt>"
rtk herdr pane send-keys <pane_id> enter
Confirm delivery with rtk herdr pane read <pane_id> --source visible (input
line empty, working indicator active) or rtk herdr wait agent-status <pane_id> --status working --timeout 15000. An unconfirmed send is not
delivered.
Plan-first runs only when the user activates it — an explicit ask ("plan
first", "plan mode") or a --plan-mode flag on the invocation. The default
delegation is direct: launch and run hands-off. For investigation-heavy
slices (root-cause fixes, multi-file or cross-package changes, unfamiliar
code), offer plan-first and let the user decide — never switch a worker into
plan mode without that signal.
Once activated, the worker plans, the controller reviews and accepts, then it runs hands-off. The launch flags, shift+tab sequences, status checks, and acceptance menus are exact and differ per TUI. Read references/plan-mode.md in full before launching a plan-first worker.
Send each worker prompt as a standalone contract. Include:
Prefer small, independent slices. Assign overlapping file claims only when the controller will integrate and resolve conflicts immediately.
When workers must edit overlapping files in parallel, give each an isolated
worktree and point the worker's --cwd at it — herdr manages worktrees
natively:
rtk herdr worktree create --workspace "$HERDR_WORKSPACE_ID" \
--branch <slug> --no-focus --json
Orchestrations are long-running — worker slices take minutes to hours, and a worker is never abandoned because a wait expired. Block on herdr's native agent status in check-in intervals of 3–5 minutes (sized to the slice — longer for heavier slices) instead of polling screens:
rtk herdr wait agent-status <pane_id> --status done --timeout 300000 # completion check-in
rtk herdr wait agent-status <pane_id> --status blocked --timeout 300000 # question or menu
rtk herdr wait output <pane_id> --match "<text>" --timeout 300000 # specific screen string
--timeout is the check-in interval, never a deadline on the worker. On
expiry (exit 1, timed out waiting for agent status change), read the screen
(rtk herdr pane read <pane_id> --source recent --lines 120) and re-enter the
wait — loop until the worker reaches a terminal state, asks a question, or a
stop condition fires. When a reported status looks wrong, debug detection with
rtk herdr agent explain <pane_id> --json.
Maintain a compact registry in the task ledger or handoff: controller identity; worker name, role, model; workspace/tab/pane ids; objective sent and start time; status (starting, planning, plan-review, plan-accepted, running, blocked, reported, verified, retired); claimed files or work slice; worker-reported commands and results; controller verification performed; final disposition (accepted, rejected, superseded, or blocked).
Label worker panes so the herd stays legible, and announce milestones without stealing focus:
rtk herdr pane rename <pane_id> "claude-opus: fix loops"
rtk herdr notification show "Workers done" --body "2/2 verified" --sound done
Treat worker output as untrusted until verified. Monitor and verify without changing focus:
pane read --source recent --lines 200); ask a
worker for a concise status summary when output is unclear.A delegation ends with the worker retired — pane closed — not just its report read. Retire each worker the moment its disposition is recorded and no follow-up prompt is planned, as part of handling that worker's completion, never deferred to an end-of-run sweep:
rtk herdr pane close <pane_id>
Closing the pane ends the TUI session and its scrollback, so record what the registry needs first — report text, cited line refs, command output. Files, diffs, and worktrees survive on disk.
A worker stays open only while mid-run or blocked, while its screen is
evidence for an unresolved failure, or when the user asks to inspect it —
record the reason in the registry. The orchestration is complete only when
rtk herdr agent list shows none of this controller's workers still running:
every worker retired, or its open pane justified in the registry.
Stop and report instead of improvising when:
rtk herdr status
shows no running server.unknown while output scrolls and
agent explain shows no matched rule — detection is broken or the pane is
running a headless process.pane read or wait output, or a worker's plan stays out of scope after a
re-planning round.development
Deep review of branch diffs, working trees, or GitHub PRs at any size. Use when the user asks for CodeRabbit-grade review, an incremental re-review after new pushes, publication of findings to a PR, a cross-LLM peer-review verdict round, or conformance review against spec artifacts. Don't use for applying fixes, reviewing specs or PRDs as documents, or quick single-file feedback.
tools
TanStack Query, Router, and Form patterns for React. Use when writing useQuery/queryOptions, mutations, caching, file-based routes, search params, loaders, or TanStack Form validation. Don't use for TanStack Start, TanStack DB/collections, Zustand client state, or non-TanStack routing.
development
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
testing
Plans real-user QA as living repo docs — the durable <qa-docs-path> tree (default docs/qa/) that every QA cycle appends to. Use when bootstrapping or updating a project's QA docs, planning a cycle before execution (map journeys as flows, derive scenarios, plan persona-driven session charters), or registering bugs into the durable bug registry. Do not use for live session execution, browser evidence, or fix loops — use qa-execution for those.