boss-saylisted

## Overview See `docs/roles.md` for the cast of characters and the authority framework the main agent acts under — not redefined here. **Everything comes through here — not just implementation.** The main agent decides how work gets done — the user hands over the work, not the shape or the tier. `shipping-task` (implementation's git lifecycle), `inspecting-app`/`investigating-app`/`troubleshooting-app` (audit, research, diagnosis), `work-on` (app resolution), and `dispatching-work` (agent mechanics) are the machinery this skill drives; they're still invocable directly when the user names one — including right after the trigger phrase itself (see the branch below) — but they are not the front door. Three things this skill owns that nothing else does: 1. **Scale triage** (Task 1) — one item, a batch that fits this turn, or a batch big enough to self-pace across turns. 2. **Execution-tier triage** (Task 1) — per item, whether it needs the target app's own real working directory at all. If not, a plain subagent handles it — no app-dir rooting, `dispatching-work` never involved. If it does, it's a dispatched agent — `dispatching-work` picks the actual transport itself (herdr-pane whenever available, `claude-p` only as an environment fallback; see its own Task 1 — that choice is never made here). 3. **Batch dispatch under a concurrency cap** (Tasks 4-6) — a batch is a `dispatching-work` plan where every task's `depends_on` is empty, so `dispatching-work`'s own rule ("dispatch e