fray

Problem The hook surfaced to the user as a red on every idle — alarming and far too verbose. It repeated the entire reconcile methodology each fire, and re-nagged for the same rests because a resuming sub-agent re-fires its rest record many times. Fixes Shorten. The full reconcile discipline already lives in the skill the model has loaded. The hook now emits 1-line nudges that only point at the work: before: a 9-line wall (drain-oldest-first, rest≠done, incomplete-handoff rules, …) after: De-scary the framing. The hook already blocked via (exit 0, not exit-2-stderr) — but Claude Code renders a blocked Stop hook's to the user as a red line (the block is intentional, not an error). The fix carries the model-facing text in (a documented non-error Stop-hook feedback channel) instead of , keeps so the stop is still blocked, and adds a calm one-liner for the user. No field ⇒ no red wall. Dedupe. Each rest is now counted at most once: id'd rests via a persisted seen-set (, capped at 200), anon rests (no ) via a timestamp high-water mark (). The guard fires only on genuinely-new unreconciled rests instead of re-nagging a resuming agent's repeats. How it renders now A blocked stop no longer shows a red reason wall. The model receives a one-line reminder; the user sees a calm system note. Verification Ad-hoc hook simulation (the established test mode for these dep-free hooks): 5 rest lines (agA×3, agB×1, anon×1) → count 3 (agA deduped to 1); output uses +, no . Second fire past the 10-min cooldown: agA resume + agC new → count 1** (agA skipped). Anon track: 2 anon + agX → 3; next fire (old anon deduped via , agX deduped, +1 new anon +agY) → 2. Guards intact: → allow; virgin repo → allow; malformed log / no stdin → fail-open (exit 0, no crash); → allow. Old state file (no /) migrates cleanly — surfaces once, then dedupes. Bumps the plugin 1.7.3 → 1.7.4 and updates the SKILL.md sentence describing the REST-guard message.

Codifies several maintainer-mandated fray rules to close recurring orchestration failures. SKILL.md only (hooks unchanged). The companion AGENTS.md edits land in nubjs/nub directly. 1. Dropped-thread fix (materialize enqueued follow-ups + standing merge-train) Root cause:** a follow-up described as "enqueued behind agent X" in chat/memory but never written as a with + . The board can only auto-fire () a thread that EXISTS — a prose-only enqueue is invisible and rots during a busy stretch. The failure is upstream of any hook (the file was never created), so it is a discipline rule, not a hook gap. THE DISCIPLINE: the instant a follow-up is described as "enqueued behind / waiting on / once X returns," create the thread file THAT turn, before the next message. Added the tell ("typed enqueued behind X, no thread file → already failed"). Follow-up routing list: a "waiting on an in-flight agent" bullet routing to an + thread file. Multi-PR goals (releases/merge trains) keep ONE standing thread enumerating every open PR + merge status, refreshed from each turn. 2. Rule A — PR closing-keyword is non-negotiable Every PR-opening dispatch for an issue MUST instruct the child to put // in the PR body and verify it before , so the merge auto-closes the issue. Added to the GitHub-PR dispatch guidance + the pre-dispatch checklist. 3. Rule B — no orchestrator-internal "L1/L2" jargon in sub-agent prompts A dispatched agent does not share the orchestrators L1/L2 tier model; "you are the L1 lead, fan out L2s" is confusing jargon. Phrase sub-agent fan-out plainly ("spin up sub-agents to do X, Y, Z and synthesize"). Keep L1/L2 for the orchestrators own reasoning only. 4. Rule C — dispatch prompts point at AGENTS.md AND inline the task-critical rules A fresh agent skims a long orchestration-heavy AGENTS.md and misses load-bearing rules. Every repo-editing/PR-opening dispatch prompt must both (i) point the child at the repos agent-orientation doc (esp. a top "Non-negotiables" block) and follow it, AND (ii) INLINE the specific load-bearing rules for that task — belt-and-suspenders, since a pointer alone is unreliable. Explicitly: do NOT create a parallel (it drifts). Hooks unchanged The check already surfaces threads whose went terminal. The new failures are either upstream of any hook (a thread that never existed) or pure prompt-content rules — none warrant hook changes. SKILL bumped to 1.7.4. https://claude.ai/code/session_01YRvztkcr4fzfg9rD5edUwa