wt-pack

Spawn, list and remove the named herdr agents this pack hands work to — planners, which start in the main checkout because their first job is to create a worktree, and workers, which start inside one. Keeps every agent named, which herdr does not do reliably on its own, so a pool stays addressable by name instead of only by pane id. Use when asked to spawn or add a planner or a worker, to remove or clean up one, or to see what the pools currently hold. Called by wt-plan's handoff; also useful invoked alone.

Ask the user a question from an agent pane, as a room chip and Inbox card in wt-dashboard. Use when you need the user's input from a room, handoff or dispatch context — not your own chat session, which already has the native question tool. Needs wt-dashboard (the full ./setup install, not the plugin alone).

The auditor role's loop — a PM+QA pass over whatever project it is started in (its apps, CLIs, tests and docs): use the product as a user would, read what changed recently, file findings on the project's board and post a ranked list of what to fix or improve next. Proposals only: never commits, never edits code, never hands off; the orchestrator schedules. Use when started as an auditor (`wt-agents spawn auditor`), or when asked to audit a project or suggest what to work on next.

Watch an open pull request until it is merge-ready, reacting to review comments, failing CI and a stale base as each arrives, and reporting honestly where it stopped. Promotes a draft out of draft once CI is green, because a draft has no review stream to react to and review is what it is waiting for. Use after wt-ship has opened a PR, or when asked to watch, babysit or keep an eye on a PR over time. Not for resolving one round of feedback already sitting on a PR, and not for reviewing someone else's changes.

Record what a piece of finished work taught, as a durable repo learning — but only when the reasoning is absent from the code, the tests, the plan and the existing docs, and only after its claims are verified against the tree. Draws on what research disproved and what review corrected rather than re-investigating, then checks findability and vocabulary so the next agent actually retrieves it. Use after work is verified and about to ship, or when asked to write up a learning or convention. Called by wt-ship. Not for routine fixes whose own diff explains them.

The local wt-dashboard (herdr agent control room) at http://127.0.0.1:7777 and its macOS app. Use when asked to open, start, restart or debug the dashboard, find its data or logs, or change its server/web/app code. Needs wt-dashboard (the full ./setup install, not the plugin alone).

Retire a finished worktree: leave it, delete the directory, and delete the branch — after establishing that nothing is lost by doing so. Use when work on a worktree is done and merged, when asked to clean up or remove a worktree, or to tidy up stale worktrees from earlier tickets. Not for stepping out of a worktree you intend to come back to — that is ExitWorktree with keep.

Hand a prompt to a herdr agent — a free worker from the repo's pool, a named pane, or a freshly spawned one — as a plain prompt (a /goal only with --goal), and leave both ends aware of each other: the target pane is labelled with the task (shown in wt-dashboard) and told who sent it and how to reply; the sender is told where it went. Use when handing off a plan or any work prompt to another agent instead of the clipboard. Called by wt-plan's handoff step; also useful invoked alone.

Durable agent preferences shared by every agent runtime — global, per role and per project markdown under ~/.config/wt-memory, injected into Claude Code sessions by the wt-memory plugin. Use when asked to remember, set, show or change a standing preference for agents, or to debug what preferences an agent received.

The wt-pack Claude Code mods — the instant `/wt <room|ticket|dnd|herd|watch> …` command and per-request model routing. Part of the wt-pack plugin; not something to invoke by name.

Take a ticket from named to planned, reviewed and committed, in an isolated git worktree, then hand it off. Resolves the ticket and the integration branch, creates the worktree, runs sharded research through wt-research, asks only shape-changing questions, writes the plan inline with the research absorbed into it as quoted evidence, self-traces, sizes a review through wt-review, applies the findings, commits the plan, and emits a handoff prompt for wt-work. Use when the user says "worktree and plan", "start <TICKET>", "plan <TICKET> in a worktree", or otherwise asks to begin a ticket in isolation and plan it before writing code. Also use when a plan is wanted for work that must not touch the current checkout.

Push the current branch and open a DRAFT pull request whose body carries what a reviewer needs — what the change does, what research corrected about the ticket, what review corrected about the implementation. Refuses a dirty tree, a detached HEAD and the base branch itself, and never promotes a PR out of draft. Use when implemented and verified work is ready to be published for review. Called by wt-ship. Not for updating an existing PR's body or resolving its feedback.

Gather evidence about a ticket or a change against the real code, sharded by question type and returned as structured findings rather than a prose report. Verifies what the ticket claims AND sweeps for what nobody named, reads installed dependency behaviour from the package rather than from docs or memory, and returns records with verdicts, quoted evidence and confidence. Use when starting a ticket, before writing a plan, when a ticket's claims need checking against the current code, or when asked "what does this change actually touch". Called by wt-plan; also useful invoked alone on a ticket or an existing plan.

Review a plan or a diff with a lens set computed from what the target actually touches, rather than a fixed reviewer panel. A plan always gets coherence and feasibility; a diff always gets correctness and regression; both add standards, testing, learnings, security, data, scope or adversarial only when the target's own content triggers them, and bundle lenses into as few agents as possible. Checks the change against the repo's documented rules and its recorded learnings, so earlier work is read rather than only written, and hands reviewers the findings table so they verify unsourced claims instead of re-deriving the codebase. Use when a plan, spec or requirements document needs reviewing before implementation, or when implemented work needs reviewing before it ships. Called by wt-plan and wt-ship; also useful invoked alone.

Create, check and tune a project's own role instructions — per-role override files and named personas (e.g. a frontend worker, a QA reviewer) kept in the repo at .wt-pack/roles/ or at user level in ~/.config/wt-pack/projects/<repo>/roles/. Use when asked to "create a role", "add a persona", "add a QA persona", "change how the worker behaves in this project", or when a role keeps getting the same project-specific correction. Not for personal preferences across projects (that is wt-memory).

Chat rooms in wt-dashboard shared by the user and agents. Use when a prompt starts with "<room-message …>" (or the older "[room

Install, check, or remove wt-pack on this machine by running the repo's `./setup` script: links the skills, installs the wt-memory plugin, builds the dashboard and runs it under launchd, and reports what is missing. Use when asked to install, set up, bootstrap, repair or doctor wt-pack, to check whether wt-pack is working, or to uninstall it. Not for configuring a single skill.

Finish implemented work: simplify the changed code, review the diff with a lens set sized from what it touches, record what was learned, and open a draft pull request — in that order, from a single read of the diff. Orchestrates wt-simplify, wt-review, wt-compound and wt-pr. Use after an implementation is complete and verified, when handed off from wt-work, or when asked to wrap up, tidy and open a PR for work already written. Not for reviewing someone else's PR or resolving feedback already left on one.

Simplify freshly implemented code without changing its behaviour, so review spends its attention on the shape that will actually ship. Looks for what an implementation written unit by unit could not see — the same pattern three times, a helper that already existed, scaffolding a later unit made dead. Use after an implementation is complete and before reviewing it, or when asked to tidy up settled code. Called by wt-ship. Not for fixing bugs and not for restructuring code the change barely touched.

The local ticket board in wt-dashboard — per-project kanban tickets with ids like WP-12, stored on disk instead of Linear. Use to file, list, show, move, comment on, claim or assign a local ticket; when a ticket id's prefix is a local board key (not a Linear team key); when the auditor files findings; or when the orchestrator picks the next work. Linear (e.g. ENG-N) is unchanged. Needs wt-dashboard (the full ./setup install, not the plugin alone).

Reviewer loop for a repo's open pull requests: watch every open PR, review each new head (the delta after the first review), and post the verdict — approve, comment, or hold with request-changes — under a dedicated reviewer identity, re-reviewing a held PR when its author replies. Held PRs show in the wt-dashboard Inbox. Use when started as a reviewer (`wt-agents spawn reviewer`), or when asked to watch, review or keep reviewing a repo's PRs. Three modes: standalone (`/wt-watch-prs [repo]`, this loop), dispatch (an orchestrator hands each new head to a pool reviewer and never reads a diff), and review ("Use wt-watch-prs to review <pr> --sha <sha> --session <D>": one PR at one head, then stop). Not for watching your own PR to merge-ready — that is wt-babysit.

Implement a plan to its Definition of Done, unit by unit, with an explicit evidence strategy per unit, test discovery before changes, a system-wide check of what fires two levels out, and incremental commits on logical boundaries. Takes the plan's findings table so cited claims are not re-researched. Use when implementing from a plan document or a concrete work prompt, when handed off from wt-plan, or when asked to carry out an agreed plan. Use a debugging approach instead for open-ended bugs with no plan.