Conciseness

The body is lean and example-driven with no tutoring on concepts Claude already knows (no 'what is a worktree' padding), but the 'Hook approvals in non-interactive sessions' section restates its point several times: "an untrusted `.config/wt.toml` cannot silently execute anything" repeats the section's opening two sentences, "neither is a shortcut for an interactive agent to silence an approval prompt" repeats the preceding sentence, and "Run once per project; the approval persists across invocations until the command template changes or the project moves" duplicates "re-prompted whenever a command template changes". These are minor instances of over-explanation that could be trimmed (anchor 4), not 'every token earns its place' (anchor 5); it is well above anchor 3 ('some unnecessary explanation') since the repetition is confined to one deliberately emphatic security section.

Actionability

Fully executable, copy-paste-ready guidance throughout: `wt step diff --branch beta` / `wt -C ../repo.beta step diff --branch beta` with ✓/✗ annotations for the targeting rules; `which claude codex opencode llm aichat`; `wt step commit --dry-run` as the verification step; complete TOML hook blocks for both pipeline and concurrent forms; `wt switch --create test-hooks`; `wt config approvals add`; `wt switch --create <branch> --no-cd`; and a literal sub-Agent prompt template ("You are working in `/abs/path/to/myproject.<branch>`..."). Specific examples cover the common cases — matching the anchor-5 example rather than anchor 4's 'minor gaps'.

Workflow Clarity

The two core workflows are clearly sequenced with explicit validation checkpoints: commit-message generation runs detect → propose the `[commit.generation]` change → apply after approval → "verify... `wt step commit --dry-run` renders the prompt, runs the LLM, and prints the message without committing"; hook configuration runs pick hook type by timing → derive commands from project files (package.json/Cargo.toml/pyproject.toml) → "verify they run before adding them" → "Test with `wt switch --create test-hooks`". The approvals section is a complete error→diagnosis→resolution loop, showing the literal error output and correctly steering the agent to escalate rather than use either `--yes` path. Checkpoints are present (not merely 'most'), so anchor 5 fits better than anchor 4.

Progressive Disclosure

The body is an overview with well-signaled, one-level-deep references: an "Available documentation" index annotating each file ("reference/config.md: User and project configuration (LLM, hooks, command defaults)" ... "reference/extending.md: Aliases, multi-step pipelines, custom subcommands, and template-expansion gotchas"), plus a "Common tasks reference" mapping tasks to files with section anchors (`reference/extending.md#aliases`, `reference/config.md#worktree-path-template`, `reference/llm-commits.md#prompt-templates`). No nested reference chains; detail is appropriately split out. (No bundle files were present in the review directory to verify the `reference/*.md` files exist, so this is scored on the body's reference structure alone.) This matches the anchor-5 'clear overview with well-signaled one-level-deep references; easy navigation' better than anchor 4's 'minor organization gaps'.

Specificity

Quotes: "git worktree management, hooks, and config", "working out which worktree a `wt` command will act on, or reaching for the global `-C <path>` to target one", "editing .config/wt.toml or ~/.config/worktrunk/config.toml", "adding, modifying, or debugging hooks (post-merge, post-start, pre-commit, pre-merge, post-switch, etc.)", "configuring commit message generation or command aliases", "troubleshooting wt behavior". These are multiple specific concrete actions and named config targets covering the tool's full surface (targeting, config, hooks, commit generation, aliases, troubleshooting) — the comprehensive anchor, not 'several actions with minor gaps'.

Completeness

What: "Guidance for Worktrunk (the `wt` CLI) — git worktree management, hooks, and config"; when: "Load when working out which worktree a `wt` command will act on, or reaching for the global `-C <path>`...; editing...; adding, modifying, or debugging hooks...; configuring commit message generation or command aliases; or troubleshooting wt behavior". Both what and when are explicit, and the when clause enumerates concrete trigger conditions — the anchor-5 pattern, clearly above anchor 4 ('when could be more explicit').

Trigger Term Quality

Quotes: "Worktrunk (the `wt` CLI)", "worktree", "`-C <path>`", ".config/wt.toml", "hooks", "commit message generation", "command aliases", "troubleshooting wt behavior", "general worktrunk/wt questions". Natural terms users of this tool would actually say are covered comprehensively, including synonyms (Worktrunk / wt / worktrunk / worktree) and concrete file paths and flags — matching the 'including synonyms and file extensions' anchor rather than merely 'good coverage with a few missing'.

Distinctiveness Conflict Risk

Quotes: "Worktrunk (the `wt` CLI)", ".config/wt.toml", "~/.config/worktrunk/config.toml", "wt behavior", "worktrunk/wt questions". Every trigger is tied to a named niche tool and its specific config files and commands, giving a clear niche with minimal conflict risk; the only generic phrase ("git worktree management") is a domain descriptor, not a load trigger, so this fits anchor 5 better than anchor 4's 'minor overlap risk with closely related skills'.