delegate-worklisted

# Delegate Work and Verify What Comes Back Your only view of delegated work is the delegate's own account of it. That account is written by the one party with an interest in it reading as complete, from a context you cannot inspect, and it is silent in exactly the places where it is wrong. A report that says nothing about instruction four is indistinguishable from a report whose author never received instruction four. The defense is not skepticism, it is structure: make each instruction produce a named artifact, then check the artifacts instead of reading the prose. `research-it` owns what a delegated *conclusion* is worth (a claim, not evidence). `prove-checks` owns whether a *check* could have gone red. This skill owns the orchestrator's side of the exchange: the brief, the delivery, and the report as a whole. ## Trigger - A prompt for a subagent, a background agent, or a parallel session is about to be written. - Two or more agents will run against the same repository or worktree. - A correction, a scope change, or a new instruction was sent to an agent that is already running. - A returned report is about to be relayed to a user, quoted, or used as the input to the next delegation. - The delegated work is expensive enough that re-running it is not the cheap fix. Not this skill: measuring what a run cost (`audit-agent`), proving a green check was capable of failing (`prove-checks`), or deciding whether a technical claim the delegate made is actually true (`research-i