Delegation And Review

Delegation and Review

The orchestrator's context is scarce. Delegate bulk work, keep judgment, and treat every returned result as a claim until verified.

1. When to delegate

• Spawn for throughput (parallel independent slices while you do other

work), independence (critics/fresh-context verifiers; waiting is correct), or context protection (bulk reading, repo scans, web research, batch edits; only conclusions return).

• Do it yourself when the delta is smaller than the prompt, the decision needs

your full local context, or an agent has failed twice and manual finish is faster.

• Investigate first: if you cannot name scope, invariant, and proof, recon before

delegation.

• Bounded fan-out: launch no more agents than you can review/merge. If a wave

depends on the last, accept/reject the last wave before the next; independent slices only need to stay within review capacity. Parallel writers get isolated worktrees (a write-capable review critic needs more — an independent copy per §3's settled-tree reference, not a linked worktree).

• Isolated trees do not isolate ports (unprobed — private incident as

shape; see Provenance). When sibling sessions run servers sharing a port namespace and a configured port, they contend for it; once one is displaced (auto-port fallback, a restart elsewhere), any STATIC reference meant for that session's server — a localhost: proxy, target, or env entry still naming the configured port — now silently reaches the sibling's server: the page loads blank or shows the wrong build while every request returns 200, which reads as a bug in your own change. Defenses (pick one of the two, apply it fully — what you persist differs by defense): (1) a unique fixed port per worktree or independent session tree, run with fallback disabled so a collision fails loud, the NUMBER persisted and propagated to every session-local reference (proxy, env, browser entry) — an explicit address-in-use bind error is the contention diagnostic: then pick a different free unique port, propagate, restart (any other bind error — permissions, bad address, exhaustion — is its own failure, never a cue to switch ports); or (2) runtime derivation, where the MECHANISM is what persists — every reference re-derived from the actually-bound port after every bind, never a bound number frozen into a static ref. Auto-port fallback alone is the displacement mechanism, never the repair; writing today's fallback port into static references is the forbidden ephemeral retarget — the next restart recreates the mismatch. To repair a mismatch: choose a defense, apply its own persistence shape as above, update every session-local reference, restart or reload every consumer that read its target at startup, and never kill the sibling's server — it is another session's work. Identity check comes after every repair mutation (reference updates, restarts, reloads): record the expected marker for THIS session first (the worktree name it serves, a session nonce noted before the request — a fresh nonce from the wrong sibling still looks fresh; a content build id shared by same-revision worktrees does not discriminate), then observe exact equality with that recorded value THROUGH every relied session-local consumer path (the API proxy included, not just the top page); a listener check (lsof-style) is port discovery, never identity evidence — and the marker is state installed only in THIS session's tree (a static file it serves, a server-held value), never a caller-supplied echo: a request-reflecting endpoint returns your nonce from the wrong sibling too. Marker cleanup is the one mutation that follows the check — use a marker whose removal restarts or reloads nothing (a static file), remove it, and verify the removal against the pre-instrumentation state (tracked, untracked, and ignored files — the declared persistent port configuration stays); a marker that cannot be removed without a restart or reload is the wrong marker — pick one that can be. Any restart or reload after the check — a cleanup that broke the rule above included — voids the identity: re-prove it (serve a fresh marker, check, clean up again) before relying on the routing. When a fanned-out preview misbehaves with all-green requests, check cross-port references — references still naming the shared configured port instead of this session's bound port — before debugging your own code: stopping your preview cannot stop a sibling's server, so the wrong upstream stays up. A reference to an intentionally shared local service (one database for all worktrees) is not a cross-port defect; the rule covers references meant for the displaced session-owned server. ✅ "each worktree pinned to its own persisted port, proxy and env updated and reloaded; identity check: the page AND a request through the API proxy both returned the nonce recorded for this session; then the marker file removed — no reload needed — and its removal verified." ❌ "every request is 200, so the proxy target must be my server."

• Route by task: mechanical clear-spec work → cheapest capable model; user-facing

output → high-taste model; reviews and hard debugging → strongest available. Tie-break intelligence > taste > cost. Model lineups are volatile facts: read the environment at session time, not memory.

• **A dispatch names its model; consumption signals weigh in only where

observable** (unprobed — two-source synthesis; see Provenance). Where the harness exposes a per-dispatch model choice, choose it explicitly and name agent type + model in the dispatch's visible description (where one exists) — first read the current harness's unset-field semantics: where blank means inherit, bulk work silently runs on the orchestrator's own often-most-expensive model, and an unlabeled dispatch is unauditable (in one source's harness, a scan agent silently billed the ceiling model exactly this way). For cost, prefer the lowest-cost configuration — model × effort tier — DEMONSTRATED CAPABLE for the role; a known- incapable route is false economy (it burns the tokens anyway, failing), and dialing a capable model's effort down is one such configuration, not a universally preferred move. Where a quota/pressure signal is OBSERVABLE (a provider's quota error naming a reset time, a dashboard the user relays), treat it as a routing input; never estimate or fabricate an unobservable quota. No dial and no signal → this rule is a no-op, never a guess. ✅ "scan repo (Explore + cheapest capable model)" in the visible description. ❌ model field left blank "to keep the call short" — the orchestrator's flagship quietly does grunt work.

• A pinned model string does not pin behavior (unprobed — private

incidents as shape; see Provenance). A routing or safety decision is about to rely on a previously measured behavioral property of a hosted model — an edge-safety rate, a failure signature, a latency class: that property is not a durable attribute of the slug (hosted endpoints drift behind identical strings — in the contributor's harnesses, one CLI's edge-guard measurement flipped on re-measurement with flag and battery unchanged, and a second vendor's reproduced failure inverted to a pass days later, strings unchanged). Date-stamp every such measurement where it is recorded; at decision time, re-run the probe — its battery responses route-attributed per the labels rule below, not just a preceding trivial check (an unattributed answer measures an unknown model, not the slug's), and produced by this invocation, not replayed from a cache (the labels rule's freshness clause) — and cite the fresh result's timestamp and configuration — the fresh result informs the routing, it never replaces §2's edge specification and proof gate for the work itself, and no measurement pins the endpoint's behavior on the next request. Probe unavailable or failing → the property is unknown: assume the ADVERSE plausible state for this decision — a protective property (an edge guard, a latency class you rely on) treated as absent, a hazardous one (a known failure signature) treated as present — and the unknown BINDS the decision exactly as an adverse fresh result would: work that needed the protective property present, or the hazardous one absent, does not go to that model (hold it, route it elsewhere, or escalate); recording "adverse assumed" while still routing as if the property held is the exact failure this clause forbids. Spec the edge per §2 either way. Done when the decision record cites the fresh probe (timestamp + configuration, its route attributed per the labels rule below) or the unknown-property fallback — an undated behavioral claim about a hosted endpoint is expired on arrival, and an unattributed probe never satisfies the citation. ✅ "re-ran the edge battery this session, cache-bypassed — the wrapper's route line named the slug as what answered each response — cited its timestamp in the routing note, and specced the edge in the packet anyway." ❌ "we already measured that model guarding this edge, so route the edge-risky work to it" — any prior measurement reused for a routing or safety decision without a decision-time re-run, last week's or this morning's.

• **Empty or dead-looking output from a live probe needs a differential

diagnosis before it becomes a routing decision** (unprobed — private incidents as shape; see Provenance) — one observation (the decision-time re-probe the rule above demands can itself come back empty) cannot distinguish an intermittent transport flake from a genuine capability gap, and the reads route differently (demote to supervised use, drop from the pool, or fix your own side first). Two situations, two ladders:

• A single endpoint returns empty/no bytes. Before declaring it

dead: (1) re-probe raw, ruling out your own parsing (a grep pattern against the wrong response shape reads as "empty" too); (2) verify the key/gateway itself with a cheap call (e.g. a models-list endpoint returning 200); (3) call a different model on the same key, transport, and request shape (same canary prompt and parameters, the answer route-attributed per the labels rule below), seconds apart. Only a controlled differential — the alternate answers, the target still doesn't, everything else held equal — isolates the failure to the target's route, away from shared auth/gateway and your own parsing; the target ATTEMPT itself must be evidenced (a status or error attributed to the target's route, not silence alone — a wrapper that silently rerouted or dropped the call leaves the target UNKNOWN, not dead). Route-isolated is not yet "model down": a per-model block on your side (entitlement, quota, unsupported parameters) silences one target the same way — the attributed status decides which, and the remedies differ (fix your account vs. wait out an outage). Any other pattern yields no target verdict — a failed gateway check is your side or the shared path, fixed first (unless the work-path differential completed anyway: evidence from the path the work actually takes outranks the auxiliary screen); a silent alternate leaves the differential incomplete (the alternate can carry its own block); either way an incomplete diagnosis, no-usable-alternate included, is recorded UNRESOLVED, never dead.

• A model returns empty on some tasks in a batch. Re-run the

battery before concluding anything, then classify each TASK separately, never the run as a whole — one battery can carry both kinds ({A,B} empty then {A,C} empty is a stable failure on A plus intermittent noise on B and C). A task empty in some runs but not others is intermittent — transport, serving, or another nondeterministic cause, not a stable gap: the model is usable but unreliable there — unfit for an unattended single-shot chain with no retry; demote it to supervised or retry-wrapped use rather than dropping it from the pool outright (for any work relying on a probed property, the binding sentence below still holds it). A task empty in EVERY run is a stable per-task failure — rule out your own side for that task first: parsing (the raw re-probe above, per task), a per-task limit (a token cap that empties the same long task every run), collection loss — before recording it as a capability gap. Two runs are the floor, not proof; extend the re-runs when the decision is load-bearing. A single run cannot tell these apart, and routing on the wrong read either burns budget on a broken transport or drops a usable model from the pool. Either way, for a routing or safety decision the ladders refine the DIAGNOSIS, never the binding above: an empty, flaky, or unresolved probe of a property leaves that property UNKNOWN, and work relying on it still does not route to that model — the differential decides transport-vs-model and what to fix, not whether unverified work may route. ✅ "re-probed raw (ruled out my own parser), confirmed the key with a 200 on /models, then sent the same canary to a different model on the same key — it answered, the target's evidenced attempt still got no response: route-isolated; the attributed status was a server-side failure, not an account or request block (quota, entitlement, parameters), so recorded as an outage — a nondiagnostic status would have stayed UNRESOLVED." ❌ "the output file was empty, so the model is dead" (one observation, no differential, no re-run).

• Labels are routes, listings are claims (unprobed — private incidents

as shape; see Provenance). Two separate boundaries, each with its own check. About to route work through a listed model: a lineup listing is the tool's routing claim, not callability — across two independent tools, a listed entry failed hard on first real invocation. Verify by sending a fixed trivial prompt through the SAME wrapper, flags, auth, and execution context the work will use; the pass is two observations — a model ANSWER to that prompt, AND the wrapper's own route report naming this route as what ANSWERED (a banner echoing the requested slug is configuration, not attribution) — both produced by THIS invocation: a cached or replayed response (wrapper cache, proxy layer) is not a pass — run cache-bypassed or carry a per-invocation element a replay cannot contain. Wrapper banners, usage text, diagnostics, or error pages are not answers. Channel presence is established, never assumed: the wrapper's docs or config declaring a what-answered report, or a prior same-wrapper invocation that emitted one, establishes the channel; NO-channel-by-design is established only by that same evidence positively showing none exists — and that conclusion is itself a capability-negative claim under skill-authoring §3's protocol (pinned to the version and probe it was observed on — and, attribution being wrapper- and account-controlled, to the instance/account and date; re-verified when any pinned dimension may have drifted); where its evidence is unknown or stale, treat the invocation as channel-present-unattributed and block. Channel established but this invocation's report missing, ambiguous, or naming a silent fallback → the route is unverified — like an error or a non-answer, do not dispatch dependent work on it (§4's retry/escalation ladder governs); channel presence UNKNOWN → the same, fail closed. Only a wrapper positively established as never emitting attribution yields the reachability-only pass: the route stays unattributed — record that limit wherever th

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: F-e-u-e-r
• Source: F-e-u-e-r/opus-pack
• License: MIT

Install and usage instructions live in the source repository linked above.